Hi all, i've found another problem with new glibc-2.14 and www.xilinx.com implementation tools. for all my fpga projects at the end of processing the xilinx mapper dies with following error: (...long path...)/xilinx_13.1/ISE_DS/ISE/bin/lin64/unwrapped/map: symbol lookup error: (...long path...)/xilinx_13.1/ISE_DS/ISE//lib/lin64/libXst_Core.so: undefined symbol: _ZN5antlr6BitSetD1Ev i've checked dynamic deps and everything looks good. _ZN5antlr6BitSetD1Ev export: $ readelf -sW libAntlr.so|grep _ZN5antlr6BitSetD1Ev 533: 0000000000018650 65 FUNC GLOBAL DEFAULT 10 _ZN5antlr6BitSetD1Ev _ZN5antlr6BitSetD1Ev import: $ readelf -sW libXst_Core.so|grep _ZN5antlr6BitSetD1Ev 6060: 0000000000000000 65 FUNC GLOBAL DEFAULT UND _ZN5antlr6BitSetD1Ev and binding: $ readelf -dW libXst_Core.so|grep Antlr 0x0000000000000001 (NEEDED) Shared library: [libAntlr.so] on 2.13 it works fine. for 2.14 ugly workaround is LD_BIND_NOW=1. looks like some kind of regression for 3rd-party binaries.
FYI, this is the same issue I was referring to in the following post on libc-help, with a test case included. http://sourceware.org/ml/libc-help/2011-07/msg00005.html The "third-party commercial tool" I mentioned at the beginning of the thread is indeed the Xilinx implementation tools, although other large C++ codebases that use dlopen might also be at risk. I'm not convinced that it's a 2.13/2.14 change... I've seen similar errors from ISE 13.1 across a wide range of systems including CentOS 5 which is some bronze age glibc 2.5. Though I won't discount that those issues could be due to distribution patches. If you have evidence comparing side-by-side libcs, then that would certainly be useful.
(In reply to comment #1) > If you have evidence comparing side-by-side libcs, then that would certainly be useful. git bisect with the testcase from previous shows first bad commit: commit 968dad0ab1f367a087ff4ad503b511dd0c565adc Author: Ulrich Drepper <drepper@gmail.com> Date: Wed Jan 19 15:32:35 2011 -0500 Fix ordering of DSO constructors and destructors.
Matthew, Could you please attach your test case to this issue so that a reviewer can get it from bugzilla?
Created attachment 5887 [details] Test case
Pawel, Can you verify if the Xilinx tools work pre the changeset you've identified? I find the quickest way is to run 'trce' with no arguments which usually breaks at exit, it might be better to bisect using that rather than my test case. (My test case is quite sensitive to the details of _dl_sort_fini, so I'm worried that you might just have located a changeset that changes the sort order but isn't the core problem, and will break with a different ordering of libraries.) Thanks, Matt
(In reply to comment #5) > Pawel, > > Can you verify if the Xilinx tools work pre the changeset you've identified? I > find the quickest way is to run 'trce' with no arguments which usually breaks > at exit, it might be better to bisect using that rather than my test case. > > (My test case is quite sensitive to the details of _dl_sort_fini, so I'm > worried that you might just have located a changeset that changes the sort > order but isn't the core problem, and will break with a different ordering of > libraries.) > > Thanks, > Matt running 'trce' w/o args works fine on 86e9235918a715095a1f5bb1c1db28fae7fca22b but on 968dad0ab1f367a087ff4ad503b511dd0c565adc it fails at end with: /local/eda/xilinx_13.2/ISE_DS/ISE/bin/lin64/unwrapped/trce: symbol lookup error: /local/eda/xilinx_13.2/ISE_DS/ISE/lib/lin64/libTw.so: undefined symbol: _ZN14UT_SM_SMALLMEMD1Ev
i've reverted two commits (modulo makefile conflicts and without accidental rtld.c change): 6b1e7d19 Handle DSOs without any dependency in ld.so 968dad0a Fix ordering of DSO constructors and destructors. now, the Xilinx ISE works again.
btw, this breakage was backported to RHEL-5/CentOS-5: * Mon Feb 21 2011 Andreas Schwab <schwab@redhat.com> - 2.5-59 - Fix ordering of DSO constructors and destructors (#604796)
Fixed in master.
(In reply to comment #9) > Fixed in master. which commit fixes this issue? glibc's testrun.sh + ./dlmain testcase fails on glibc-2.14-318-g6857791
(In reply to comment #10) > (In reply to comment #9) > > Fixed in master. > > which commit fixes this issue? > glibc's testrun.sh + ./dlmain testcase fails on glibc-2.14-318-g6857791 ahh, my fault, i've tested http://repo.or.cz/w/glibc.git master instead of http://sourceware.org/git/?p=glibc.git;a=summary http://sourceware.org/git/?p=glibc.git;a=commit;h=d45c60c2feb38d95e7ad95af6edb39a6d5afba81 fixes the problem.