'gcc -lXext' succeeds but libXext appears not to be linked

0
votes

A binary has been linked with gcc using:

gcc notion.o -Wl,-whole-archive ../ioncore/ioncore.a -Wl,-no-whole-archive -L/usr/X11R6/lib -lX11 -lXext -lSM -lICE -Wl,-whole-archive -L../libmainloop -lmainloop -lextl -ltu -Wl,-no-whole-archive pkg-config --libs lua5.1 -ldl -lm -lrt -Xlinker --export-dynamic -o notion

Linking succeeds - however, when starting the application, a user reports a crash due to an undefined symbol (XShapeCombineRectangles). XShapeCombineRectangles should be available in libXext.

Indeed, checking with 'ldd', Xext is not listed as a shared library dependency for this user:

linux-gate.so.1 => (0x0068f000)
libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0x00ec7000)
liblua5.1.so.0 => /usr/lib/i386-linux-gnu/liblua5.1.so.0
(0x00226000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0x005da000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0x005e1000)
librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0x0032c000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0x00335000)
libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0x007d6000)
/lib/ld-linux.so.2 (0x00882000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0
(0x006dc000)
libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0x00110000)
libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6
(0x00dd8000)

When I compile the application myself, ldd does show libXext, and indeed does not crash.

What could be going on here?

(More context: this bug was reported at http://sourceforge.net/tracker/?func=detail&aid=3427206&group_id=314802&atid=1324528 )

1
linuxgcclinkercrashdynamic-linking
Are you sure you're not linking in a static libXext library, and not a shared library ? – nos
I'm not entirely sure, but running with -Wl,-y,XShapeCombineRectangles shows /usr/lib/gcc/i686-linux-gnu/4.6.1/../../../i386-linux-gnu/libXext.so so I'd say it's linking dynamically, right? – Arnout Engelen

1 Answers

2
votes

It's likely that your linker (or gcc) automagically adds --as-needed behind the scenes, and that on your system XShapeCombineRectangles comes from some library other than libXext.

You can find out which library defines the XShapeCombineRectangles symbol in your link: just add -Wl,-y,XShapeCombineRectangles to your link line.

Adding -v will show if any --as-needed arguments are at play or not.

You may be able to force the final executable to reference libXext by appending -Wl,--no-as-needed,-lXext to the link line.

Update: I misunderstood the question (and you've formulated it exceedingly poorly).

To restate:

  1. the application links and works correctly on OPs system, and ldd
    app     shows dependency on libXext
  2. the application also links and starts correctly on end-user system, but ldd app does not show libXext
  3. when the application attempts to dlopen("de.so", ...) on end-user system, this fails with de.so: undefined symbol XShapeCombineRectangles

If above points are correct, it's likely that

  1. The end-user system has libXext.a, but not libXext.so
  2. The main application does not call XShapeCombineRectangles, only code in de.so does
  3. When de.so is linked, there is no -lXext on its link line.

Either installing libXext.so, or linking the main application with -u XShapeCombineRectangles will likely solve the problem.

To understand the problem, you might want to read this.

My guess is that XShapeCombineRectangles is not referenced from main executable, hence not pulled from the libXext.a "bookshelf", hence not exported from the main executable despite --export-dynamic.