Re: HTTP proxy working for folks on 2.1-dev?

[Mladen Turk]

Jeff Trawick wrote:
[Fri Sep 03 12:05:59 2004] [error] [client 127.0.0.1] File does not
exist: proxy:http://127.0.0.1:10101/cgi-bin/printenv
If nobody can/has reproduced the problem, I'll dig into it this weekend.
I had time dig into it enough to get the feeling that it is something
that the balancer/worker folks ought to have a look at ;)  It would be
a big headstart knowing what is supposed to happen in the handler
hook.  See attached function call trace.  Does the balancer's handler
have to return OK?  Does the balancer's proxy-pre_request hook have to
return OK?
Balancer handler returns OK only if you set something like:

   SetHandler balancer-manager

It is used for dynamic balancer manager (enabling/disabling members,
changing load factors, etc...).
So, just like any handler (status, info, ...) it should return DECLINED.
pre_request hook returns OK only if the balancer is found.
Looking in the trace you've provided, it behaves just as it should,
cause it seems that you didn't define any balancer in the config,
so none is found and DECLINED is returned.
If the balancer is not found (the uri doesn't start with
proxy:balancer://) then the each particular scheme handler is called.
What is the config that you are using. Does you requests get
passed with previous version of proxy. If they do, please post the
config so we can find why is it breaking.
Regards,
MT.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Time for 1.3.32 ?

[Rasmus Lerdorf]

On Tue, 7 Sep 2004, [ISO-8859-15] André Malo wrote:
> * Jim Jagielski <[EMAIL PROTECTED]> wrote:
>
> > I'd like to propose a 1.3.32 release with a T&R either late this
> > week or early next.
>
> Sounds good.
> Though I'd like to point to the 2.0 status file, where a bugfix (to 2.0
> and 1.3) is waiting for approval :)

Could you save us some hunting and post it then?

-Rasmus

Re: HTTP proxy working for folks on 2.1-dev?

[Jeff Trawick]

On Fri, 3 Sep 2004 12:30:34 -0400, Jeff Trawick <[EMAIL PROTECTED]> wrote:
> 
> 
> On Fri, 03 Sep 2004 09:23:27 -0700, Justin Erenkrantz
> <[EMAIL PROTECTED]> wrote:
> > --On Friday, September 3, 2004 12:14 PM -0400 Jeff Trawick <[EMAIL PROTECTED]>
> > wrote:
> >
> >
> >
> > > I'm using head, with a spelling fix to mod_proxy comment (probably the
> > > cause of the breakage) and a tweak to allow proxy connect to bypass
> > > the balancer, and this silly testcase isn't working:
> > >
> > > 192.168.1.11 - - [03/Sep/2004:12:05:59 -0400] "GET
> > > http://127.0.0.1:10101/cgi-bin/printenv HTTP/1.0" 404 236
> > >
> > > error log has:
> > >
> > > [Fri Sep 03 12:05:59 2004] [error] [client 127.0.0.1] File does not
> > > exist: proxy:http://127.0.0.1:10101/cgi-bin/printenv
> 
> If nobody can/has reproduced the problem, I'll dig into it this weekend.

I had time dig into it enough to get the feeling that it is something
that the balancer/worker folks ought to have a look at ;)  It would be
a big headstart knowing what is supposed to happen in the handler
hook.  See attached function call trace.  Does the balancer's handler
have to return OK?  Does the balancer's proxy-pre_request hook have to
return OK?


handler_trace
Description: Binary data

Re: compile solaris 2.8: improper member use: response_code_strings

[brian richardson]

