You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Paul Sutton <pa...@c2.net> on 1998/02/05 16:15:03 UTC
Shared modules -- missing util_script
On Wed, 4 Feb 1998, Paul Sutton wrote:
> - add the following lines to your httpd.conf:
>
> LoadModule access_module mod_access.so
> LoadModule action_module mod_actions.so
> LoadModule alias_module mod_alias.so
> LoadModule asis_module mod_asis.so
> LoadModule auth_module mod_auth.so
Actually, this didn't work entirely on my Linux 2 libc system. It
complained about *some* of the modules (mod_asis, mod_cgi) having unknown
symbols. I fought for ages with a seemingly stupid problem, and eventually
found the cause:
All the symbols it cannot find are in util_script.c. No symbols from this
object are referenced from the Apache core. One httpd is linked to form
httpd, util_script.o is NOT linked in.
We need to force util_script to be linked in. One way is to use
--whole-archive option to GNU's ld, but I'm sure that's not portable.
Another way is to add a function into the core which is never called, but
contains calls to a function in util_script. The patch below does this. It
has no effect on Apache (other than a slight size increase, I guess, but
is required to ensure we don't lose some of the Apache API if some modules
are changed into shared libraries.
This needs to be committed before the shared module stuff is released.
Unless anyone knows of a portable way to force the linker to include all
the objects in a library into the executable?
Paul
Index: main/http_main.c
===================================================================
RCS file: /export/home/cvs/apache-1.3/src/main/http_main.c,v
retrieving revision 1.280
diff -u -r1.280 http_main.c
--- http_main.c 1998/01/31 21:44:57 1.280
+++ http_main.c 1998/02/05 15:06:48
@@ -141,6 +141,10 @@
# endif /* _DEBUG */
#endif /* MULTITHREAD */
+static void force_library_loading(void) {
+ add_cgi_vars(NULL,NULL);
+}
+
#include "explain.h"
#if !defined(max)
Re: Shared modules -- missing util_script
Posted by Chuck Murcko <ch...@topsail.org>.
Cristian Gafton wrote:
>
> On Thu, 5 Feb 1998, Paul Sutton wrote:
>
> > This needs to be committed before the shared module stuff is released.
> > Unless anyone knows of a portable way to force the linker to include all
> > the objects in a library into the executable?
>
> Compile it with -rdynamic (using gcc, of course)
>
Unfortunately, the method varies with each compiler/linker/OS
combination, if you use flags. It might be easier in modules.c for
instance to reference all the symbols in each module in the build to
force them to be linked.
--
chuck
Chuck Murcko
The Topsail Group, West Chester PA USA
chuck@topsail.org
Re: Shared modules -- missing util_script
Posted by Martin Kraemer <Ma...@mch.sni.de>.
On Mon, Feb 09, 1998 at 12:37:26PM +0000, Paul Sutton wrote:
> On Sat, 7 Feb 1998, Martin Kraemer wrote:
> > 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
>
> -rdynamic is probably specific to gcc's ld. Other vendors will use
> different options -- presumably you checked your manpages?
Yes, and I even contacted the compiler developers. Their proposal was
similar to what I described.
Martin
--
| S I E M E N S | <Ma...@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
Re: Shared modules -- missing util_script
Posted by Paul Sutton <pa...@c2.net>.
On Sat, 7 Feb 1998, Martin Kraemer wrote:
> 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
-rdynamic is probably specific to gcc's ld. Other vendors will use
different options -- presumably you checked your manpages?
> * 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.
Does this actually work? If so, I guess it's okay. It should be an option
that Configure sets so we don't do this for other platforms.
//pcs
Re: Shared modules -- missing util_script
Posted by Martin Kraemer <Ma...@mch.sni.de>.
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 | <Ma...@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
Re: Shared modules -- missing util_script
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Paul Sutton wrote:
>
> 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
Long ago, when the library setup was originally proposed, I was concerned
about things of this nature. I was assured that listing the .a file in
the link rather than using -L would cause the entire library to be
included. Since then I've become a convert to the idea.
Why would this be happening, though? libmain.a *is* named as such,
and no -L searching is supposedly being done, so why would anything
be left out? Is this a platform-specific thing?
#ken P-)}
Re: Shared modules -- missing util_script
Posted by Ben Laurie <be...@algroup.co.uk>.
Dean Gaudet wrote:
>
> On Thu, 5 Feb 1998, Cristian Gafton wrote:
>
> > That's not true if you do:
> > ld -o httpd c.o libz.a
> > (ie link the library in). You have to decide whether the library will be
> > used as a library or as an object file.
>
> That's what I thought too. But it's not true with gnu ld.
It's always been my understanding that -lxyz is shorthand for
{searchpath}libxyz.a, literally.
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686|Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
Re: Shared modules -- missing util_script
Posted by Dean Gaudet <dg...@arctic.org>.
On Thu, 5 Feb 1998, Cristian Gafton wrote:
> That's not true if you do:
> ld -o httpd c.o libz.a
> (ie link the library in). You have to decide whether the library will be
> used as a library or as an object file.
That's what I thought too. But it's not true with gnu ld.
Dean
% cat >a.c
int a() {}
% cat > b.c
int b() {}
% cat > hello.c
void main() {puts("hello");}
% make CFLAGS='-g' a.o b.o hello.o
cc -g -c a.c -o a.o
cc -g -c b.c -o b.o
cc -g -c hello.c -o hello.o
% ar cr t.a a.o b.o
% nm t.a
a.o:
00000000 T a
b.o:
00000000 T b
% ld -o httpd /usr/lib/crt1.o hello.o t.a -lc
% nm hello
080494f8 A _DYNAMIC
080494d8 A _GLOBAL_OFFSET_TABLE_
080494cc ? __CTOR_END__
080494c8 ? __CTOR_LIST__
080494d4 ? __DTOR_END__
080494d0 ? __DTOR_LIST__
080483d0 T ___crt_dummy__
08049580 A __bss_start
08048488 t __do_global_ctors_aux
08048450 t __do_global_dtors_aux
080494c4 D __environ
08049580 B __fpu_control
U __libc_init
U __setfpucw
08049580 A _edata
08049584 A _end
080484ac A _etext
080484b0 ? _fini
08048360 ? _init
080483d0 T _start
U atexit
08048440 t done
080494c4 W environ
U exit
08048470 t fini_dummy
080494c8 d force_to_data
080494c8 d force_to_data
08048488 t gcc2_compiled.
08048450 t gcc2_compiled.
08048474 t gcc2_compiled.
080484a8 t init_dummy
08048474 T main
U puts
% ld --version
GNU ld 2.8.1
Copyright 1997 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License. This program has absolutely no warranty.
Supported emulations:
elf_i386
i386linux
Re: Shared modules -- missing util_script
Posted by Paul Sutton <pa...@awe.com>.
On Thu, 5 Feb 1998, Cristian Gafton wrote:
> On Thu, 5 Feb 1998, Paul Sutton wrote:
> > 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.
>
> That's not true if you do:
> ld -o httpd c.o libz.a
> (ie link the library in). You have to decide whether the library will be
> used as a library or as an object file.
That certainly isn't the case with my ld (GNU ld 2.7). We already build
httpd that way, and util_script is still missing. In the absence of any
apparent alternatives, we'll have to just my patch to make the linker
think that at least one symbol in util_script is in use.
Paul
Re: Shared modules -- missing util_script
Posted by Cristian Gafton <ga...@redhat.com>.
On Thu, 5 Feb 1998, Paul Sutton wrote:
> 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.
That's not true if you do:
ld -o httpd c.o libz.a
(ie link the library in). You have to decide whether the library will be
used as a library or as an object file.
Cristian
--
----------------------------------------------------------------------
Cristian Gafton -- gafton@redhat.com -- Red Hat Software, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
UNIX is user friendly. It's just selective about who its friends are.
Re: Shared modules -- missing util_script
Posted by Paul Sutton <pa...@c2.net>.
On Thu, 5 Feb 1998, Cristian Gafton wrote:
> On Thu, 5 Feb 1998, Paul Sutton wrote:
> > This needs to be committed before the shared module stuff is released.
> > Unless anyone knows of a portable way to force the linker to include all
> > the objects in a library into the executable?
>
> 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
Re: Shared modules -- missing util_script
Posted by Marc Slemko <ma...@worldgate.com>.
On Thu, 5 Feb 1998, Cristian Gafton wrote:
> On Thu, 5 Feb 1998, Paul Sutton wrote:
>
> > This needs to be committed before the shared module stuff is released.
> > Unless anyone knows of a portable way to force the linker to include all
> > the objects in a library into the executable?
>
> Compile it with -rdynamic (using gcc, of course)
No, a portable way.
Re: Shared modules -- missing util_script
Posted by Cristian Gafton <ga...@redhat.com>.
On Thu, 5 Feb 1998, Paul Sutton wrote:
> This needs to be committed before the shared module stuff is released.
> Unless anyone knows of a portable way to force the linker to include all
> the objects in a library into the executable?
Compile it with -rdynamic (using gcc, of course)
Cristian
--
----------------------------------------------------------------------
Cristian Gafton -- gafton@redhat.com -- Red Hat Software, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
UNIX is user friendly. It's just selective about who its friends are.