Bug 52167 - llvmpipe test programs link fails when ld --as-needed option is used
Summary: llvmpipe test programs link fails when ld --as-needed option is used
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: mesa-dev
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-16 20:12 UTC by Olivier Blin
Modified: 2013-06-13 21:44 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:


Attachments
gallium: only link static archives between ld start/end group options (2.67 KB, patch)
2012-08-03 22:44 UTC, Olivier Blin
Details | Splinter Review

Description Olivier Blin 2012-07-16 20:12:05 UTC
llvmpipe test programs link fails when ld --as-needed option is used:

Making all in llvmpipe
gmake[1]: Entering directory `/home/blino/vc/mageia/packages/cauldron/mesa/BUILD/mesa-20120715/src/gallium/drivers/llvmpipe'
g++ -Wl,--as-needed -Wl,-z,relro -Wl,-O1 -Wl,--build-id -Wl,--enable-new-dtags -L/usr/lib64/llvm  -lpthread -lffi -ldl -lm  lp_test_blend.o lp_test_main.o -o lp_test_blend -Wl,--start-group  -L../../auxiliary/ -lgallium libllvmpipe.a -lLLVM  -lXext -lXdamage -lXfixes -lX11-xcb -lX11 -lxcb-glx -lxcb -lXxf86vm   -ldrm   -lm -lpthread -ldl -Wl,--end-group
/usr/bin/ld: ../../auxiliary//libgallium.a(u_dl.o): undefined reference to symbol 'dlclose@@GLIBC_2.2.5'
/usr/bin/ld: note: 'dlclose@@GLIBC_2.2.5' is defined in DSO /usr/lib/gcc/x86_64-mageia-linux-gnu/4.7.1/../../../../lib64/libdl.so so try adding it to the linker command line
/usr/lib/gcc/x86_64-mageia-linux-gnu/4.7.1/../../../../lib64/libdl.so: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
gmake[1]: *** [lp_test_blend] Error 1
gmake[1]: Leaving directory `/home/blino/vc/mageia/packages/cauldron/mesa/BUILD/mesa-20120715/src/gallium/drivers/llvmpipe'

My ld configuration is the following:
LD='/usr/bin/ld -m elf_x86_64'
LDFLAGS=' -Wl,--as-needed -Wl,-z,relro -Wl,-O1 -Wl,--build-id -Wl,--enable-new-dtags'

Link goes fine is all existing -ldl options are removed, and one extra occurence of -ldl is added after the --end-group option:

g++ -Wl,--as-needed -Wl,-z,relro -Wl,-O1 -Wl,--build-id -Wl,--enable-new-dtags -L/usr/lib64/llvm  -lpthread -lffi -lm  lp_test_blend.o lp_test_main.o -o lp_test_blend -Wl,--start-group  -L../../auxiliary/ -lgallium libllvmpipe.a -lLLVM  -lXext -lXdamage -lXfixes -lX11-xcb -lX11 -lxcb-glx -lxcb -lXxf86vm   -ldrm   -lm -lpthread -Wl,--end-group -ldl
Comment 1 Olivier Blin 2012-07-16 20:15:23 UTC
Link is also fine if I remove the --as-needed option in the original command.
Comment 2 Jose Fonseca 2012-07-17 12:54:34 UTC
"-ldl" appears several time in the command line. So I don't understand why dlclose is not dlclose.

I'm not an automake expert so I don't know how to help here.
Comment 3 Olivier Blin 2012-08-03 22:13:24 UTC
Actually, only static archives should be listed between the --start-group and --end-group options.
We should list static archives and dynamic libraries in different variables, like done with a LDADD variable in state_trackers/d3d1x/progs/Makefile.

I will prepare a patch.
Comment 4 Olivier Blin 2012-08-03 22:44:42 UTC
Created attachment 65103 [details] [review]
gallium: only link static archives between ld start/end group options

The attached patch fixes the issue.

I have checked the Makefiles in src/gallium, and found only llvmpipe and gd3d1x mixing static archives and dynamic libs in the LIBS variable, which is used between --start-group and --end-group ld options.
Comment 5 roberth 2012-08-05 01:47:32 UTC
*** Bug 49504 has been marked as a duplicate of this bug. ***
Comment 6 roberth 2012-08-21 19:26:18 UTC
Any chance of this being commited to master? It fixes the build when --with-llvm-shared-libs is used.
Comment 7 Fabio Pedretti 2012-09-01 19:07:34 UTC
It seems that this, or at least bug #49504 which is a duplicate, is fixed. Close it if you agree.
Comment 8 Olivier Blin 2012-09-07 08:55:27 UTC
Fabio: no, the bug is still present in 9.0 branch, and likely in master since the build files did not change.
The patch from comment 4 can still be applied as is.
Comment 9 Fabio Pedretti 2013-01-11 11:03:33 UTC
This patch no longer apply after recent automake work. Fixed?
Comment 10 Sergei 2013-01-11 21:51:09 UTC
Fixed this?
Comment 11 Olivier Blin 2013-06-13 21:44:33 UTC
I can not reproduce the build issue anymore, so this patch is not needed.
This has likely been fixed by the automake conversion.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.