Re: SCO/bugfix patch 8 of 10: ltmain.in -L handling for SCO platforms

[Ralf Wildenhues]

Hi Tim,

* Tim Rice wrote on Sun, Nov 06, 2005 at 11:41:39PM CET:
> ...
> $ dump -Lv .libs/depdemo
> 
> libs/depdemo:
> 
>   **** DYNAMIC SECTION INFORMATION ****
> dynamic :
> [INDEX]       Tag      Value
> [1]   NEEDED   libl1.so.0
> [2]   NEEDED   libl2.so.0
> [3]   NEEDED   libl4.so.0
> [4]   NEEDED   libl3.so.0
> [5]   NEEDED   libl2.so.0
> [6]   NEEDED   libl1.so.0
> [7]   NEEDED   /usr/lib/libc.so.1
> [8]   INIT     0x8048750
> [9]   FINI     0x8048760
> [10]  RPATH    /usr/local/src/gnu/libtool-1.5.21a/tests/_inst/lib:
> [11]  HASH     0x80480e8
> [12]  STRTAB   0x8048328
> [13]  SYMTAB   0x8048198
> [14]  STRSZ    0x14e
> [15]  SYMENT   0x10
> [16]  DEBUG    0
> [17]  PLTGOT   0x8049828
> [18]  PLTSZ    0x48
> [19]  PLTREL   0x11
> [20]  JMPREL   0x8048498
> [21]  REL      0x8048478
> [22]  RELSZ    0x20
> [23]  RELENT   0x8

Ah-ha!  So the linker thinks these are two different libraries, and adds
two DT_NEEDED entries.  How stupid.  Now we need to find out whether
this affects the dynamic loader (RTLD) as well.  It's bound to be pretty
unlikely, but with the -lc disaster, I won't place any bets.  :-/

Is there a way to find out the equivalent of what this does on Linux?
$ cat /proc/$PID/maps

Alternatively, and this is what it boils down to: Does the loader try to
load libl1.so.0 twice (and thus, for example, create two distinct
sections for static library data)?  I don't care too much about the
extra DT_NEEDED entry if it does no harm otherwise.

Another thing: the RPATH entry is fishy (this is a Libtool bug): there
should not be a trailing colon, I believe.  I think I know where this
happens (there is a TODO entry for this, too, Albert reported it some
time ago but I never saw it happen).  Could you post the link line of
`depdemo' and its output with --debug added, too?

Thanks,
Ralf