Bug 52167

Summary:	llvmpipe test programs link fails when ld --as-needed option is used
Product:	Mesa	Reporter:	Olivier Blin <freedesktop>
Component:	Mesa core	Assignee:	mesa-dev
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	medium	CC:	colin, csredrat, jfonseca, pedretti.fabio, sarvatt
Version:	git
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:
Attachments:	gallium: only link static archives between ld start/end group options

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.