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
