Hi libtool gurus :)
I would really appreciate your input on a problem I have, that might
or might not be a libtool problem.
When building RPMs, an unwanted dependency sneakes in preventing a
clean install
error: Failed dependencies:
libc.so.6.1(GLIBC_PRIVATE)(64bit) is needed by
MySQL-server-enterprise-5.1.31-0.rhel4.ia64
When I looked into this I now know why it happens (took me many hours
of trial and error, searching, and reading generated scripts). But I
don't know where to solve it the best, i.e. where the bug is. If in
libtool, icc, Red Hat, .... or me ;)
The facts:
Dist : Red Hat RHEL5 (same problem on RHEL3 and RHEL4)
uname -a : Linux hostname 2.6.18-53.1.4.el5 #1 SMP Wed Nov 14 10:37:54 EST
2007
ia64 ia64 ia64 GNU/Linux
C/C++ : Intel(R) C IA-64 Compiler for applications running on IA-64,
Version 10.0 Build 20070809 Package ID: l_cc_c_10.0.026
Autoconf : 2.63
Automake : 1.10.2
Libtool : 2.2.6
Environment
CC="icc -static-intel -static-libgcc"
CXX="icpc -static-intel -static-libgcc"
CFLAGS="-O3 -g -unroll2 -ip -mp -restrict -no-ftz -no-prefetch"
CXXFLAGS="-O3 -g -unroll2 -ip -mp -restrict -no-ftz -no-prefetch"
LDFLAGS=""
Now my observation about events during configure and build leading up
to the problem
(1) "configure" when run will set
output_verbose_link_cmd='$CC -shared $CFLAGS -v conftest.$objext 2>&1 |
$GREP "\-L"'
This relies on that if using "-v" the verbose output will list
the "link line" used, and it does. The output is then split and
arguments matched one by one to create 'postdeps_CXX', that in my
case ends up like
-L/opt/intel/cc/10.0.026/lib \
-L/usr/lib/gcc/ia64-redhat-linux/4.1.2/ \
-L/usr/lib/gcc/ia64-redhat-linux/4.1.2/../../../ \
-limf -lm -lipgo -lstdc++ -lirc -lipr -lgcc -lgcc_eh \
-lirc -lc -lgcc -lgcc_eh -lunwind -lirc_s -ldl -lc
This is what 'postdeps' will be set to in the generated
"libtool" script.
(2) When linking the main executable "mysqld" there is a libtool call
/bin/sh ../libtool ... libndb.la ... (no -lc or -lgcc) ... -lm ...
that expands to
icpc -static-intel -static-libgcc -O3 ... .libs/libndb.a -lc -lgcc ...
-lm ...
i.e. there is a "-lc" before the first "-lm". This is where the
trouble begins.
(3) The "libndb.la" file contains
dependency_libs=' -lpthread -lpthread -lpthread -lcrypt -lnsl -lpthread
/usr/lib/libunwind.la'
The "libunwind" library is not referenced explicitly from my
build files, it is from "libtool" adding it from 'postdeps'. Why
that library and not the others from 'postdeps' are added I don't
know.
(4) The reason the "-lc -lgcc" shows up in my "mysqld" link line is
from "libtool" expanding ".la" files on the command line
(recursively?). And "libndb.la" is referencing /usr/lib/libunwind.la"
that contains the line
dependency_libs=' -lc -lgcc'
(5) There is an implicit reference to "-lc" when running "icpc" for
linking, so the effect of this expansion is that we pass to the
real linker
ld ... -o mysqld .... -lc ..... -lm ... -lc
Now why is that bad? The reason is that there are symbols
deliberately defined twice in the system libraries.
% eu-readelf -s /usr/lib/libm.so | fgrep __libm_error_support
2138: 0000000000062270 90752 FUNC LOCAL DEFAULT 12 __libm_error_support
% eu-readelf -s /lib/libc.so.6.1 | fgrep __libm_error_support
2381: 000000000004e790 48 FUNC GLOBAL DEFAULT 11
__libm_error_support@@GLIBC_PRIVATE
6705: 000000000004e790 48 FUNC GLOBAL DEFAULT 11 __libm_error_support
What happens when linking "mysqld" is that because there is a
"-lc" before "-lm", the GLIBC_PRIVATE one in "libc" will be
picked, not the one in "libm". As can be seen with a
% eu-readelf -s mysqld | fgrep __libm_error_support
4206: 0000000000000000 48 FUNC GLOBAL DEFAULT UNDEF
__libm_error_supp...@glibc_private (8)
The automatic dependency generator used by the RPM tools will
then add this "libc.so.6.1(GLIBC_PRIVATE)(64bit)" dependency to
the RPM created.
So who is at fault here? Some options are
(A) Red Hat, the "/usr/lib/libunwind.la" should not have ' -lc -lgcc'
as a dependency, those are implicit and should never be in a ".la",
except maybe when building the compiler/linker itself?
(B) Intel, icc/icpc should never have output "-lunwind" in the link line
when using "-v"? Running "gcc -v ..." doesn't.
(C) Intel, SuSE has the exact same content of "libunwind.la", but
'postdeps' contains a "-lm" before "-lc", so should icc/icpc "-v"
on Red Hat?
(D) Libtool, it tries too hard, should not use "icpc -v...." to grab
compiler internals and should not use any 'postdeps', it should
trust the compiler/linker to do its job?
(E) Libtool, it should have filtered away compiler implicit libraries
when expanding dependencies found in ".la" files?
(F) The linker, it should know about GLIBC_PRIVATE, and search for
non private occurrences first, then if not found do another scan
for private ones?
(G) Linux system devs, for defining that symbols twice?
(H) Me, for not using these tools correctly? ;)
Thankful for any help to understand where this goes wrong, so I can do
a fix in the proper spot?
Also suggestions to where to fix this are welcome, i.e. if hack the
"libunwind.la", switch libtool version, pass some magic flag to
libtool, filter dependency checking in the RPM spec, patch the
generated "configure" or "libtool" scipt.....?
kent
Ref: http://bugs.mysql.com/bug.php?id=45706
--
Kent Boortz, Senior Production Engineer
Sun Microsystems Inc., the MySQL team
Office: +46 863 11 363
Mobile: +46 70 279 11 71
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
