You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by hiten pandya <hp...@lycos.co.uk> on 2001/10/07 16:28:04 UTC

DSO

greetings,

i am trying to fix the problem regarding:

adding a LoadModule directive when user selects any module 
as a DSO.

When i was going throught the configure script, it had two 
lines like the following:

ac_help="$ac_help
 --enable-so DSO capability"
ac_help="$ac_help
 --enable-so DSO capability"

Can someone please explain me why there is a need for two 
of them lines. I didnt know if there was a need to submit 
a patch for this.

thank You,

Greetings

Hiten Pandya


Hiten Pandya
hpandya@lycos.co.uk

Reply-To:
hpandya@lycos.co.uk
______________________________________________________
Free E-mail - Lycos UK - http://www.lycos.co.uk
Get your domain for £9.90 - http://lycos.uk.domainnames.com/default.asp?caller=lycos_ef
Play now to win £1 Million - http://ad.uk.doubleclick.net/clk;3386758;6457074;y?http://www.thedailydraw.com/mainframe.cfm?source=lycos

Re: [PATCH] enable mod_so by default [Was: DSO]

Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Tue, Oct 09, 2001 at 10:55:44AM -0700, Aaron Bannert wrote:
> I think this patch would do that. One should be able to do --disable-so
> to turn it off, and by default it will be built.
> 
> My only worry is that this will break out-of-the-box builds for platforms
> that aren't supported under apr_dso.h. Are any of our apache-supported
> platforms not supported under apr_dso.h?

Committed with an additional APR_HAS_DSO check which should resolve
the above concern.  Please verify that I didn't do something 
stupid.  =)

Thanks.  -- justin

Re: [PATCH] enable mod_so by default [Was: DSO]

Posted by Cliff Woolley <cl...@yahoo.com>.
On Tue, 9 Oct 2001, Aaron Bannert wrote:

> I think this patch would do that. One should be able to do --disable-so
> to turn it off, and by default it will be built.
>
> My only worry is that this will break out-of-the-box builds for platforms
> that aren't supported under apr_dso.h. Are any of our apache-supported
> platforms not supported under apr_dso.h?

-0 ... I think the minimal default build should be a set of modules that
can be considered tight, reliable, and secure.  mod_so doesn't fit that
bill IMO, not because of its implementation but just the whole loadable
module concept.  Maybe that's just me, but I doubt it...

--Cliff

--------------------------------------------------------------
   Cliff Woolley
   cliffwoolley@yahoo.com
   Charlottesville, VA

[PATCH] enable mod_so by default [Was: DSO]

Posted by Aaron Bannert <aa...@clove.org>.
On Tue, Oct 09, 2001 at 07:15:26AM -0400, Jeff Trawick wrote:
> It sounds reasonable to me to build mod_so by default, but I think
> that the builder should be able to turn off mod_so.
> 
> Somebody putting together a package for distribution/support ought to
> be able to decide what modules they are willing to deal with, and
> mod_so opens up everything.  I doubt that a commercial vendor would
> make such a decision, but certainly within an organization it might
> make sense.  I bet a lot of companies would like a build of IIS to
> put on their employees' machines which could not be made to do
> anything other than serve static pages :)

I think this patch would do that. One should be able to do --disable-so
to turn it off, and by default it will be built.

My only worry is that this will break out-of-the-box builds for platforms
that aren't supported under apr_dso.h. Are any of our apache-supported
platforms not supported under apr_dso.h?

-aaron


Index: modules/mappers/config9.m4
===================================================================
RCS file: /home/cvspublic/httpd-2.0/modules/mappers/config9.m4,v
retrieving revision 1.5
diff -u -r1.5 config9.m4
--- modules/mappers/config9.m4	2001/10/03 17:47:51	1.5
+++ modules/mappers/config9.m4	2001/10/09 17:48:21
@@ -17,11 +17,8 @@
   APR_ADDTO(CFLAGS,-DNO_DBM_REWRITEMAP)
 ])
 
-if test "$sharedobjs" = "yes"; then
-    APACHE_MODULE(so, DSO capability, , , static)
-else
-    APACHE_MODULE(so, DSO capability, , , no)
-fi
+APACHE_MODULE(so, DSO capability, , , static)
+
 dnl ### why save the cache?
 AC_CACHE_SAVE