anyone know how in the hell i can get off these mailing lists?  they are ruining my lifesolo turn <[EMAIL PROTECTED]> wrote:
i get the following compile error with the sun forte compiler on solaris 2.8:/usr/local/httpd-2.0.50/srclib/apr/libtool --silent --mode=compile cc -g -mt -DSOLARIS2=8 -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -I/usr/local/httpd-2.0.50/srclib/apr/include-I/usr/local/httpd-2.0.50/srclib/apr-util/include-I/opt/d2svn11/include-I/usr/local/httpd-2.0.50/srclib/apr-util/xml/expat/lib -I.-I/usr/local/httpd-2.0.50/os/unix-I/usr/local/httpd-2.0.50/server/mpm/prefork-I/usr/local/httpd-2.0.50/modules/http-I/usr/local/httpd-2.0.50/modules/filters-I/usr/local/httpd-2.0.50/modules/proxy-I/usr/local/httpd-2.0.50/include-I/usr/local/httpd-2.0.50/modules/generators-I/usr/local/httpd-2.0.50/server -I/opt/d2svn11/include/openssl-I/usr/local/httpd-2.0.50/modules/dav/main -prefer-non-pic -static -ccore.c && touch
 core.lo/usr/local/httpd-2.0.50/srclib/apr/libtool --silent --mode=compile cc -g -mt -DSOLARIS2=8 -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -I/usr/local/httpd-2.0.50/srclib/apr/include-I/usr/local/httpd-2.0.50/srclib/apr-util/include-I/opt/d2svn11/include-I/usr/local/httpd-2.0.50/srclib/apr-util/xml/expat/lib -I.-I/usr/local/httpd-2.0.50/os/unix-I/usr/local/httpd-2.0.50/server/mpm/prefork-I/usr/local/httpd-2.0.50/modules/http-I/usr/local/httpd-2.0.50/modules/filters-I/usr/local/httpd-2.0.50/modules/proxy-I/usr/local/httpd-2.0.50/include-I/usr/local/httpd-2.0.50/modules/generators-I/usr/local/httpd-2.0.50/server -I/opt/d2svn11/include/openssl-I/usr/local/httpd-2.0.50/modules/dav/main -prefer-non-pic -static -cutil.c && touch util.lo"core.c", line 691: improper member use: response_code_strings"core.c", line 692: improper member use: response_code_strings"core.c", line 693: improper member use:
 response_code_strings"core.c", line 1125: improper member use: response_code_strings"core.c", line 1126: improper member use: response_code_strings"core.c", line 1127: improper member use: response_code_strings"core.c", line 1127: improper member use: response_code_strings"core.c", line 1133: improper member use: response_code_strings"core.c", line 3727: warning: statement not reached"core.c", line 3822: cannot recover from previous errorscc: acomp failed for core.cmake[2]: *** [core.lo] Error 1make[2]: *** Waiting for unfinished jobsmake[2]: Leaving directory `/usr/local/httpd-2.0.50/server'make[1]: *** [all-recursive] Error 1make[1]: Leaving directory `/usr/local/httpd-2.0.50/server'make: *** [all-recursive] Error 1what is so "improper" there?
		Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!

Re: compile solaris 2.8: improper member use: response_code_strings

[Joe Orton]

On Mon, Sep 06, 2004 at 08:57:31PM +0200, solo turn wrote:
> i get the following compile error with the sun forte compiler on solaris 2.8:
> 
> /usr/local/httpd-2.0.50/srclib/apr/libtool --silent --mode=compile cc 
> -g -mt-DSOLARIS2=8 -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT   
> -I/usr/local/httpd-2.0.50/srclib/apr/include
> -I/usr/local/httpd-2.0.50/srclib/apr-util/include
> -I/opt/d2svn11/include
...
> "core.c", line 691: improper member use: response_code_strings

Do you have headers from an old version of 2.0 installed in
/opt/d2svn11/include?  If so, try removing them first. 

joe

Re: [PATCH] Allow mod_cache to be build/loaded as DSO

[Joe Orton]

On Tue, Sep 07, 2004 at 02:50:50PM -0400, Jim Jagielski wrote:
> Here's the scenario:
> 
>1. Build httpd
>2. Now build mod_cache as a DSO with apxs
>3. Now try to load it in and run it
> 
> You'll see that this results in a dependency on libgcc.
> Do we *want* a dependency on libgcc? I don't think so.

Ah, your complaint is backwards.  Yes, you need a dependency on libgcc,
because gcc emitted a reference to a symbol from libgcc into the object
code.  There's no way round that.  But if you see an "undefined symbol"
link error that is because your module was *not* linked against libgcc.

