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

[Tim Rice]

On Mon, 7 Nov 2005, Ralf Wildenhues wrote:

> 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.

UnixWare does have /proc/$PID/maps but it's binary data.
Looking at truss, it looks like they are opened once.
(striped out the ENOENT lines)
....
open("/usr/local/src/gnu/libtool-1.5.21a/depdemo/l1/.libs/libl1.so.0", 
O_RDONLY, 027777756034) = 3
open("/usr/local/src/gnu/libtool-1.5.21a/depdemo/l2/.libs/libl2.so.0", 
O_RDONLY, 027777756034) = 3
open("/usr/local/src/gnu/libtool-1.5.21a/depdemo/l4/.libs/libl4.so.0", 
O_RDONLY, 027777756034) = 3
open("/usr/local/src/gnu/libtool-1.5.21a/depdemo/l3/.libs/libl3.so.0", 
O_RDONLY, 027777756034) = 3
....
> 
> 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?
....
/usr/bin/ksh88 ./libtool --tag=CC --mode=link cc  -g   -o depdemo  main.o 
./l1/libl1.la ./l2/libl2.la ./l4/libl4.la 
mkdir .libs
LD_RUN_PATH="/usr/local/src/gnu/libtool-1.5.21a/tests/_inst/lib:$LD_RUN_PATH" 
cc -g -o .libs/depdemo main.o  -L./l1/.libs ./l1/.libs/libl1.so -L./l2/.libs 
./l2/.libs/libl2.so -L./l4/.libs ./l4/.libs/libl4.so 
-L/usr/local/src/gnu/libtool-1.5.21a/depdemo/l3/.libs 
/usr/local/src/gnu/libtool-1.5.21a/depdemo/l3/.libs/libl3.so 
-L/usr/local/src/gnu/libtool-1.5.21a/depdemo/l2/.libs 
/usr/local/src/gnu/libtool-1.5.21a/depdemo/l2/.libs/libl2.so 
-L/usr/local/src/gnu/libtool-1.5.21a/depdemo/l1/.libs 
/usr/local/src/gnu/libtool-1.5.21a/depdemo/l1/.libs/libl1.so -lm
creating depdemo
....

see attached depdemo-link-debug.gz for --debug output.

> 
> Thanks,
> Ralf
> 
> 
> 
> 

-- 
Tim Rice                                Multitalents    (707) 887-1469
address@hidden

depdemo-link-debug.gz
Description: depdemo-link-debug.gz