httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: [PATCH] Allow mod_cache to be build/loaded as DSO
Date Tue, 07 Sep 2004 19:18:38 GMT
On Tue, 7 Sep 2004 14:50:50 -0400, Jim Jagielski <jim@jagunet.com> wrote:
> 
> 
> 
> On Sep 7, 2004, at 2:20 PM, Joe Orton wrote:
> 
> > On Tue, Sep 07, 2004 at 01:00:40PM -0400, Jim Jagielski wrote:
> >> True, but this is one that I'm hitting a lot, especially
> >> with the increase in cache development going on...
> >
> > Then fix your build environment, or work out how the httpd build system
> > can be improved to avoid the issue in general.  Munging the code is not
> > the answer.
> >
> >
> 
> Geez...
> 
> Here's the scenario:
> 
>     1. Build httpd
>     2. Now build mod_cache as a DSO with apxs

it doesn't have to be mod_cache

and it doesn't have to be built with apxs

it just has to be built as a DSO with gcc, and it can reference
libgcc.a symbols that weren't included in httpd and/or weren't
exported by httpd

various Apache users including myself have hit this with mod_access in
Apache 1.3 and mod_actions in Apache 2.0 (and others which I can't
remember at the moment)

>     3. Now try to load it in and run it
> 
> You'll see that this results in a dependency on libgcc.

yep

> I don't care a fig about trying to determine where libgcc
> is or what compiler flags forces libgcc or any of that
> crud. I want to avoid our modules having a dependency
> on it. And I don't care if it's "impossible" for us
> to avoid it with all the 3rd party modules out there;
> if their stuff requires libgcc to allow for it to
> be used without recompiling httpd, I couldn't care
> less. I'm only worrying about *our* stuff.
> 
> I'm certainly understand and support the POV that
> munging the code is ugly, but I can't understand
> this disregard about "so if we require it (libgcc)
> we require it..."

a critical point in deciding how to address this is that it isn't just
that line of code; maybe it is just that line of code with today's
checkout of CVS with your current level of gcc and your configure
options, but it is different line(s) of code for somebody else and
their checkout and their gcc and their configure options

so changing that line of code is no solution except maybe as your own
local modification which you can maintain until your gcc or your
checkout or your compile/configure options change sufficiently to add
a dependency elsewhere; given that, how can that source code change be
checked into CVS?

Mime
View raw message