You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Matthias Apitz <gu...@unixarea.de> on 2014/10/22 15:13:50 UTC
GLIBC_2.10 && libapr-1.so
Hello,
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
which can not be fullfilled on older SLES 10 servers, like this:
sisis@REINERS-C-VMOH:~> uname -a
Linux REINERS-C-VMOH 2.6.16.60-0.21-default #1 Tue May 6 12:41:02 UTC 2008 x86_64 x86_64 x86_64 GNU/Linux
sisis@REINERS-C-VMOH:~> cat /etc/SuSE-release
SUSE Linux Enterprise Server 10 (x86_64)
VERSION = 10
PATCHLEVEL = 2
sisis@REINERS-C-VMOH:~> /lib/libc.so.6
GNU C Library stable release version 2.4 (20080421), by Roland McGrath et al.
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Configured for i686-suse-linux.
Compiled by GNU CC version 4.1.2 20070115 (prerelease) (SUSE Linux).
Compiled on a Linux 2.6.16 system on 2008-04-21.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
GNU libio by Per Bothner
NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
NoVersion patch for broken glibc 2.0 binaries
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
Thread-local storage support included.
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.
sisis@REINERS-C-VMOH:~> strings /lib/libc.so.6 | fgrep GLIBC
GLIBC_2.0
GLIBC_2.1
GLIBC_2.1.1
GLIBC_2.1.2
GLIBC_2.1.3
GLIBC_2.2
GLIBC_2.2.1
GLIBC_2.2.2
GLIBC_2.2.3
GLIBC_2.2.4
GLIBC_2.2.6
GLIBC_2.3
GLIBC_2.3.2
GLIBC_2.3.3
GLIBC_2.3.4
GLIBC_2.4
GLIBC_PRIVATE
Apache says on start: /lib/libc.so.6: version GLIBC_2.10 not found
(required by /usr/local/sisis-pap/apache/lib/libapr-1.so.0)
Ofc, the easy answer could be: just update the target hosts, but this is
not an option in all cases.
What makes me wonder is, that other shared objects of *our* software
produced on the same host with the same compiler, does not have this
GLIBC_2.10 requirement. I checked all our shared libs, the max is
GLIBC_2.4.
My questions are:
What make libapr-1.so requesting GLIBC_2.10?
Is this something which could be configured?
Thanks in advance
Vy 73
matthias
--
Matthias Apitz | /"\ ASCII Ribbon Campaign:
E-mail: guru@unixarea.de | \ / - No HTML/RTF in E-mail
WWW: http://www.unixarea.de/ | X - No proprietary attachments
phone: +49-170-4527211 | / \ - Respect for open standards
| en.wikipedia.org/wiki/ASCII_Ribbon_Campaign
Re: GLIBC_2.10 && libapr-1.so
Posted by Florian Weimer <fw...@deneb.enyo.de>.
* Matthias Apitz:
> Maybe it's worth to put this together into some configure value as
> --without-glibc-2.10-level or something like this...
In general, you need to build on the oldest GNU/Linux system you want
to run on anyway because newer GNU libc versions will use newer
symbols even for functionality already supported in older GNU libc
versions. Therefore, I do not think such an APR option will add much
value.
Re: GLIBC_2.10 && libapr-1.so
Posted by Matthias Apitz <gu...@unixarea.de>.
Hello Rainer,
El día Thursday, October 23, 2014 a las 04:34:51PM +0200, Rainer Jung escribió:
> Try to also set
>
> apr_cv_sock_cloexec=no
>
> Again check apr_private.h after configure for having HAVE_SOCK_CLOEXEC
> not set.
>
> Got that additional dependency from
>
> https://issues.apache.org/bugzilla/show_bug.cgi?id=47662
Thanks! With this the Apache comes up fine and serves the requests.
> What you try to achieve is not supported, so it is expected to be a bit
> of trial-and-error.
I know and I was and I am willing to work this out as trial and error.
And I highly appreciate your helping hand.
Maybe it's worth to put this together into some configure value as
--without-glibc-2.10-level or something like this...
Thanks
matthias
--
Matthias Apitz | /"\ ASCII Ribbon Campaign:
E-mail: guru@unixarea.de | \ / - No HTML/RTF in E-mail
WWW: http://www.unixarea.de/ | X - No proprietary attachments
phone: +49-170-4527211 | / \ - Respect for open standards
| en.wikipedia.org/wiki/ASCII_Ribbon_Campaign
Re: GLIBC_2.10 && libapr-1.so
Posted by Rainer Jung <ra...@kippdata.de>.
Hi Matthias,
Am 23.10.2014 um 15:02 schrieb Matthias Apitz:
> El día Thursday, October 23, 2014 a las 08:43:22AM +0200, Matthias Apitz escribió:
>
>> nm .libs/libapr-1.so.0.4.5 | egrep 'GLIBC_2.[4-9]|GLIBC_2.10'
>> U accept4@@GLIBC_2.10
>> U dup3@@GLIBC_2.9
>> U epoll_create1@@GLIBC_2.9
>>
>> With setting:
>>
>> apr_cv_accept4=no export apr_cv_accept4
>> apr_cv_dup3=no export apr_cv_dup3
>> apr_cv_epoll_create1=no export apr_cv_epoll_create1
>>
>> we have:
>>
>> nm .libs/libapr-1.so.0.4.5 | egrep 'GLIBC_2.[4-9]|GLIBC_2.10'
>> U pthread_mutex_consistent_np@@GLIBC_2.4
>> U pthread_mutexattr_setprotocol@@GLIBC_2.4
>> U pthread_mutexattr_setrobust_np@@GLIBC_2.4
>>
>> Thanks for this hint
>
> Well, it's fine that the symbols for the new calls accept4, dup3,
> epoll_create1 went away, so far so good.
>
> But the apache is unwilling to create a LISTEN on its port; it says:
>
>
> # strace -o /tmp/apa.tr -f /usr/local/sisis-pap/apache/bin/apachectl start
> [ Process PID=6864 runs in 32 bit mode. ]
> [Thu Oct 23 14:42:12 2014] [crit] (22)Invalid argument: alloc_listener: failed to get a socket for (null)
> Syntax error on line 138 of /usr/local/sisis-pap/apache/conf/httpd.conf:
> Listen setup failed
> [ Process PID=6836 runs in 64 bit mode. ]
>
> 6864 connect(3, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "::", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0
> 6864 getsockname(3, {sa_family=AF_INET6, sin6_port=htons(32772), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [8589934620]) = 0
> 6864 connect(3, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0
> 6864 connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
> 6864 getsockname(3, {sa_family=AF_INET6, sin6_port=htons(32772), inet_pton(AF_INET6, "::ffff:127.0.0.1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [8589934620]) = 0
> 6864 close(3) = 0
> 6864 socket(PF_INET6, 0x80001 /* SOCK_??? */, IPPROTO_IP) = -1 EINVAL (Invalid argument)
> 6864 socket(PF_INET, 0x80001 /* SOCK_??? */, IPPROTO_IP) = -1 EINVAL (Invalid argument)
> 6864 gettimeofday({3233802550310820, 18426497511976861723}, NULL) = 0
> 6864 open("/etc/localtime", O_RDONLY) = 3
>
> It seems a known issue, for example:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=516331
>
> The exact version is httpd-2.2.22 which brings APR 1.4.5
>
> Any idea? Thanks
Try to also set
apr_cv_sock_cloexec=no
Again check apr_private.h after configure for having HAVE_SOCK_CLOEXEC
not set.
Got that additional dependency from
https://issues.apache.org/bugzilla/show_bug.cgi?id=47662
What you try to achieve is not supported, so it is expected to be a bit
of trial-and-error.
Regards,
Rainer
Re: GLIBC_2.10 && libapr-1.so
Posted by Matthias Apitz <gu...@unixarea.de>.
El día Thursday, October 23, 2014 a las 08:43:22AM +0200, Matthias Apitz escribió:
> nm .libs/libapr-1.so.0.4.5 | egrep 'GLIBC_2.[4-9]|GLIBC_2.10'
> U accept4@@GLIBC_2.10
> U dup3@@GLIBC_2.9
> U epoll_create1@@GLIBC_2.9
>
> With setting:
>
> apr_cv_accept4=no export apr_cv_accept4
> apr_cv_dup3=no export apr_cv_dup3
> apr_cv_epoll_create1=no export apr_cv_epoll_create1
>
> we have:
>
> nm .libs/libapr-1.so.0.4.5 | egrep 'GLIBC_2.[4-9]|GLIBC_2.10'
> U pthread_mutex_consistent_np@@GLIBC_2.4
> U pthread_mutexattr_setprotocol@@GLIBC_2.4
> U pthread_mutexattr_setrobust_np@@GLIBC_2.4
>
> Thanks for this hint
Well, it's fine that the symbols for the new calls accept4, dup3,
epoll_create1 went away, so far so good.
But the apache is unwilling to create a LISTEN on its port; it says:
# strace -o /tmp/apa.tr -f /usr/local/sisis-pap/apache/bin/apachectl start
[ Process PID=6864 runs in 32 bit mode. ]
[Thu Oct 23 14:42:12 2014] [crit] (22)Invalid argument: alloc_listener: failed to get a socket for (null)
Syntax error on line 138 of /usr/local/sisis-pap/apache/conf/httpd.conf:
Listen setup failed
[ Process PID=6836 runs in 64 bit mode. ]
6864 connect(3, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "::", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0
6864 getsockname(3, {sa_family=AF_INET6, sin6_port=htons(32772), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [8589934620]) = 0
6864 connect(3, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0
6864 connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
6864 getsockname(3, {sa_family=AF_INET6, sin6_port=htons(32772), inet_pton(AF_INET6, "::ffff:127.0.0.1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [8589934620]) = 0
6864 close(3) = 0
6864 socket(PF_INET6, 0x80001 /* SOCK_??? */, IPPROTO_IP) = -1 EINVAL (Invalid argument)
6864 socket(PF_INET, 0x80001 /* SOCK_??? */, IPPROTO_IP) = -1 EINVAL (Invalid argument)
6864 gettimeofday({3233802550310820, 18426497511976861723}, NULL) = 0
6864 open("/etc/localtime", O_RDONLY) = 3
It seems a known issue, for example:
https://bugzilla.redhat.com/show_bug.cgi?id=516331
The exact version is httpd-2.2.22 which brings APR 1.4.5
Any idea? Thanks
matthias
--
Matthias Apitz | /"\ ASCII Ribbon Campaign:
E-mail: guru@unixarea.de | \ / - No HTML/RTF in E-mail
WWW: http://www.unixarea.de/ | X - No proprietary attachments
phone: +49-170-4527211 | / \ - Respect for open standards
| en.wikipedia.org/wiki/ASCII_Ribbon_Campaign
Re: GLIBC_2.10 && libapr-1.so
Posted by Matthias Apitz <gu...@unixarea.de>.
El día Wednesday, October 22, 2014 a las 07:14:43PM +0200, Rainer Jung escribió:
> 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. ...
Thanks! This was exactly the solution. And I was not aware of this
detailed tweaking of the configure process by such env vars.
Without the env vars:
nm .libs/libapr-1.so.0.4.5 | egrep 'GLIBC_2.[4-9]|GLIBC_2.10'
U accept4@@GLIBC_2.10
U dup3@@GLIBC_2.9
U epoll_create1@@GLIBC_2.9
With setting:
apr_cv_accept4=no export apr_cv_accept4
apr_cv_dup3=no export apr_cv_dup3
apr_cv_epoll_create1=no export apr_cv_epoll_create1
we have:
nm .libs/libapr-1.so.0.4.5 | egrep 'GLIBC_2.[4-9]|GLIBC_2.10'
U pthread_mutex_consistent_np@@GLIBC_2.4
U pthread_mutexattr_setprotocol@@GLIBC_2.4
U pthread_mutexattr_setrobust_np@@GLIBC_2.4
Thanks for this hint
matthias
--
Matthias Apitz | /"\ ASCII Ribbon Campaign:
E-mail: guru@unixarea.de | \ / - No HTML/RTF in E-mail
WWW: http://www.unixarea.de/ | X - No proprietary attachments
phone: +49-170-4527211 | / \ - Respect for open standards
| en.wikipedia.org/wiki/ASCII_Ribbon_Campaign
Re: GLIBC_2.10 && libapr-1.so
Posted by Rainer Jung <ra...@kippdata.de>.
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