Linker ld



  • 1. SOLARIS 8 problem
    Hello, i ecounter a problem installing sol8. i use an Ultra60 via ttya and the following settings in openboot: input and output set to ttya with 9600,8,n,1. when i boot my sol8 02/02 installation cd via boot cdrom my U60 starts working and shows some info about solaris5.8 (boot info message). after that a bar starts turning over and stops in a horizontal position. in this state nothing is going on any more. no disk or cdrom activity and no further output for about 10 hours now. times ago i installed sol8 succesfully on this machine. meanwhile i tried linux but this was not the right choice for me. now i have this strange problem reinstalling sol8. since i can't find some information regarding this problem i did like to ask if someone can tell me how to proceed or where to find information. best regards uwe
  • 2. Wireless Router and Hostnames
    I have a wireless router which takes care of IP addresses for machines on my wireless network. But not hostnames. Is it possible to get DNS or some naming service to work with the router? It's a Linksys WRT54G
  • 3. urgent help please! - moved /usr/lib
    Hi Andrew, Today I moved the /usr itself! (Didn't have enough space - thought I would create a symlink to another copy - very clever indeed) I googled for a solution after pulling my hair out for a few hours and found this post. Your suggestion about usr/sbin/static/mv worked! I thought I should let you know. Regards, Sony Jose. P.S. I noticed that you post was created in 1997! Andrew Gabriel wrote: > In article < XXXX@XXXXX.COM >, > XXXX@XXXXX.COM (Tim Downing) writes: > >I have moved /usr/lib and intended to create symlink in order to free > >space on /usr which is bordering on full. > > > >Now nothing works! I can't even move it back! > > > >Can anyone offer me a fix? > > Use /usr/sbin/static/mv > > Other utilities available in /usr/sbin/static are cp, ln, rcp, tar > (no ls unfortunately - try echo directory/* as a substitute). > > -- > Andrew Gabriel XXXX@XXXXX.COM > Consultant Software Engineer

Linker ld

Postby Ramachandran, Madhu [NCRTP:3X30:EXCH] » Thu, 07 Aug 2003 06:25:07 GMT


Have a question with respect to the linker 'ld' on Solaris 2.8
We use a machine (say A) for our loadbuild. Our patch team (which patches
fixes) uses another machine (say B)to build. The problem encountered is
this: Machine B installed some OS patches. Hence, the code linked in that
machine using 'ld' produced different size executable and sharedLib than
what was produced in Machine A. To ensure both machines produce same size
executable, there was a proposal to put the linker 'ld' in a repository like
ClearCase(CC). this way the linker used is the same. I guess i could put
'ld' on CC. However, iam not sure whether that alone would work? are there
any other libraries which 'ld' needs which should also be in CC? Also, is
there a chance that some other OS patching in the future could cause the
'ld'(which i put in CC) to fail in future?

Thanks for your time in advance!


Similar Threads:

1.when is the dynamic linker called !!

> > Nope, there are no 'magically' loaded libraries. While is indeed
> > used by virtually every program it isn't mapped for the first time till
>  the
> > first program that uses it starts. As soon as no more processes have it
> > mmaped it will cease to 'consume' memory.
>     Not only that, but it's not even loaded then. It's mapped, but it won't
> be loaded until the memory it was mapped into is accessed! This is known as
> 'faulting in'.
This seems similar to DLLs in windows,but i thought that dl_* calls
were actually the equivalent of DLL's in Linux.Do you mean to say that
the actual mapping is done at runtime when we use dl_*
functions.Because as far as i know of dll's they are dynamically
loaded and unloaded when the last reference to it caeses to exist.The
unloading part is similar to unix shared libraries.Its the loading
part, and dl_* calls are actually close/equal to the dll's loading.

please correct me if iam wrong.

2.GNU linker ld usage question.


Currently I've been looking into the Makefile of bootloader "DAS
At final build stage, gnu linker links all object and produce
the u-boot by the following Makefile target rule:

u-boot:		depend $(SUBDIRS) $(OBJS) $(LIBS) $(LDSCRIPT)
		UNDEF_SYM=`$(OBJDUMP) -x $(LIBS) | sed  -n -e
			--start-group $(LIBS) $(PLATFORM_LIBS) --end-group \
			-Map -o u-boot

$(LDFLAGS) variable ends "-n" and UNDEF_SYM is undefined symbol name
Can the undefined symbol names be the non-option argument of gnu ld?
According to manual page or info, I haven't found any mention of it.

Do I misunderstand at some point about usage of ld?
If anyone have a answer please let me know.


3.linker ld script

Can anyone help me with  Linker LD script memory allocation
I need to write a embedded bootloader

The bootloader should be placed i ROM at 0xa000 and above . The code should
include some function foo1()... foo10().  and main() and crt0

The CPU  starts at 0x0000 where it should be vector which should point to
crt0 (rom version)
.After boot process . The bootloader wil copy its Ram based program ( runing
in RAM) from external device (Rs232) .

The Memory is mapped as
000-0x50  Hardware vectors (prom)
0x52---0x1ffe  Program  RAM   Where the sshould be copied from external
2000-3000 Ram ( ram , heap , stack)
0xa000-0xc000 ROM (bootloader)

How should I  write a LD script file  for both Rom and Ram based version

With regards
George Arndt

4.Debian Etch - the LD Linker command

The LD command is part of the GNU binutils package,  Debian etch 
currently has version 2.17 in there package feed although version 2.18 
is available from GNU).

The LD program is the GNU linker program and has been around for some 

I have noticed something very strange when checking through a log file 
generated while building a program.   The relevant log output is :-

checking for ld --version-script... no
*** WARNING: You should not compile GNU libc without versioning. Not 
*** versioning will introduce incompatibilities so that old binaries
*** will not run anymore.

But if I type ld -help it displays

   --version-script FILE       Read version information script

so it looks as if the --version-script option is supported because it is 
displayed as part of the help screen.

If I type 'ld --version-script' I get the following console output

ld: unrecognized option '--version-script' which infers that the 
--version-script option is not included.

Is this a possible bug,  perhaps either with the debian etch version or 
with the version compiled for any distro??
Robert Hammond   <Mailto: XXXX@XXXXX.COM >

5.ld (linker) appears to set incorrect memory locations when plugin libraries involved

Hi everyone,

I'd be forever grateful (and quite impressed), if anyone knows the
solution to the following problem:

I have a program which links to many libraries (Qt, lapack, atlas, and
many more) and also loads plugin libraries via dlopen().

The plugin consists of only these functions:

void controller()
  cout << "got here" << endl;

void init(Object* x)
  void (**fn)() = &x->fn;
  *fn = controller;
  // these two statements equivalent to x->fn = controller and are
used for illustrate the problem

The program that loads the plugin (highly simplified and modified for

int main()
  Object o;
  typedef void (*init_t)();

  // load init function
  void* handle = dlopen("", DTLD_NOW);
  init_t init = (init_t) dlsym(handle, "init");
  const char *dlsym_error = dlerror();

  // run controller
  if (o.controller)
    cout << "no controller!" << endl;

Running this program yields the output "no controller!"

Debugging with gdb reveals that the statement void *(*fn) = &x->fn
uses the wrong memory address for x->fn (it is off by 0x70 bytes
according to gdb): the program is writing to the wrong location (I've
verified this).

I wouldn't mind including the source for my program, but it depends on
many libraries, at least one of which I can guarantee you don't have

Some clues:

If I link the code together with the program that loads and executes
the plugin (i.e., making it no longer a plugin), the code works

valgrind does not indicate any problems

I've tried RTLD_NOW, RTLD_GLOBAL, and RTLD_LAZY- makes no difference

In the past, I had weird problems occurring within my plugins (C++
RTTI would fail inexplicably when using data passed to the plugin),
but I was able to get around these problems and didn't spend the time
to diagnose the situation.

Source files are compiled with -fPIC

Problem occurs on 3 different unix machines (2 machines running
different distributions of linux and a OS X leopard machine).

I've tried building all third party libraries as shared libraries to
no effect.

Thanks for your help and your time,

6. (relocating - possible?) ... a different

7. [PATCH v2 2/2] m68k: Cleanup linker scripts using new linker script macros.

8. "m68k: Cleanup linker scripts using new linker script macros." and old binutils (was: [PATCH] m68k: Atari EtherNAT - Nicolas Pitre has a new email address)

Return to unix


Who is online

Users browsing this forum: No registered users and 94 guest