Re: Problem building httpd 2.0.55 with openssl 0.9.8a

[Stephen Collyer <sc...@netspinner.co.uk>]

Joe Orton wrote:
> On Wed, Nov 30, 2005 at 10:05:19AM +0000, Stephen Collyer wrote:
> 
>>[Aside - I posted a similar query to the users list and got a
>>couple of suggestions but no solution, so I'm reposting here]
>>
>>In brief:
>>
>>I'm trying to build http 2.0.55 against openssl 0.9.8a.
>>
>>I've built (but not installed) a local copy of openssl, with
>>shared libraries. I've built http like this:
> 
> 
> If the previous suggestions didn't help please capture the output of 
> running configure and make from a freshly unpacked tarball and upload 
> them along with the config.log file somewhere.
> 
> joe

I've put up a tarball containing these items, along with a shell
script that does the configure and make, at:

http://www.netspinner.co.uk/Downloads/httpd_build_prob.tgz

-- 
Regards

Stephen Collyer
Netspinner Ltd

Re: Problem building httpd 2.0.55 with openssl 0.9.8a [FIXED but ...]

[Stephen Collyer <sc...@netspinner.co.uk>]

Stephen Collyer wrote:
> William A. Rowe, Jr. wrote:
> 
>> Stephen Collyer wrote:
>>
>>>
>>> OK, I've found the problem and hacked a fix for it:
>>>
> [deleted]
> 
>>
>> Did you run make install and point --with-ssl= at the install target,
>> rather than a source build?

I now understand what you mean here: did I do a "make install"
of OpenSSL ? The answer is no, and this is what was screwing it
up. All is well if OpenSSL is not only built, but installed.
I didn't realise that the "make install" changed the dir structure,
and I though I could get away with just a "make".

One caveat though - OpenSSL has to be configured with the shared
argument e.g.

> ./config --prefix=/home/stephen/apache/openssl shared

to ensure that the shared libs are built; the httpd 2.0.55
build fails otherwise.

Thanks to Joe Orton for pointing out my error.

(BTW, are problems in building Apache supposed to go this
this list or the user list ?)

-- 
Regards

Stephen Collyer
Netspinner Ltd

Re: Problem building httpd 2.0.55 with openssl 0.9.8a [FIXED but ...]

[Stephen Collyer <sc...@netspinner.co.uk>]

William A. Rowe, Jr. wrote:
> Stephen Collyer wrote:
> 
>>
>> OK, I've found the problem and hacked a fix for it:
>>
[deleted]
> 
> Did you run make install and point --with-ssl= at the install target,
> rather than a source build?

I'm not sure what you mean here by a "source build", but if you're
interested, you can download the details of what I did here:

http://www.netspinner.co.uk/Downloads/httpd_build_prob.tgz

which contains the o/p of make and config.log. However, in brief,
I built openssl 0.9.8a, ran configure with --with-ssl pointing at
the openssl tree, and ran make install.

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

Again I don't understand this. What counts as an "installed openssl" ?
Something where the libs end up in /usr/lib or somewhere standard like
that ? If so, that doesn't fit with what the configure script does, as
it explicitly looks for the openssl libs under the dir supplied to
--with-ssl.

>> 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)

[deleted]

>> 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.

Well, I'm not an Apache developer so far be it from me to
tell you what you ought to do, but I would have thought that
if --with-ssl is supplied then it's safe for something like
dtable to be linked against the static libs in that dir.
(though now I come to think of it, I can't see why dtable needs
anything from them - it's just a bunch of printfs).

-- 
Regards

Stephen Collyer
Netspinner Ltd

Re: Problem building httpd 2.0.55 with openssl 0.9.8a [FIXED but ...]

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

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 libaprutil-1.so 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 libssl.so/libcrypto.so, and we bound libssl.a/libcrypto.a to httpd, the
whole thing can choke at load time.

Bill

Re: Problem building httpd 2.0.55 with openssl 0.9.8a [FIXED but ...]

[Stephen Collyer <sc...@netspinner.co.uk>]

Stephen Collyer wrote:
> Joe Orton wrote:
> 
>> On Wed, Nov 30, 2005 at 10:05:19AM +0000, Stephen Collyer wrote:
>>
>>> [Aside - I posted a similar query to the users list and got a
>>> couple of suggestions but no solution, so I'm reposting here]
>>>
>>> In brief:
>>>
>>> I'm trying to build http 2.0.55 against openssl 0.9.8a.
>>>
>>> I've built (but not installed) a local copy of openssl, with
>>> shared libraries. I've built http like this:
>>
>>
>>
>> If the previous suggestions didn't help please capture the output of 
>> running configure and make from a freshly unpacked tarball and upload 
>> them along with the config.log file somewhere.
>>
>> joe
> 
> 
> I've put up a tarball containing these items, along with a shell
> script that does the configure and make, at:
> 
> http://www.netspinner.co.uk/Downloads/httpd_build_prob.tgz
> 

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.

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.

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.

-- 
Regards

Stephen Collyer
Netspinner Ltd