httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: Problem building httpd 2.0.55 with openssl 0.9.8a [FIXED but ...]
Date Mon, 05 Dec 2005 16:58:44 GMT
Stephen Collyer wrote:
> OK, I've found the problem and hacked a fix for it:
> If you configure with, say, a --with-ssl=/somedir/openssl, then
> the httpd 2.0.55 configure script assumes that openssl builds
> its libraries into /somedir/openssl/lib. (see configure scripts
> lines 10726 ff). However, in the case of openssl 0.9.8a at least,
> the libraries go into /somedir/openssl. I've fixed this by creating
> the appropriate lib /somedir/openssl/lib directory and putting the
> libraries there, but it looks like a clash between openssl and
> Apache - one or other has to change to fix it properly.

Did you run make install and point --with-ssl= at the install target,
rather than a source build?

It would be interesting to support either, but at present we only
support building against an installed openssl from unix.

> I've now run into another problem: the build falls over when compiling
> srclib/pcre/pcre.c:
>> pcre.c:2545: error: `pcre_default_tables' undeclared (first use in 
>> this function)
> I've also fixed this: it was occurring because the build process
> runs the dftable exe to generate chartables.c, but chartables.c
> was empty; it was empty because dftable was linked against a couple
> of openssl libraries it couldn't find, though I don't know why.

It's actually pretty schlocky that we link every library to every
module and binary from httpd, including intermediate (code generation)
binaries.  This can be fixed, in fact I've used a hack around this for
years, and I'll re-present it to the list for consideration.  (Half of
my hack, though, is invalidated by the binding to the
libldap, which may then be bound to libssl, so in fact my patch might
prove altogether useless in practice for 2.2.)

> The fix is to add /somedir/openssl/lib to LD_LIBRARY_PATH before
> running the build. This is a local hack of course, and I guess
> this too needs a proper fix, but I don't know why the linking of
> dtable is screwed up so I can't suggest one. I would have thought that
> dtable should be linked against whatever -with-ssl points to, but
> this doesn't seem to be happening.

Well, either your solution (using LIBRARY_PATH on aix and SHLIB_PATH
on HP/UX 32 bit) - or linking to a static libssl.a/libcrypto.a would help.
It would not be good for the main binary httpd to link to these, since there
would result many symbol clashes, later.  But we have the concept of static
support binaries, and the autoconf script we use for openssl could resolve
these gen_test_char-type issues by following the pattern of static support.

Of course there are other places, e.g. apxs, where we might be invoking httpd
and it, too, needs these library paths to be set up correctly.  httpd is
different than support, or code generation binary tools, because we can load
any number of modules in, and if one of these has an incidental linkage to the
system, and we bound libssl.a/libcrypto.a to httpd, the
whole thing can choke at load time.


View raw message