Why does ldd show this dynamic linker location?

Question

Here's the link command. Notice the specially defined dynamic linker near the beginning.

time gcc -Wl,-rpath,/data/data/org.freesoft.Macaulay2/files/lib -Wl,-rpath,/data/data/org.freesoft.Macaulay2/files/lib/Macaulay2/armv7l-Linux-Ubuntu-12.04/lib -L/root/M2/M2/libraries/final/lib -Wl,--dynamic-linker=/data/data/org.freesoft.Macaulay2/files/lib/ld-linux.so.3 -L/usr/lib/gcc/arm-linux-gnueabi/4.6 -L/usr/lib/gcc/arm-linux-gnueabi/4.6/../../../arm-linux-gnueabi -L/usr/lib/gcc/arm-linux-gnueabi/4.6/../../../../lib -L/lib/arm-linux-gnueabi -L/lib/../lib -L/usr/lib/arm-linux-gnueabi -L/usr/lib/../lib -L/usr/lib/gcc/arm-linux-gnueabi/4.6/../../.. timestamp.o ../d/M2inits.o ../d/startup.o ../d/../regex/regex.o ../d/gmp_init.o ../d/gmp_aux.o ../d/main.o ../d/pari-c.o ../d/M2-factory.o ../d/M2types.o ../d/scclib.o ../d/M2lib.o ../d/M2mem.o ../d/gdbm_interface.o ../d/xml-c.o ../d/arithmetic.o ../d/atomic.o ../d/M2.o ../d/system.o ../d/strings.o ../d/varstrin.o ../d/strings1.o ../d/errio.o ../d/vararray.o ../d/ctype.o ../d/nets.o ../d/varnets.o ../d/interrupts.o ../d/pthread0.o ../d/stdiop0.o ../d/gmp.o ../d/engine.o ../d/xml.o ../d/stdio0.o ../d/parse.o ../d/expr.o ../d/stdio.o ../d/stdiop.o ../d/err.o ../d/gmp1.o ../d/tokens.o ../d/getline.o ../d/lex.o ../d/parser.o ../d/binding.o ../d/basic.o ../d/convertr.o ../d/common.o ../d/util.o ../d/struct.o ../d/classes.o ../d/buckets.o ../d/equality.o ../d/hashtables.o ../d/sets.o ../d/version.o ../d/evaluate.o ../d/mysqldummy.o ../d/pthread.o ../d/actors.o ../d/actors2.o ../d/actors3.o ../d/actors4.o ../d/xmlactors.o ../d/actors5.o ../d/threads.o ../d/pari.o ../d/interface.o ../d/interface2.o ../d/texmacs.o ../d/interp.o ../e/error.o ../e/table.o ../e/exptable.o ../e/monordering.o ../e/complex.o ../e/rand.o ../e/matrix-stream.o ../e/cra.o ../e/aring-zz-flint.o ../e/aring-RRR.o ../e/aring-tower.o ../e/aring-m2-gf.o ../e/aring-promoter.o ../e/aring-glue.o ../e/aring-zzp.o ../e/aring-gf.o ../e/aring-ffpack.o ../e/aring.o ../e/schurSn.o ../e/schur2.o ../e/spair-heap.o ../e/dpoly.o ../e/tower.o ../e/interreduce.o ../e/gb-test1.o ../e/finalize.o ../e/NAG.o ../e/overflow.o ../e/memory-status.o ../e/exceptions.o ../e/imonorder.o ../e/sagbi.o ../e/monideal-minprimes.o ../e/dmat-LU.o ../e/lapack.o ../e/LLL.o ../e/fractionfreeLU.o ../e/ntl-interface.o ../e/fplll-interface.o ../e/mat.o ../e/dmat.o ../e/smat.o ../e/coeffrings.o ../e/Eschreyer.o ../e/gbweight.o ../e/qring.o ../e/polyquotient.o ../e/poly.o ../e/debug.o ../e/comp.o ../e/comp-gb.o ../e/comp-gb-proxy.o ../e/comp-gb-declared.o ../e/comp-res.o ../e/res-a0.o ../e/res-a0-poly.o ../e/res-a1.o ../e/res-a1-poly.o ../e/res-a2.o ../e/reducedgb.o ../e/reducedgb-field.o ../e/reducedgb-marked.o ../e/reducedgb-field-local.o ../e/reducedgb-ZZ.o ../e/montable.o ../e/montableZZ.o ../e/schorder.o ../e/GF.o ../e/ZZ.o ../e/QQ.o ../e/RRR.o ../e/CCC.o ../e/assprime.o ../e/buffer.o ../e/comb.o ../e/det.o ../e/frac.o ../e/franzi-brp.o ../e/freemod.o ../e/gb-default.o ../e/gb-homog2.o ../e/gb-sugarless.o ../e/gb-toric.o ../e/gb-walk.o ../e/gbring.o ../e/gauss.o ../e/hermite.o ../e/hilb.o ../e/int-bag.o ../e/intarray.o ../e/matrix.o ../e/matrix-con.o ../e/mem.o ../e/monideal.o ../e/monoid.o ../e/monomial.o ../e/ntuple.o ../e/polyring.o ../e/pfaff.o ../e/relem.o ../e/ring.o ../e/ringmap.o ../e/schur.o ../e/skew.o ../e/skewpoly.o ../e/solvable.o ../e/spair.o ../e/text-io.o ../e/varpower.o ../e/weylalg.o ../e/ZZp.o ../e/interrupted.o ../e/newdelete.o ../e/ntl-internal.o ../e/ntl-debugio.o ../e/matrix-kbasis.o ../e/matrix-symm.o ../e/matrix-sort.o ../e/ring-vecs.o ../e/res-a2-gb.o ../e/engine.o ../e/x-aring.o ../e/x-monom.o ../e/x-monoid.o ../e/x-relem.o ../e/x-free.o ../e/x-mat.o ../e/x-gb.o ../e/x-ringmap.o ../e/x-mutablemat.o ../e/franzi-gb.o ../e/franzi-interface.o ../e/x-monideal.o ../e/x-factor.o ../e/f4/f4.o ../e/f4/f4-syz.o ../e/f4/f4-mem.o ../e/f4/f4-monlookup.o ../e/f4/f4-types.o ../e/f4/f4-computation.o ../e/f4/f4-spairs.o ../e/f4/f4-m2-interface.o ../e/f4/hilb-fcn.o ../e/f4/monhashtable.o ../e/f4/monsort.o ../e/f4/moninfo.o ../e/f4/ntuple-monomial.o ../e/f4/varpower-monomial.o ../e/f4/gausser.o ../system/m2file.o ../system/supervisor.o ../system/tests.o ../kernel/bibasis/bibasis.o ../kernel/bibasis/allocator.o ../kernel/bibasis/launcher.o ../kernel/bibasis/monom.o ../kernel/bibasis/monomDL.o ../kernel/bibasis/monomDRL.o ../kernel/bibasis/monomLex.o ../kernel/bibasis/settings-manager.o -L../d -lM2inits2 -lfac -lcf -lfac -lcfmem -lgc -lpthread -lmpfr -lfrobby -lpari -lmpirxx -lmpir -Wl,-Bstatic -Wl,-Bdynamic -lxml2 -lz -lm -llapack -lblas -lntl -lgdbm -lgc -lreadline -lpthread -ldl -lrt -lstdc++ -lncurses -Wl,-Bstatic -lgfortran -Wl,-Bdynamic -ldl -lrt -lm -lxml2 -lm -lc -o "/root/M2/M2/StagingArea/armv7l-Linux-Ubuntu-12.04/bin/M2".tmp