The problem you're seeing is probably that libtool < 1.5 doesn't use
"gcc -shared" to link shared objects on Solaris, it uses ld -G directly;
the former will introduce a dependency on libgcc as desired, whereas the
latter will not, leaving you with undefined symbols in random modules
iff the httpd binary did not itself require those symbols.

The 1.3 Configure script exactly has the same issue on a few platforms
as Jeff mentioned.  If you can build 2.0 with libtool 1.5.x it should
work (modulo other libtool 1.5 issues).

(I don't know where your rant about licensing is coming from, GCC is
licensed such that linking against libgcc does not introduce any
restrictions on redistribution of the code you compiled)

joe

Re: mod_cache 2 questions

[Roy T. Fielding]

Just a thought... why does this restriction exist in the first place?
Because, a long time ago, queries contained mostly user-defined
strings that were not likely to result in a later hit, so it wasn't
worth the effort.  Now, some web applications use a bogus query
string in order to override caching because of this default behavior.
It would be fine with me to change the default, but that may result
in very inefficient caches.  It is better to default to no-cache unless
it is specifically configured or indicated (cache-control) as cacheable.
Roy

Re: [PATCH] Allow mod_cache to be build/loaded as DSO

[Jim Jagielski]

Of course, assuming any dependencies do exist, doing
a "full" build in an environment where "just"libgcc.a
exists will cause the required functions to be statically
linked in, so you avoid the external library (.so)
dependency... Still need to build mod_cache though
inline with httpd...
By the by, I *do* have an environment where no libgcc shared
libs exist, which is where I hit these. It's
an interesting testbed to use to discover these.

Re: mod_cache 2 questions

[Bill Stoddard]

Justin Erenkrantz wrote:
--On Tuesday, September 7, 2004 2:48 PM +1000 Ian Holsman 
<[EMAIL PROTECTED]> wrote:

ok.. so I've started playing with mod-cache again, and I noticed the
following:
- there is no way to cache something with query-args which doesn't return
a expires tag.
proposal: add a CacheIgnoreNoExpires directive so that we can cache them
- Even if we add a optional function to ignore the query-args, we still
   check the args to see if the thing is cacheable. I'm not sure what to
   do about this.. maybe move some more functionality into the key-gen
   code... I don't know.
any objections to adding yet another config option to mod-cache?

Not really, but I'd like to see a patch posted to this list first before 
committing it.  There's a couple ways I could see implementing this, but 
not sure which way you are intending to do this.  -- justin

Just a thought... why does this restriction exist in the first place? If it is to cover an uncommon occurance, 
perhaps we relax the restriction by default and enable the restriction with a CacheNoExpiresStrict (or 
similar) config option? Another alternative might be to apply a default expires policy and add an Expires 
header to the reply and then run the reply through mod_cache. Just thinking out loud...

Bill

Re: [PATCH] Allow mod_cache to be build/loaded as DSO

[Jim Jagielski]

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
True 'nuff... I was simply trying to indicate a quick
and dirty way to recreate the issue and show the
dependency. If you do build mod_cache at the same
time however, the libgcc dependency is "hidden"
(it still exists and, in most cases, the required
library mojo happens during the link phase so
that it gets pulled in correctly at runtime).
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?
Well... I've confirmed that with that change, we remove
that libgcc dependency for the singular case of the
code not requiring __floatdidf :)
Yes, I agree that the issue is deeper and that doing
these line-by-line hacks will likely be more
trouble than they are worth (eventually) but what
disturbed me (as mentioned) was the "yeah, so
what" attitude. Kind of defeats the whole purpose
of httpd being licensed the way it is, and
allowing companies like RedHat and Covalent and
IBM to redistribute it if the resulting code
results in dependencies that circumvent the
desire of LICENSE.
I'm not gung-ho about the patch; I am gung-ho
about the *reason* for the patch. ;)

Re: [PATCH] Allow mod_cache to be build/loaded as DSO

[Jeff Trawick]

