Incorrect dependency on GLIBC_PRIVATE symbol, who to blame?

[Kent Boortz]

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 address@hidden (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