You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Nick Kew <ni...@webthing.com> on 2006/01/03 07:37:10 UTC
A Bloat of Libraries
Running ldd on the curent httpd on my desktop - like anywhere else -
shows an alarming number of libraries. This is IMO a Bad Thing.
In sharp contrast, httpd -l lists just the basic four "compiled in modules".
This is IMO a Good Thing.
Whenever I write a module that requires an external library, I avoid
linking to it and use LoadFile instead. This avoids the likelihood of
dependency hell with conflicting library versions and segfaults[1].
Or the confusing situation on Windows where users may have to
LoadFile zlib before they can load libxml2[2].
I'm wondering what it would take to refactor the build procedure
to avoid linking anything but a few core libraries, and substitute
a Core configuration section in httpd.conf to load them with
LoadFile instead. Obvious candidates for LoadFile include
DBM and SQL libs, SSL and crypto.
Amongst modules, we should apply the same principle: e.g.
with mod_deflate and zlib.
How about modularised dependencies as a goal for 2.4?
[1] As reported from time to time with pcre - e.g. PR#23952.
OK I didn't find any open reports of that in bugzilla, but it's a
fairly regular question on the mailinglists, and every linked
library carries its own risk.
[2] This is the single most common support question I get
regarding mod_proxy_html, and I still don't know whether it
just depends on whether they have mod_deflate, and if so
how it depends on module load order, etc.
--
Nick Kew
Re: A Bloat of Libraries
Posted by Nick Kew <ni...@webthing.com>.
On Tuesday 03 January 2006 15:13, Philip M. Gollucci wrote:
> Nick Kew wrote:
> > How about modularised dependencies as a goal for 2.4?
>
> I agree with the idea, but I don't really think theres that manu
> libraries linked in...
>
> I've got a 2.0.55 with mp2, php4, ssl, ruby, python, mod_log_sql
> using a slew of config IfDevines, each server runs only what it needs.
>
> httpd.ssl:
> libz.so.3 => /lib/libz.so.3 (0x280b6000)
> libssl.so.4 => /usr/lib/libssl.so.4 (0x280c6000)
> libcrypto.so.4 => /lib/libcrypto.so.4 (0x280f4000)
Why do any of those have to be linked rather than loaded?
> libaprutil-0.so.9 => /usr/local/lib/apache2/libaprutil-0.so.9
> (0x281e6000)
OK, that's pretty integral to it.
> libldap-2.2.so.7 => /usr/local/lib/libldap-2.2.so.7 (0x281f8000)
> liblber-2.2.so.7 => /usr/local/lib/liblber-2.2.so.7 (0x28225000)
> libdb4.so.0 => /usr/local/lib/libdb4.so.0 (0x28231000)
Again, LoadFile them!
> libexpat.so.5 => /usr/local/lib/libexpat.so.5 (0x282b7000)
> libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x282d5000)
Borderline cases I guess ...
> libapr-0.so.9 => /usr/local/lib/apache2/libapr-0.so.9 (0x283c2000)
OK, we need apr_dso linked in:-)
> libm.so.4 => /lib/libm.so.4 (0x283dc000)
> libcrypt.so.3 => /lib/libcrypt.so.3 (0x283f2000)
> libc.so.6 => /lib/libc.so.6 (0x2840a000)
> libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x284e1000)
Libsasl is surely another LoadFile. And maybe libcrypt.
--
Nick Kew
Re: A Bloat of Libraries
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Nick Kew wrote:
> How about modularised dependencies as a goal for 2.4?
I agree with the idea, but I don't really think theres that manu
libraries linked in...
I've got a 2.0.55 with mp2, php4, ssl, ruby, python, mod_log_sql
using a slew of config IfDevines, each server runs only what it needs.
httpd.ssl:
libz.so.3 => /lib/libz.so.3 (0x280b6000)
libssl.so.4 => /usr/lib/libssl.so.4 (0x280c6000)
libcrypto.so.4 => /lib/libcrypto.so.4 (0x280f4000)
libaprutil-0.so.9 => /usr/local/lib/apache2/libaprutil-0.so.9
(0x281e6000)
libldap-2.2.so.7 => /usr/local/lib/libldap-2.2.so.7 (0x281f8000)
liblber-2.2.so.7 => /usr/local/lib/liblber-2.2.so.7 (0x28225000)
libdb4.so.0 => /usr/local/lib/libdb4.so.0 (0x28231000)
libexpat.so.5 => /usr/local/lib/libexpat.so.5 (0x282b7000)
libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x282d5000)
libapr-0.so.9 => /usr/local/lib/apache2/libapr-0.so.9 (0x283c2000)
libm.so.4 => /lib/libm.so.4 (0x283dc000)
libcrypt.so.3 => /lib/libcrypt.so.3 (0x283f2000)
libc.so.6 => /lib/libc.so.6 (0x2840a000)
libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x284e1000)
------------------------------------------------------------------------
"Love is not the one you can picture yourself marrying,
but the one you can't picture the rest of your life without."
"It takes a minute to have a crush on someone, an hour to like someone,
and a day to love someone, but it takes a lifetime to forget someone..."
Philip M. Gollucci (pgollucci@p6m7g8.com) 301.254.5198
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
Re: A Bloat of Libraries
Posted by Thom May <th...@planetarytramp.net>.
* Joe Orton (jorton@redhat.com) wrote :
> On Tue, Jan 03, 2006 at 03:18:48PM -0800, Justin Erenkrantz wrote:
> > --On January 3, 2006 11:09:34 PM +0000 Nick Kew <ni...@webthing.com> wrote:
> >
> > >That is of course resolved by LoadFile /lib/libz.so, which is what I
> > >contend should be standard practice. So when another module
> > >relies on libz, there's no side effect that manifests mysteriously
> > >according to whether and when mod_deflate is loaded.
> >
> > I strongly disagree. Forcing the user to manually track all of the library
> > dependencies is insane. If someone wants to shoot themselves in the foot,
> > fine - you can do it. But, we shouldn't force everyone to fit your
> > preferred model because you want a few less libraries.
>
> Totally agreed.
>
Agreed here too.
-Thom
Re: A Bloat of Libraries
Posted by Joe Orton <jo...@redhat.com>.
On Wed, Jan 04, 2006 at 01:40:11AM -0800, Justin Erenkrantz wrote:
> On Wed, Jan 04, 2006 at 08:54:01AM +0000, Joe Orton wrote:
> > > Again, there are substantial libtool issues that come into play that limit
> > > what we can realistically do.
> >
> > I don't see any here. 2.2.x links only mod_deflate against -lz and only
> > mod_ssl against $(SSL_LIBS). The 2.0.x way only linking dependent
> > libraries into httpd is broken for the not unexpected case of having a
> > static OpenSSL build or a static libz, etc.
>
> Try to create a static mod_deflate that links against -lz. GNU libtool
> doesn't like that combination at all. (It just silently drops the -lz.)
$ make LTFLAGS=
...
gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes
-Wmissing-declarations -pthread -o httpd .libs/modules.o buildmark.o
-Wl,--export-dynamic server/.libs/libmain.a
...
modules/filters/.libs/libmod_deflate.a -lz
...
looks correct here. What platform, what version of libtool?
joe
Re: A Bloat of Libraries
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Justin Erenkrantz wrote:
> On Wed, Jan 04, 2006 at 08:54:01AM +0000, Joe Orton wrote:
>
>>>Again, there are substantial libtool issues that come into play that limit
>>>what we can realistically do.
>>
>>I don't see any here. 2.2.x links only mod_deflate against -lz and only
>>mod_ssl against $(SSL_LIBS). The 2.0.x way only linking dependent
>>libraries into httpd is broken for the not unexpected case of having a
>>static OpenSSL build or a static libz, etc.
>
>
> Try to create a static mod_deflate that links against -lz. GNU libtool
> doesn't like that combination at all. (It just silently drops the -lz.)
>
> It's the one major problem I keep running into with the 2.2 series. I keep
> having to add -lz to AP_LIBS or make mod_deflate shared. -- justin
That's the gut of it... first you aren't creating a STATIC mod_deflate, ever.
You're either creating a loadable mod_deflate module, or you are creating httpd
and it needs to bind to any of mod_deflate's dependencies as well as it's own.
Also consider OpenSSL itself, which now has ties into libz.so, either dynamic,
static (bad - because you now clash with mod_deflate), or even load on demand
(the 'ZLIB_DYNAMIC' design). I'm discovering ZLIB_DYNAMIC isn't exactly what
I wanted. I'm also discovering that the 'right thing' is probably for libssl.so
to be dynamically linked to libcrypto.so, but of course the openssl build system
is, uhm, unique :) And goes to prove the complexity of the problem you identify
--- trying to replace libtool.
More thoughts later, just wanted to record these few.
Bill
Re: A Bloat of Libraries
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Wed, Jan 04, 2006 at 08:54:01AM +0000, Joe Orton wrote:
> > Again, there are substantial libtool issues that come into play that limit
> > what we can realistically do.
>
> I don't see any here. 2.2.x links only mod_deflate against -lz and only
> mod_ssl against $(SSL_LIBS). The 2.0.x way only linking dependent
> libraries into httpd is broken for the not unexpected case of having a
> static OpenSSL build or a static libz, etc.
Try to create a static mod_deflate that links against -lz. GNU libtool
doesn't like that combination at all. (It just silently drops the -lz.)
It's the one major problem I keep running into with the 2.2 series. I keep
having to add -lz to AP_LIBS or make mod_deflate shared. -- justin
Re: A Bloat of Libraries
Posted by Joe Orton <jo...@redhat.com>.
On Tue, Jan 03, 2006 at 03:18:48PM -0800, Justin Erenkrantz wrote:
> --On January 3, 2006 11:09:34 PM +0000 Nick Kew <ni...@webthing.com> wrote:
>
> >That is of course resolved by LoadFile /lib/libz.so, which is what I
> >contend should be standard practice. So when another module
> >relies on libz, there's no side effect that manifests mysteriously
> >according to whether and when mod_deflate is loaded.
>
> I strongly disagree. Forcing the user to manually track all of the library
> dependencies is insane. If someone wants to shoot themselves in the foot,
> fine - you can do it. But, we shouldn't force everyone to fit your
> preferred model because you want a few less libraries.
Totally agreed.
> Again, there are substantial libtool issues that come into play that limit
> what we can realistically do.
I don't see any here. 2.2.x links only mod_deflate against -lz and only
mod_ssl against $(SSL_LIBS). The 2.0.x way only linking dependent
libraries into httpd is broken for the not unexpected case of having a
static OpenSSL build or a static libz, etc.
joe
Re: A Bloat of Libraries
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On January 3, 2006 11:09:34 PM +0000 Nick Kew <ni...@webthing.com> wrote:
> That is of course resolved by LoadFile /lib/libz.so, which is what I
> contend should be standard practice. So when another module
> relies on libz, there's no side effect that manifests mysteriously
> according to whether and when mod_deflate is loaded.
I strongly disagree. Forcing the user to manually track all of the library
dependencies is insane. If someone wants to shoot themselves in the foot,
fine - you can do it. But, we shouldn't force everyone to fit your
preferred model because you want a few less libraries.
Again, there are substantial libtool issues that come into play that limit
what we can realistically do.
>> SSL seems to be the worst culprit. httpd gets linked against tons
>> of stuff so that I cannot copy the binary to a non-ssl enabled host.
>
> Indeed. That principle applies equally to SQL client libs for DBD,
> to DBM libs, and somewhat even to things like expat.
Expat is brought in by apr-util, so you'd have to add dynamic loading of
expat to apr-util. In my opinion, it's a maze of twisty passages that
isn't worth the payoff. -- justin
Re: A Bloat of Libraries
Posted by Nick Kew <ni...@webthing.com>.
On Tuesday 03 January 2006 15:18, Brian Akins wrote:
> Nick Kew wrote:
> > Amongst modules, we should apply the same principle: e.g.
> > with mod_deflate and zlib.
>
> Or why not just have mod_deflate link against zlib and not have httpd do
> it.
It does that now - if built from ./configure. That gets confusing -
and has potential for segfaults - when there's some other module
or library that needs zlib.
Indeed, it's worse than that. Here's after a configure+make:
$ ldd .libs/mod_deflate.so
linux-gate.so.1 => (0xffffe000)
libz.so.1 => /lib/libz.so.1 (0xb7fc9000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb7f76000)
libc.so.6 => /lib/libc.so.6 (0xb7e5e000)
/lib/ld-linux.so.2 (0x80000000)
$ apxs -c mod_deflate.c
[chop]
$ ldd .libs/mod_deflate.so
linux-gate.so.1 => (0xffffe000)
libc.so.6 => /lib/libc.so.6 (0xb7ec1000)
/lib/ld-linux.so.2 (0x80000000)
That's a difference of *two* libs! Since libz isn't linked in httpd, we get:
# apxs -i mod_deflate.la
[chop]
# apachectl configtest
httpd: Syntax error on line 263 of /usr/local/apache/conf/httpd.conf: Cannot
load /usr/local/apache2/modules/mod_deflate.so into
server: /usr/local/apache2/modules/mod_deflate.so: undefined symbol: deflate
Ouch!
That is of course resolved by LoadFile /lib/libz.so, which is what I
contend should be standard practice. So when another module
relies on libz, there's no side effect that manifests mysteriously
according to whether and when mod_deflate is loaded.
> SSL seems to be the worst culprit. httpd gets linked against tons
> of stuff so that I cannot copy the binary to a non-ssl enabled host.
Indeed. That principle applies equally to SQL client libs for DBD,
to DBM libs, and somewhat even to things like expat.
--
Nick Kew
Re: A Bloat of Libraries
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Wed, Jan 04, 2006 at 12:12:18AM -0600, William A. Rowe, Jr. wrote:
> Justin Erenkrantz wrote:
> >
> >Nice idea, but libtool doesn't support any of this in a portable manner
> >- some OSes support DSOs having their own dependencies, a number just
> >don't.
>
> Name a few? Or one?
In my experience, most versions of GNU libtool don't do the right thing for
inter-library dependencies on Solaris or Darwin. (I've seen it barf on
Linux once or twice too.) On those platforms, it may not link the
dependency into the DSO and forces the main binary to link against the DSO
dependency when the main binary links to the first DSO's .la file. In
short, it'll usually disregard your 'cleverness' and link the binary to all
of the implicit dependencies anyway.
However, in certain circumstances, libtool will just fall over and screw
the linking process up entirely. Subversion relies upon this working in a
few cases and occassionally gets really weird error reports that have to do
with libtool screwing this step up.
If you *really* want to go make this work, be prepared to toss GNU libtool
and spend a lot of time working on a replacement to get platform parity
with GNU libtool. I think that's a really poor idea (having written a
libtool-replacement myself). -- justin
Re: A Bloat of Libraries
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Justin Erenkrantz wrote:
>
> Nice idea, but libtool doesn't support any of this in a portable manner
> - some OSes support DSOs having their own dependencies, a number just
> don't.
Name a few? Or one?
Re: A Bloat of Libraries
Posted by Brian Akins <br...@turner.com>.
Justin Erenkrantz wrote:
> If you want to completely rip apart libtool and write your own, feel
> free. Been there, done that, got the t-shirt. -- justin
This is one reason I build mod_deflate and others on its own:
apxs -cia -lz mod_deflate.c
--
Brian Akins
Lead Systems Engineer
CNN Internet Technologies
Re: A Bloat of Libraries
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On January 3, 2006 10:18:06 AM -0500 Brian Akins <br...@turner.com>
wrote:
> Nick Kew wrote:
>
>> Amongst modules, we should apply the same principle: e.g.
>> with mod_deflate and zlib.
>
> Or why not just have mod_deflate link against zlib and not have httpd do
> it. SSL seems to be the worst culprit. httpd gets linked against tons of
> stuff so that I cannot copy the binary to a non-ssl enabled host.
Nice idea, but libtool doesn't support any of this in a portable manner -
some OSes support DSOs having their own dependencies, a number just don't.
If you want to completely rip apart libtool and write your own, feel free.
Been there, done that, got the t-shirt. -- justin
Re: A Bloat of Libraries
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Brian Akins wrote:
> Nick Kew wrote:
>
>> Amongst modules, we should apply the same principle: e.g.
>> with mod_deflate and zlib.
>
>
> Or why not just have mod_deflate link against zlib and not have httpd do
> it. SSL seems to be the worst culprit. httpd gets linked against tons
> of stuff so that I cannot copy the binary to a non-ssl enabled host.
That's what I do, I'll submit a patch shortly. Similarly with other .so's,
my httpd 2.0 build links the ldap provider to mod_ldap/mod_auth_ldap, by
querying apr-util (which my 0.9 flavor splits the ldflags between core, and
added dependencies against ldap). My issue, none of this works anymore in 2.2
because libaprutil.so now needs to bind directly to libldap/liblber :(
Bill
Re: A Bloat of Libraries
Posted by Brian Akins <br...@turner.com>.
Nick Kew wrote:
> Amongst modules, we should apply the same principle: e.g.
> with mod_deflate and zlib.
Or why not just have mod_deflate link against zlib and not have httpd do
it. SSL seems to be the worst culprit. httpd gets linked against tons
of stuff so that I cannot copy the binary to a non-ssl enabled host.
--
Brian Akins
Lead Systems Engineer
CNN Internet Technologies