On Tue, 7 Sep 2004 14:50:50 -0400, Jim Jagielski <[EMAIL PROTECTED]> 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?

Re: mod_cache 2 questions

[Justin Erenkrantz]

--On Tuesday, September 7, 2004 2:48 PM +1000 Ian Holsman 
<[EMAIL PROTECTED]> wrote:

ok.. so I've started playing with mod-cache again, and I noticed the
following:
- there is no way to cache something with query-args which doesn't return
a expires tag.
proposal: add a CacheIgnoreNoExpires directive so that we can cache them
- Even if we add a optional function to ignore the query-args, we still
   check the args to see if the thing is cacheable. I'm not sure what to
   do about this.. maybe move some more functionality into the key-gen
   code... I don't know.
any objections to adding yet another config option to mod-cache?
Not really, but I'd like to see a patch posted to this list first before 
committing it.  There's a couple ways I could see implementing this, but 
not sure which way you are intending to do this.  -- justin

Re: [PATCH] Allow mod_cache to be build/loaded as DSO

[Jim Jagielski]

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
   3. Now try to load it in and run it
You'll see that this results in a dependency on libgcc.
Do we *want* a dependency on libgcc? I don't think so.
And from what I can tell, it's only this area of code
with our bundled module that causes it.
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..."

compile solaris 2.8: improper member use: response_code_strings

[solo turn]

i get the following compile error with the sun forte compiler on solaris 2.8:

