httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GOMEZ Henri <hgo...@slib.fr>
Subject RE: Apache 2.0.27 and 2.0.28 RPM available
Date Sat, 24 Nov 2001 08:44:56 GMT
>> What's the problem with libtool allready present on the
>> system ? 
>
>As I mentioned to Daniel, it may not be GNU libtool.  For RH and
>Debian, it will be.  For other platforms, it may a) not even be
>GNU libtool, or b) not even be in the PATH at all (everything but
>Linux).

Yes, if you take a look a tomcat-dev for JTC, you'll see that I couldn't
build mod_webapp for Apache 2.0 with Apache 2.0 libtool, but I could
with GNU libtool. I could send you many logs of mod_jk/mod_webapp built
with system libtool and apache 2.0 generated libtool. Also I could attach
the generated libtool.

>> Which make me think about including APR, EXPAT and all
>> in Apache 2.0. 
>> 
>> Latest release (2.0.28beta) make apr, expat as shared libs.
>> Could we imagine configuring and building Apache 2.0 with 
>> apr/expat as external shared libs ie :
>> 
>> --with-apr-lib=
>> --with-apr-include=
>> 
>> --with-expat-lib=
>> --with-expat-include=
>> 
>> Could we also imagine to have expat.h and apr_*.h in 
>> expat and apr include dir ??? 
>
>I think the proper thing is trying to get proper layout 
>support into APR and APR-util.  And, we can also do that with
>expat as well and contribute back to them (Greg Stein has commit
>access to expat and can help facilitate contributions back to
>expat).
>
>I absolutely disagree with your patch for J-T-C about this.
>But, I'm not a committer there, so I am impotent.  =)

With that patch, I could make web_app start compiling on a system
where apr is not installed under $prefix. I strongly believe in APR
and I saw not reason why we should have APR installed alone on 
system, and to follow FHS it should live under /usr/lib/libapr* and
/usr/include/apr/apr_*.h. Dito for Expat...

>> I attached my spec file and also patch to make Apache 2.0 Beta28
>> more FHS compliant....
>
>Can you contribute stuff to the layout to help this?  
>
>Furthermore, most of the stuff in your patch has already been 
>committed (except for the apachectl fix which is awful to get 
>right).  Madhu submitted a change to ssl-std.conf to do the same 
>thing as your HAVE_SSL change, but instead relies on the standard
>SSL define (which apachectl passes in with -DSSL).  -- justin

Nice, does it means that I won't have to also add my defines in
ap_config.h ?

Mime
View raw message