Re: DSO

Posted by Jeff Trawick <tr...@attglobal.net>.
Justin Erenkrantz <je...@ebuilt.com> writes:

> On Sun, Oct 07, 2001 at 08:31:16AM -0700, Aaron Bannert wrote:
> > I propose we simply get rid of the "if test" in the above code snippit,
> > and default to "static" for mod_so, since by default we have some
> > modules already turned on.  Alternatively we could default to "no"
> > and simply set "enable_so=yes" as soon as any APACHE_MODULE call ends
> > in something non-"no".
> 
> Well, I'm kind of thinking we should always build mod_so.  I've run 
> into the case where I haven't built any shared core libraries (i.e.
> in the tree), but have wanted to install a "separate" module (i.e. 
> mod_webapp) which must be built as shared.  Since I didn't compile 
> in mod_so, I needed to do a full recompile to enable mod_so.  Yuck.

It sounds reasonable to me to build mod_so by default, but I think
that the builder should be able to turn off mod_so.

Somebody putting together a package for distribution/support ought to
be able to decide what modules they are willing to deal with, and
mod_so opens up everything.  I doubt that a commercial vendor would
make such a decision, but certainly within an organization it might
make sense.  I bet a lot of companies would like a build of IIS to
put on their employees' machines which could not be made to do
anything other than serve static pages :)

-- 
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
       http://www.geocities.com/SiliconValley/Park/9289/
             Born in Roswell... married an alien...

Re: DSO

Posted by Greg Stein <gs...@lyra.org>.
On Tue, Oct 09, 2001 at 06:32:22AM -0700, Ryan Bloom wrote:
> On Monday 08 October 2001 08:21 pm, Justin Erenkrantz wrote:
>...
> > So, +1 on removing the test and always building mod_so if the
> > platform has shared object support - can we check that?  -- justin

+1 on compiling mod_so by default, per the other parts of this thread (that
is: check APR_HAS_DSO).

> There are a lot of people who dislike DSO's, and there are companies who
> refuse to use them for security reasons.  I have had a couple of major
> companies tell me that they want everything compiled statically.

./configure --disable-so

Not a problem.

> As for the test, we should just do what we do for DAV.

Ryan is referring to these lines:

if test "$enable_http" = "no"; then
  dav_enable=no
else
  dav_enable=most
fi

APACHE_MODULE(dav, WebDAV protocol handling, $dav_objects, , $dav_enable)
    

IOW, just compute the default rather than using a hard-coded string. It
works just as well.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: DSO

Posted by Ryan Bloom <rb...@covalent.net>.
On Monday 08 October 2001 08:21 pm, Justin Erenkrantz wrote:
> On Sun, Oct 07, 2001 at 08:31:16AM -0700, Aaron Bannert wrote:
> > I propose we simply get rid of the "if test" in the above code snippit,
> > and default to "static" for mod_so, since by default we have some
> > modules already turned on.  Alternatively we could default to "no"
> > and simply set "enable_so=yes" as soon as any APACHE_MODULE call ends
> > in something non-"no".
>
> Well, I'm kind of thinking we should always build mod_so.  I've run
> into the case where I haven't built any shared core libraries (i.e.
> in the tree), but have wanted to install a "separate" module (i.e.
> mod_webapp) which must be built as shared.  Since I didn't compile
> in mod_so, I needed to do a full recompile to enable mod_so.  Yuck.
>
> So, +1 on removing the test and always building mod_so if the
> platform has shared object support - can we check that?  -- justin

There are a lot of people who dislike DSO's, and there are companies who
refuse to use them for security reasons.  I have had a couple of major
companies tell me that they want everything compiled statically.

As for the test, we should just do what we do for DAV.

Ryan

______________________________________________________________
Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net
--------------------------------------------------------------

Re: DSO

Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Justin Erenkrantz wrote:
> 
> So, +1 on removing the test and always building mod_so if the
> platform has shared object support - can we check that?

Why not just drag it back into the core, then?
-- 
#ken	P-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist      http://Apache-Server.Com/