/usr/local/httpd-2.0.50/srclib/apr/libtool --silent --mode=compile cc 
-g -mt-DSOLARIS2=8 -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT   
-I/usr/local/httpd-2.0.50/srclib/apr/include
-I/usr/local/httpd-2.0.50/srclib/apr-util/include
-I/opt/d2svn11/include
-I/usr/local/httpd-2.0.50/srclib/apr-util/xml/expat/lib -I.
-I/usr/local/httpd-2.0.50/os/unix
-I/usr/local/httpd-2.0.50/server/mpm/prefork
-I/usr/local/httpd-2.0.50/modules/http
-I/usr/local/httpd-2.0.50/modules/filters
-I/usr/local/httpd-2.0.50/modules/proxy
-I/usr/local/httpd-2.0.50/include
-I/usr/local/httpd-2.0.50/modules/generators
-I/usr/local/httpd-2.0.50/server -I/opt/d2svn11/include/openssl
-I/usr/local/httpd-2.0.50/modules/dav/main -prefer-non-pic -static -c
core.c && touch core.lo
/usr/local/httpd-2.0.50/srclib/apr/libtool --silent --mode=compile cc 
-g -mt-DSOLARIS2=8 -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT   
-I/usr/local/httpd-2.0.50/srclib/apr/include
-I/usr/local/httpd-2.0.50/srclib/apr-util/include
-I/opt/d2svn11/include
-I/usr/local/httpd-2.0.50/srclib/apr-util/xml/expat/lib -I.
-I/usr/local/httpd-2.0.50/os/unix
-I/usr/local/httpd-2.0.50/server/mpm/prefork
-I/usr/local/httpd-2.0.50/modules/http
-I/usr/local/httpd-2.0.50/modules/filters
-I/usr/local/httpd-2.0.50/modules/proxy
-I/usr/local/httpd-2.0.50/include
-I/usr/local/httpd-2.0.50/modules/generators
-I/usr/local/httpd-2.0.50/server -I/opt/d2svn11/include/openssl
-I/usr/local/httpd-2.0.50/modules/dav/main -prefer-non-pic -static -c
util.c && touch util.lo
"core.c", line 691: improper member use: response_code_strings
"core.c", line 692: improper member use: response_code_strings
"core.c", line 693: improper member use: response_code_strings
"core.c", line 1125: improper member use: response_code_strings
"core.c", line 1126: improper member use: response_code_strings
"core.c", line 1127: improper member use: response_code_strings
"core.c", line 1127: improper member use: response_code_strings
"core.c", line 1133: improper member use: response_code_strings
"core.c", line 3727: warning: statement not reached
"core.c", line 3822: cannot recover from previous errors
cc: acomp failed for core.c
make[2]: *** [core.lo] Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: Leaving directory `/usr/local/httpd-2.0.50/server'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/local/httpd-2.0.50/server'
make: *** [all-recursive] Error 1

what is so "improper" there?

Re: [PATCH] Allow mod_cache to be build/loaded as DSO

[Jeff Trawick]

On Tue, 07 Sep 2004 11:14:46 -0700, Justin Erenkrantz
<[EMAIL PROTECTED]> wrote:
> --On Tuesday, September 7, 2004 2:06 PM -0400 Jeff Trawick
> <[EMAIL PROTECTED]> wrote:
> 
> > Won't gcc 3.2+ have dynamic reference to libgcc_s.so instead of static
> > reference to libgcc.a?
> 
> gcc 3.3 on Mac OS X and gcc 3.4.0 (stock) on Solaris both refer to libgcc.a.
> 
> *shrug*

hrm...  we've had folks complain^H^H^H^H^H^H^H^Hnotice before that gcc
3.2 on Solaris referenced the .so and that if they copied libgcc_s.so
along with their Apache binaries it would run on another box

> > gcc < 3 will have static reference to libgcc.a too, but no
> > -print-libgcc-file-name option :(
> 
> Well, not sure what we can do 'bout that.

check

> > Based on Joe's comment, this stuff depends on how gcc was built.
> 
> It's better to try to figure this out than greatly obfuscate our code to
> work around a bug in one compiler.

agreed 100%; I'm just trying to understand what the pattern is, if
indeed there is one that can be instantiated in our configure logic

the alternative is something in a readme that tells how to build
Apache so that libgcc.a gets linked into DSOs automaticaly and/or what
it means if httpd or some module fails to load because libgcc_s.so
can't be found

Re: Time for 1.3.32 ?

[André Malo]

* Jim Jagielski <[EMAIL PROTECTED]> wrote:

> I'd like to propose a 1.3.32 release with a T&R either late this
> week or early next.

Sounds good.
Though I'd like to point to the 2.0 status file, where a bugfix (to 2.0
and 1.3) is waiting for approval :)

nd
-- 
"Solides und umfangreiches Buch"
  -- aus einer Rezension

Re: [PATCH] Allow mod_cache to be build/loaded as DSO

[Joe Orton]

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.

joe

Re: [PATCH] Allow mod_cache to be build/loaded as DSO

[Jim Jagielski]

> 
> It's better to try to figure this out than greatly obfuscate our code to 
> work around a bug in one compiler.  So, I think our option is to try to 
> figure what gcc-magic we need to call to get this right or just ignore it.
> 

It's worth it, IMO, to avoid redistribution dependencies on gcc totally
however.

-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  "A society that will trade a little liberty for a little order
 will lose both and deserve neither" - T.Jefferson

Re: [PATCH] Allow mod_cache to be build/loaded as DSO

[Justin Erenkrantz]

--On Tuesday, September 7, 2004 2:06 PM -0400 Jeff Trawick 
<[EMAIL PROTECTED]> wrote:

Won't gcc 3.2+ have dynamic reference to libgcc_s.so instead of static
reference to libgcc.a?
gcc 3.3 on Mac OS X and gcc 3.4.0 (stock) on Solaris both refer to libgcc.a.
*shrug*
gcc < 3 will have static reference to libgcc.a too, but no
-print-libgcc-file-name option :(
Well, not sure what we can do 'bout that.
Based on Joe's comment, this stuff depends on how gcc was built.
It's better to try to figure this out than greatly obfuscate our code to 
work around a bug in one compiler.  So, I think our option is to try to 
figure what gcc-magic we need to call to get this right or just ignore it.

FWIW, I apply custom patches to the gcc specs file to work around this 
complete insanity.  -- justin

Time for 1.3.32 ?

[Jim Jagielski]

I'd like to propose a 1.3.32 release with a T&R either late this
week or early next.
There's enough changes to warrant it I think. In the meantime,
if people could test HEAD, that would be great! Especially
those hit by the mod_dav/mod_frontpage problems that
surfaced with 1.3.31.

Re: [PATCH] backport static module checking in mod_so to 1.3

[Rasmus Lerdorf]

On Tue, 7 Sep 2004, Geoffrey Young wrote:
> the attached patch is a direct port of the logic from 2.0 to 1.3.  thoughts
> or insights on why this wouldn't be a good idea for 1.3 or other feedback
> appreciated.

Seems like a good idea to me.

-Rasmus

Re: [PATCH] Allow mod_cache to be build/loaded as DSO

[Jeff Trawick]

On Tue, 07 Sep 2004 10:41:44 -0700, Justin Erenkrantz
<[EMAIL PROTECTED]> wrote:
> --On Tuesday, September 7, 2004 1:00 PM -0400 Jim Jagielski
> <[EMAIL PROTECTED]> wrote:
> 
> > True, but this is one that I'm hitting a lot, especially
> > with the increase in cache development going on...
> >
> > And this is the only bundled module that I've hit this on
> > when httpd is build "normally".
> 
> IMHO, the proper thing to do is add `gcc -print-libgcc-file-name` to the
> shared module builds when we're using gcc 3+.  -- justin

Won't gcc 3.2+ have dynamic reference to libgcc_s.so instead of static
reference to libgcc.a?

gcc < 3 will have static reference to libgcc.a too, but no
-print-libgcc-file-name option :(

Based on Joe's comment, this stuff depends on how gcc was built.

Re: [PATCH] Allow mod_cache to be build/loaded as DSO

[Justin Erenkrantz]

--On Tuesday, September 7, 2004 1:00 PM -0400 Jim Jagielski 
<[EMAIL PROTECTED]> wrote:

True, but this is one that I'm hitting a lot, especially
with the increase in cache development going on...
And this is the only bundled module that I've hit this on
when httpd is build "normally".
IMHO, the proper thing to do is add `gcc -print-libgcc-file-name` to the 
shared module builds when we're using gcc 3+.  -- justin

Re: [PATCH] Allow mod_cache to be build/loaded as DSO

[Jim Jagielski]

Jeff Trawick wrote:
> 
> 
> Get a different compiler?  Look for some gcc option to cause it to
> generate different code?
> 

This all presumes that you're building httpd knowing in advance
that you'll be building mod_cache via apxs later (in which
case, if you know that, then why bother) ). I was simply
hoping to make mod_cache more ignorant and less-dependent
on how httpd was built.

-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  "A society that will trade a little liberty for a little order
 will lose both and deserve neither" - T.Jefferson

Re: [PATCH] Allow mod_cache to be build/loaded as DSO

[Jim Jagielski]

True, but this is one that I'm hitting a lot, especially
with the increase in cache development going on...

And this is the only bundled module that I've hit this on
when httpd is build "normally".

Joe Orton wrote:
> 
> On Tue, Sep 07, 2004 at 10:03:39AM -0400, Jim Jagielski wrote:
> > Jeff Trawick wrote:
> > > If you add libgcc.a into any DSO, wouldn't that take care of the
> > > issue?  (does the SH_LIBS variable allow you to specify extra
> > > libraries that should be linked into DSOs?)
> > 
> > I'm thinking specifically about preventing the dependency on libgcc.
> > Important for those who bundle/redistribute httpd :)
> 
> You can't second guess when you'll introduce a dependency on libgcc
> especially with all the 64-bit arithmetic using apr_time_t.  Build GCC
> without a shared libgcc and you can be sure to avoid any extra run-time
> dependency, of course.
> 
> joe
> 


-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  "A society that will trade a little liberty for a little order
 will lose both and deserve neither" - T.Jefferson

Re: [PATCH] Allow mod_cache to be build/loaded as DSO

[Joe Orton]

On Tue, Sep 07, 2004 at 10:03:39AM -0400, Jim Jagielski wrote:
> Jeff Trawick wrote:
> > If you add libgcc.a into any DSO, wouldn't that take care of the
> > issue?  (does the SH_LIBS variable allow you to specify extra
> > libraries that should be linked into DSOs?)
> 
> I'm thinking specifically about preventing the dependency on libgcc.
> Important for those who bundle/redistribute httpd :)

You can't second guess when you'll introduce a dependency on libgcc
especially with all the 64-bit arithmetic using apr_time_t.  Build GCC
without a shared libgcc and you can be sure to avoid any extra run-time
dependency, of course.

joe

Re: [PATCH] Allow mod_cache to be build/loaded as DSO

[Jeff Trawick]

On Tue, 7 Sep 2004 10:03:39 -0400 (EDT), Jim Jagielski <[EMAIL PROTECTED]> wrote:
> 
> 
> Jeff Trawick wrote:
> >
> > On Tue, 7 Sep 2004 09:10:45 -0400, Jim Jagielski <[EMAIL PROTECTED]> wrote:
> > > I've noticed that if you build httpd normally (with DSO capability)
> > > and then use apxs to try to build mod_cache, then when you try
> > > to run the server you get:
> > >
> > >mod_cache.so: symbol __floatdidf: referenced symbol not found
> > >
> > > This is due to the fact that the required math functions to do some
> > > date calcs aren't available since when httpd was initially built,
> > > there was no need. It also means there are some dependencies
> > > issues which might be best to be avoided (libgcc for example).
> >
> > This gcc-specific issue can happen in various places (e.g., 1.3's
> > mod_access on AIX).  It is a losing battle to modify web server code
> > to work around this instead of providing the ability to link libgcc
> > into the right places.
> >
> > If you add libgcc.a into any DSO, wouldn't that take care of the
> > issue?  (does the SH_LIBS variable allow you to specify extra
> > libraries that should be linked into DSOs?)
> >
> 
> I'm thinking specifically about preventing the dependency on libgcc.
> Important for those who bundle/redistribute httpd :)

Get a different compiler?  Look for some gcc option to cause it to
generate different code?

[PATCH] backport static module checking in mod_so to 1.3

[Geoffrey Young]

hi all.

in 2.0 mod_so checks a given LoadModule statement against both static
modules and those previously loaded by LoadModule.  in 1.3 it checks only
against those loaded with LoadModule, leaving open the possibility that
someone will try to dynamically load a module that is already compiled into
the server.

the attached patch is a direct port of the logic from 2.0 to 1.3.  thoughts
or insights on why this wouldn't be a good idea for 1.3 or other feedback
appreciated.

--Geoff
Index: src/modules/standard/mod_so.c
===
RCS file: /home/cvs/apache-1.3/src/modules/standard/mod_so.c,v
retrieving revision 1.42
diff -u -r1.42 mod_so.c
--- src/modules/standard/mod_so.c	20 Feb 2004 20:38:27 -	1.42
+++ src/modules/standard/mod_so.c	7 Sep 2004 13:57:18 -
@@ -182,6 +182,7 @@
 /* 
  * check for already existing module
  * If it already exists, we have nothing to do 
+ * Check both dynamically-loaded modules and statically-linked modules.
  */
 sconf = (so_server_conf *)ap_get_module_config(cmd->server->module_config, 
 	&so_module);
@@ -194,6 +195,45 @@
 return NULL;
 }
 }
+
+for (i = 0; ap_preloaded_modules[i]; i++) {
+const char *preload_name;
+size_t preload_len;
+size_t thismod_len;
+
+modp = ap_preloaded_modules[i];
+
+/* make sure we're comparing apples with apples
+ * make sure name of preloaded module is mod_FOO.c
+ * make sure name of structure being loaded is FOO_module
+ */
+
+if (memcmp(modp->name, "mod_", 4)) {
+continue;
+}
+
+preload_name = modp->name + strlen("mod_");
+preload_len = strlen(preload_name) - 2;
+
+if (strlen(modname) <= strlen("_module")) {
+continue;
+}
+thismod_len = strlen(modname) - strlen("_module");
+if (strcmp(modname + thismod_len, "_module")) {
+continue;
+}
+
+if (thismod_len != preload_len) {
+continue;
+}
+
+if (!memcmp(modname, preload_name, preload_len)) {
+return ap_pstrcat(cmd->pool, "module ", modname,
+  " is built-in and can't be loaded",
+  NULL);
+}
+}
+
 modi = ap_push_array(sconf->loaded_modules);
 modi->name = modname;
 

Re: [PATCH] Allow mod_cache to be build/loaded as DSO

[Jim Jagielski]

Jeff Trawick wrote:
> 
> On Tue, 7 Sep 2004 09:10:45 -0400, Jim Jagielski <[EMAIL PROTECTED]> wrote:
> > I've noticed that if you build httpd normally (with DSO capability)
> > and then use apxs to try to build mod_cache, then when you try
> > to run the server you get:
> > 
> >mod_cache.so: symbol __floatdidf: referenced symbol not found
> > 
> > This is due to the fact that the required math functions to do some
> > date calcs aren't available since when httpd was initially built,
> > there was no need. It also means there are some dependencies
> > issues which might be best to be avoided (libgcc for example).
> 
> This gcc-specific issue can happen in various places (e.g., 1.3's
> mod_access on AIX).  It is a losing battle to modify web server code
> to work around this instead of providing the ability to link libgcc
> into the right places.
> 
> If you add libgcc.a into any DSO, wouldn't that take care of the
> issue?  (does the SH_LIBS variable allow you to specify extra
> libraries that should be linked into DSOs?)
> 

I'm thinking specifically about preventing the dependency on libgcc.
Important for those who bundle/redistribute httpd :)

-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  "A society that will trade a little liberty for a little order
 will lose both and deserve neither" - T.Jefferson

Re: [PATCH] Allow mod_cache to be build/loaded as DSO

[Jeff Trawick]

On Tue, 7 Sep 2004 09:10:45 -0400, Jim Jagielski <[EMAIL PROTECTED]> wrote:
> I've noticed that if you build httpd normally (with DSO capability)
> and then use apxs to try to build mod_cache, then when you try
> to run the server you get:
> 
>mod_cache.so: symbol __floatdidf: referenced symbol not found
> 
> This is due to the fact that the required math functions to do some
> date calcs aren't available since when httpd was initially built,
> there was no need. It also means there are some dependencies
> issues which might be best to be avoided (libgcc for example).

This gcc-specific issue can happen in various places (e.g., 1.3's
mod_access on AIX).  It is a losing battle to modify web server code
to work around this instead of providing the ability to link libgcc
into the right places.

If you add libgcc.a into any DSO, wouldn't that take care of the
issue?  (does the SH_LIBS variable allow you to specify extra
libraries that should be linked into DSOs?)

[PATCH] Allow mod_cache to be build/loaded as DSO

[Jim Jagielski]

I've noticed that if you build httpd normally (with DSO capability)
and then use apxs to try to build mod_cache, then when you try
to run the server you get:

   mod_cache.so: symbol __floatdidf: referenced symbol not found

This is due to the fact that the required math functions to do some
date calcs aren't available since when httpd was initially built,
there was no need. It also means there are some dependencies
issues which might be best to be avoided (libgcc for example).

Anyway, this patch gets around it by breaking the calculations
into separate steps, keeping the result within normal bounds.

Index: modules/experimental/mod_cache.c
===
RCS file: /home/cvs/httpd-2.0/modules/experimental/mod_cache.c,v
retrieving revision 1.89
diff -u -r1.89 mod_cache.c
--- modules/experimental/mod_cache.c17 Aug 2004 16:34:51 -  1.89
+++ modules/experimental/mod_cache.c7 Sep 2004 13:05:17 -
@@ -683,7 +683,14 @@
  *   freshness calculations, so we choose the else path...
  */
 if ((lastmod != APR_DATE_BAD) && (lastmod < date)) {
-apr_time_t x = (apr_time_t) ((date - lastmod) * conf->factor);
+apr_time_t x;
+long diff;
+diff = (date - lastmod);
+diff = diff * conf->factor;
+x = diff;
+/*
+ apr_time_t x = (apr_time_t) ((date - lastmod) * conf->factor);
+*/
 
 if (x > conf->maxex) {
 x = conf->maxex;