httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Kraemer <Martin.Krae...@mch.sni.de>
Subject Re: Shared modules -- missing util_script
Date Sat, 07 Feb 1998 19:54:04 GMT
I _think_ on my SVR4 systems here I'm going to have the same problem.
The linker has no -rdynamic switch, and there's no way to force it
to "export" global symbols for which there seems no need to export them
(i.e., during linking of httpd, no shared lib was specified which referenced
palloc(), so all palloc() references were resolved WITHIN the server, and
the symbol was removed.)

So, when I follow the standard method to produce shared modules
which is available in Configure/Makefile,
then as soon as I try to load _any_ of the shared object modules, I
get "killed: unable to resolve palloc" or some such.

The way I want to go when I find the time is this:

*   find out all symbols on the server <-> module interface, i.e.,
    all symbols which are present in the base server and are needed
    for the modules.

*   CREATE A DUMMY SHARED LIBRARY which consists only of a dummy function
    or dummy structure which references all the the server symbols found
    in the first step

*   link the server against this dummy.so library (so that the linker knows
    that all these symbols are part of the interface and must not be
    stripped). The disadvantage is that this requires
    dummy.so to be available when http is started.

*   dynamically load the other mod_xxx.so modules.

Would that be a "kind of portable" (albeit ugly) way to do it?

    Martin

On Thu, Feb 05, 1998 at 03:59:34PM +0000, Paul Sutton wrote:
> > Compile it with -rdynamic (using gcc, of course)
> 
> No, this has nothing to do the dynamic linking. I'm talking about ensuring
> that the statically-linked httpd contains all the consituents of
> libmain.a, when the modules which normally use objects in libmain are
> removed from the build.
> 
> I.e. you do
> 
>   ar crv libz a.o b.o
>   ld c.o -lz -o httpd
> 
> If c.o doesn't make use of any objects defined in a.o or b.o, neither will
> be in the final httpd. So it doesn't matter if the linker need -rdynamic
> or not, since the objects aren't in being linked *into* the executable to
> start with. So the question again: a portable way of ensuring that a.o and
> b.o both get included into httpd, even if none of their symbols are
> required by c.o.
> 
> Paul

-- 
| S I E M E N S |  <Martin.Kraemer@mch.sni.de>  |      Siemens Nixdorf
| ------------- |   Voice: +49-89-636-46021     |  Informationssysteme AG
| N I X D O R F |   FAX:   +49-89-636-44994     |   81730 Munich, Germany
~~~~~~~~~~~~~~~~My opinions only, of course; pgp key available on request

Mime
View raw message