"All right everyone!  Step away from the glowing hamburger!"

Re: DSO

Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Mon, Oct 08, 2001 at 09:53:52PM -0700, Aaron Bannert wrote:
> It would make sense to have it default to "static", allowing it to be
> explicitly disabled if desired -- for example if someone were building an
> exotic port or if they wanted to trim out all but the most necessary core.

Yeah, that's what I meant.  =)

> > So, +1 on removing the test and always building mod_so if the
> > platform has shared object support - can we check that?  -- justin
> 
> APR_HAS_DSO  ?

That's a #define that'd need to be checked at configure time.
Yeah, that'll work since httpd is configured after APR.  =)

Please submit a patch if possible...  

I'm way too tired to figure this out now.  -- justin

Re: DSO

Posted by Aaron Bannert <aa...@clove.org>.
> Well, I'm kind of thinking we should always build mod_so.  I've run 
> into the case where I haven't built any shared core libraries (i.e.
> in the tree), but have wanted to install a "separate" module (i.e. 
> mod_webapp) which must be built as shared.  Since I didn't compile 
> in mod_so, I needed to do a full recompile to enable mod_so.  Yuck.

It would make sense to have it default to "static", allowing it to be
explicitly disabled if desired -- for example if someone were building an
exotic port or if they wanted to trim out all but the most necessary core.

> So, +1 on removing the test and always building mod_so if the
> platform has shared object support - can we check that?  -- justin

APR_HAS_DSO  ?

-aaron

Re: DSO

Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Sun, Oct 07, 2001 at 08:31:16AM -0700, Aaron Bannert wrote:
> I propose we simply get rid of the "if test" in the above code snippit,
> and default to "static" for mod_so, since by default we have some
> modules already turned on.  Alternatively we could default to "no"
> and simply set "enable_so=yes" as soon as any APACHE_MODULE call ends
> in something non-"no".

Well, I'm kind of thinking we should always build mod_so.  I've run 
into the case where I haven't built any shared core libraries (i.e.
in the tree), but have wanted to install a "separate" module (i.e. 
mod_webapp) which must be built as shared.  Since I didn't compile 
in mod_so, I needed to do a full recompile to enable mod_so.  Yuck.

So, +1 on removing the test and always building mod_so if the
platform has shared object support - can we check that?  -- justin

Re: DSO

Posted by Aaron Bannert <aa...@clove.org>.
On Sun, Oct 07, 2001 at 07:28:32AM -0700, hiten pandya wrote:
> greetings,
> 
> i am trying to fix the problem regarding:
> 
> adding a LoadModule directive when user selects any module 
> as a DSO.
> 
> When i was going throught the configure script, it had two 
> lines like the following:
> 
> ac_help="$ac_help
>  --enable-so DSO capability"
> ac_help="$ac_help
>  --enable-so DSO capability"
> 
> Can someone please explain me why there is a need for two 
> of them lines. I didnt know if there was a need to submit 
> a patch for this.

Hi Hiten,

You have a good point. The problem is comming from somewhere else
(the "configure" script is automatically generated by autoconf).
(see modules/mappers/config9.m4:20):

if test "$sharedobjs" = "yes"; then
    APACHE_MODULE(so, DSO capability, , , static)
else
    APACHE_MODULE(so, DSO capability, , , no)
fi

See, we want to be able to have it work when we do ./configure --help, but
we don't know at that time if we want it to default to "static" or "no".
So what ends up happening is each of those APACHE_MODULE declarations
will add their own ac_help thing as you showed above at ./buildconf-time,
but by the time we've already run ./configure it will decide if it needs
to be "static" or "no" by default.

I propose we simply get rid of the "if test" in the above code snippit,
and default to "static" for mod_so, since by default we have some
modules already turned on.  Alternatively we could default to "no"
and simply set "enable_so=yes" as soon as any APACHE_MODULE call ends
in something non-"no".

-aaron

p.s. about the adding LoadModule statements to the httpd.conf output problem,
I have a partial fix in my tree right now that I expect to get working real
soon and posted, but you're welcome to hack on it too. Contact me offlist
if you want to see what I have so far. :)