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 [EMAIL PROTECTED]
depdemo-link-debug.gz
Description: depdemo-link-debug.gz