Here's what ldd has to say about the resulting executable:

ldd /root/M2/M2/StagingArea/armv7l-Linux-Ubuntu-12.04/bin/M2.tmp
    libpthread.so.0 => /data/data/org.freesoft.Macaulay2/files/lib/libpthread.so.0 (0x401b2000)
    libxml2.so.2 => /data/data/org.freesoft.Macaulay2/files/lib/libxml2.so.2 (0x401cd000)
    libm.so.6 => /data/data/org.freesoft.Macaulay2/files/lib/libm.so.6 (0x40023000)
    liblapack.so.3gf => /data/data/org.freesoft.Macaulay2/files/lib/liblapack.so.3gf (0x4029b000)
    libntl-5.4.2.so => /data/data/org.freesoft.Macaulay2/files/lib/libntl-5.4.2.so (0x40925000)
    libgdbm.so.3 => /data/data/org.freesoft.Macaulay2/files/lib/libgdbm.so.3 (0x4009c000)
    libreadline.so.6 => /data/data/org.freesoft.Macaulay2/files/lib/libreadline.so.6 (0x400f0000)
    libdl.so.2 => /data/data/org.freesoft.Macaulay2/files/lib/libdl.so.2 (0x4008f000)
    librt.so.1 => /data/data/org.freesoft.Macaulay2/files/lib/librt.so.1 (0x400ca000)
    libstdc++.so.6 => /data/data/org.freesoft.Macaulay2/files/lib/libstdc++.so.6 (0x40a3f000)
    libc.so.6 => /data/data/org.freesoft.Macaulay2/files/lib/libc.so.6 (0x40ae6000)
    /data/data/org.freesoft.Macaulay2/files/lib/ld-linux.so.3 => /lib/ld-linux.so.3 (0x400aa000)
    libgcc_s.so.1 => /data/data/org.freesoft.Macaulay2/files/lib/libgcc_s.so.1 (0x400d8000)
    libz.so.1 => /data/data/org.freesoft.Macaulay2/files/lib/libz.so.1 (0x40120000)
    libblas.so.3gf => /data/data/org.freesoft.Macaulay2/files/lib/libblas.so.3gf (0x40138000)
    libgfortran.so.3 => /data/data/org.freesoft.Macaulay2/files/lib/libgfortran.so.3 (0x40bc8000)
    libgmp.so.10 => /data/data/org.freesoft.Macaulay2/files/lib/libgmp.so.10 (0x40c43000)
    libtinfo.so.5 => /data/data/org.freesoft.Macaulay2/files/lib/libtinfo.so.5 (0x40c8d000)

