Building mod_deflate against libz.a (static)

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Group,

  One thing we seem to be missing in most of our modules is the
ability to link against static libraries, especially those which are
used within a single module (and are therefore good candidates 
for building and linking against statically.)

  Attached is a trivial patch that looks at the contents of zlib_base/lib
to make this determination.  It then adds the libz.a to the objects list
to build mod_deflate, provided we don't recognize the shlib extension.
This is not 100% portable behavior, but very useful on the majority of
platforms which support it.  For simplicity, I don't pull -lz from this list
in this case, and that apparently is not a problem.

  The only line I don't like is;

+    if test -f $ap_zlib_base/lib/libz.s?; then

  which presupposes that .so/.sl is the shared flavor.  Three options,
one is to add a check for .dyld (???) on OSX and .dll on Win32.  Second
option is to reverse the test to '!' -f $ap_zlib_base/lib/libz.a';.  It seems
like the third option would be best, though - look for the platform shlib
extension from the $ac_{???} variable defining this platforms shlib ext.

  I'm guessing M4/AC can somehow tell us that, but I would appreciate
a pointer to an example or macro.  Thanks.

  This patch should apply well to APACHE_2_0_BRANCH, haven't tested
HEAD just yet.

Bill 

Re: Building mod_deflate against libz.a (static)

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

At 09:04 AM 5/19/2003, Jeff Trawick wrote:
>William A. Rowe, Jr. wrote:
>
>>  Attached is a trivial patch that looks at the contents of zlib_base/lib
>>to make this determination.  It then adds the libz.a to the objects list
>>to build mod_deflate, provided we don't recognize the shlib extension.
>>This is not 100% portable behavior, but very useful on the majority of
>>platforms which support it.
>
>Which part of your patch prevents this from happening on the platforms 
>that don't support it?  (ISTR static linking of zlib with mod_deflate not doing 
>the right thing on HP-UX.)
>
>Does it break normal users to do it the portable way?

I'm quoting the comments from libtool, which state

*** Warning: Linking the shared library mod_include.la against the 
*** static library /usr/local/lib/zlib/libz.a is not portable!

... but everything seems fine to me on hpux, linux and solaris; the objects
from libz.a are definately included according to strings mod_deflate.so
(and based on observing the file size.)  This might actually be screaming
about the -lz and not the libz.a item in the objects list.

Without the patch - (on libtool 1.4.2) I see a smaller module which attempts
(fatally) to use libz.a as a shared library, although I built zlib static.

I don't see any harm to the patch (provided we decide how to determine 
if libz.a should be in the object list or as an -lz, e.g. what filename patterns).
But I'm also in no rush to throw it over the wall into 2.0.46 either.

Bill

Re: Building mod_deflate against libz.a (static)

[Jeff Trawick <tr...@attglobal.net>]

William A. Rowe, Jr. wrote:

>   Attached is a trivial patch that looks at the contents of zlib_base/lib
> to make this determination.  It then adds the libz.a to the objects list
> to build mod_deflate, provided we don't recognize the shlib extension.
> This is not 100% portable behavior, but very useful on the majority of
> platforms which support it.

Which part of your patch prevents this from happening on the platforms 
that don't support it?  (ISTR static linking of zlib with mod_deflate 
not doing the right thing on HP-UX.)

Does it break normal users to do it the portable way?