Am 22.10.2014 um 15:13 schrieb Matthias Apitz:
We compile and deliver to our customers in a large Library Project an
Apache and the libapr-1.so, among other stuff.
The compilation is done on our production Linux box:
guru@srap08dxoh:~/apr-1.5.1> uname -a
Linux srap08dxoh 3.0.76-0.11-pae #1 SMP Fri Jun 14 08:21:43 UTC 2013 (ccab990)
i686 athlon i386 GNU/Linux
with GCC:
guru@srap08dxoh:~/apr-1.5.1> gcc -v
Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3
--enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap
--with-slibdir=/lib --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --program-suffix=-4.3
--enable-linux-futex --without-system-libunwind --with-cpu=generic
--build=i586-suse-linux
Thread model: posix
gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux)
After compilation the share library contains an request for GLIBC_2.10:
guru@srap08dxoh:~/apr-1.5.1> strings .libs/libapr-1.so.0.5.1 | fgrep GLIBC
GLIBC_2.1
GLIBC_2.0
GLIBC_2.3.2
GLIBC_2.2
GLIBC_2.1.3
GLIBC_2.10
GLIBC_2.9
GLIBC_2.3.3
GLIBC_2.1.2
GLIBC_2.3
GLIBC_2.1.1
GLIBC_2.4
Start with a more informative command:
nm libapr-1.so.0.5.1 | grep GLIBC
This will show you which symbol is taken with which version from GLIBC.
Let us know the result, especially the 2.10 ones.
I don't get any 2.10 dependencies for a 32 Bit SLES 10 system (with old
patch levels), but I do get a 2.10 dependency on SLES 11, namely for
accept4@@GLIBC_2.10
Presence of the function accept4() is checked by configure and noted via
HAVE_ACCEPT4 in include/arch/unix/apr_private.h. If it is found it is
used in network_io/unix/sockets.c.
You can overwrite the configure check (thus disabling the use of
accept4()) via exporting an environment variable named apr_cv_accept4
with value "no" before running configure.
The result of the accept4() check in configure is logged in config.log.
you can check for the result via
% grep apr_cv_accept4 config.log
apr_cv_accept4=no
% grep HAVE_ACCEPT4 include/arch/unix/apr_private.h
/* #undef HAVE_ACCEPT4 */
Whether in your case it actually is accept4() which is the problem or
something else can be checked using the above nm command.
Regards,
Rainer