Why does everything point to /data/data/... EXCEPT the dynamic loader itself?

If you want to reproduce the whole thing, it's a Macaulay 2 build on ARM with this configure command:

./configure  --enable-download --enable-build-libraries=pari --prefix=/data/data/org.freesoft.Macaulay2/files LDFLAGS=-Wl,--dynamic-linker=/data/data/org.freesoft.Macaulay2/files/lib/ld-linux.so.3

score 6 · Accepted Answer · answered Aug 30 '13 at 08:12

6

That's because ldd is actually a script that calls /lib/ld-linux.so.3 with the executable as argument and LD_TRACE_LOADED_OBJECTS=1 in its environment, so /lib/ld-linux.so.3 reports itself as the dynamic linker.

Instead, you can run

LD_TRACE_LOADED_OBJECTS=1 /root/M2/M2/StagingArea/armv7l-Linux-Ubuntu-12.04/bin/M2.tmp

directly, in which case that will be the dynamic linker that you specified that will dump the libraries and itself.

answered Aug 30 '13 at 08:12

Stéphane Chazelas

544,893

2

The loader is in the .interp section of an ELF binary, check with readelf -l M2.tmp or objdump -s -j .interp M2.tmp, especially useful for cross-compiles when your build host cannot run the binaries. Similarly, the .dynamic section (indirectly) lists the dynamic libraries (in .dynstr), use readelf for that too (it chases the links and prints the library names, objdump just gives the offsets). – mr.spuratic Aug 30 '13 at 08:56
Yes... that gives me the output I expected! Thank you! – Brent Baccala Aug 31 '13 at 21:57

score 1 · Answer 2 · answered Aug 30 '13 at 07:39

The arguments:

-Wl,-rpath,/data/data/org.freesoft.Macaulay2/files/lib 
-Wl,-rpath,/data/data/org.freesoft.Macaulay2/files/lib/Macaulay2/armv7l-Linux-Ubuntu-12.04/lib

are getting passed to the linker from gcc. These are what's driving the /data/data in your final binary build.

These switches:

-Wl,--dynamic-linker=/data/data/org.freesoft.Macaulay2/files/lib/ld-linux.so.3

are controlling where to find the dynamic loader. Double check that this path:

/data/data/org.freesoft.Macaulay2/files/lib/ld-linux.so.3

is an actual file and not a link to /lib/ld-linux.so.3. At least according to the ldd output:

/data/data/org.freesoft.Macaulay2/files/lib/ld-linux.so.3 => /lib/ld-linux.so.3 (0x400aa000)

it would appear to be a link.

I double checked it. It's not a link. Everything slm says is right, but Stephane Chazelas has the explaination for ldd's behavior, I think. — Brent Baccala, Aug 31 '13 at 22:02
@BrentBaccala - yeah StephaneChazelas knows things that no other human on the planet knows. I never knew that was a script either 8-). — slm, Aug 31 '13 at 22:50

Why does ldd show this dynamic linker location?

2 Answers2

Linked