httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Hyde <>
Subject RE: [PATCH] Hide symbols to avoid namespace conflicts (take 2)
Date Tue, 03 Mar 1998 15:01:08 GMT
On Tuesday, March 03, 1998 8:54 AM, Ralf S. Engelschall
[] wrote:
> In article <34FB4FCB.B359CF5B@Golux.Com> you wrote:
> > Whoops!  Something just occurred to me - this could have nasty
> > repercussions if mod_so is used to pull in modules which were
> > linked with a different setting of -DHIDE from the core..
> Sure, another point to use HIDE=yes not as the default. It's intended
just for
> those how need to compile Apache with problematic third-party
libraries. Here
> they can easily avoid namespace conflicts by using HIDE=yes. But when
you use
> it you have to use it also for modules which are linked before or
> Or is there any possible work-around for this basic problem? I
currently don't
> know if any...

Sorry to keep picking this nit.

The right default is YES. 

Consider the symbols currently in the list: user_name, find_token,
copy_table, do_nothing, free_blocks, get_time, getword, ind, log_error,
make_table, require, satisfy, usage...

It is bogus to create a situation where the all module authors have to
compile up two 
versions of their modules if they want to reach all NT users.

This is not a rare problem for module authors.  It has appeared in this
forum like
clock work.

It is bad to treat those that have conflicts as second class citizens.
My customers
will need this facility (unless I use my fall back of rewriting the
library binary file).   If
the default is NO then they will be forced to get their copy of Apache
from me, and
won't - generally, be able to get other modules.  Recall that most of my
are on NT and don't have C compilers.

If you make the default NO, then all module builders in my shoes will

If you make the default YES then the core group of developers have to
they have to either type more characters for random symbols when
_or_ they have to build with the default modified to NO.

YES is better for the customers - both module builders and site

Again, thank you so much for fixing this problem for me!

  - ben hyde

ps. And it's so much in keeping with the tradition of #define NO_... in
the sources. :-).
"The plight at the end of the carpal tunnel may be an oncoming strain."

View raw message