From 08514089488cf6b4271e4a4da63b2a44c03422f8 Mon Sep 17 00:00:00 2001 From: "Ralf S. Engelschall" Date: Mon, 3 Aug 1998 08:44:10 +0000 Subject: [PATCH] Link DSO modules against possible libraries from $(LIBS) (take 2) ================================================================= Currently we have the following entry in our dso.html document: | Because DSO modules cannot be linked against other DSO-based libraries (ld | -lfoo) on all platforms (for instance a.out-based platforms usually don't | provide this functionality while ELF-based platforms do) you cannot use the | DSO mechanism for all types of modules. Or in other words, modules compiled as | DSO files are restricted to only use symbols from the Apache core, from the C | library (libc) and all other dynamic or static libraries used by the Apache | core, or from static library archives (libfoo.a) containing position | independend code. The only chance to use other code is to either make sure the | Apache core itself already contains a reference to it or loading the code | yourself via dlopen(). The important part here is: "cannot be linked .... on all platforms". But there _are_ platform (especially ELF-based ones) which support linking DSO files agains other DSO files. And even on platforms where this is not possible is it possible to at least link against libraries assuming they contain PIC code. So, the idea is this: In the configuration process we already determine the variable LDFLAGS and LIBS. They hold -L and -l options for linking executables. We parse these options and separate them into three classes: OBJ, PIC and DSO. And then we re-assemble a LIBS_SHLIB variable from only the options in classes PIC and DSO. This variable is then used on the build command for mod_xxx.so. Example: | $ ./configure --prefix=/tmp/apache \ | --enable-module=auth_db \ | --enable-shared=auth_db \ | --enable-rule=SHARED_CHAIN Without SHARED_CORE the mod_auth_db.so cannot be linked or at least not loaded correctly under run-time. With SHARED_CHAIN enabled it is linked against the libdb.so and all is fine (at least under this ELF-based Debian box I tried): | :> make mod_auth_db.so | gcc -c -I../../os/unix -I../../include -I/usr/include/ -DLINUX=2 | -DUSE_HSREGEX `../../apaci` -fpic -DSHARED_MODULE mod_auth_db.c && mv | mod_auth_db.o mod_auth_db.lo | ld -Bshareable -o mod_auth_db.so mod_auth_db.lo -lm -ldb | root@gw1:/e/apache/SRC/WORK/apache-1.3-libsshlib/src/modules/standard | :> ldd mod_auth_db.so | ./mod_auth_db.so => ./mod_auth_db.so | libc.so.5 => /lib/libc.so.5 | libm.so.5 => /lib/libm.so.5 | libdb.so.1 => /usr/lib/libdb.so.1 This way we provide the maximum we can provide. Sure, on some platforms the user still has no chance. But this shouldn't mean he becomes no chance on other platforms where there _is_ a chance. So this patch is a first step for more friendly and flexible DSO support. The complete mechanism is triggered by a new Rule named SHARED_CHAIN. To avoid problems this is DISABLED(!) for ALL(!) platforms currently. But when experience shows that it worked fine for users we can enable it for tested platforms per default. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@81846 13f79535-47bb-0310-9956-ffa450edef68 --- docs/manual/dso.html | 8 +++++--- docs/manual/dso.html.en | 8 +++++--- 2 files changed, 10 insertions(+), 6 deletions(-) diff --git a/docs/manual/dso.html b/docs/manual/dso.html index 235391c5c5..76db6fc5a1 100644 --- a/docs/manual/dso.html +++ b/docs/manual/dso.html @@ -364,9 +364,11 @@ $ apxs -i -a -n foo mod_foo.so use symbols from the Apache core, from the C library (libc) and all other dynamic or static libraries used by the Apache core, or from static library archives (libfoo.a) containing position - independent code. The only chance to use other code is to either make - sure the Apache core itself already contains a reference to it or loading - the code yourself via dlopen(). + independent code. The only chances to use other code is to either make + sure the Apache core itself already contains a reference to it, loading + the code yourself via dlopen() or enabling the + SHARED_CHAIN rule while building Apache when your platform + supports linking DSO files against DSO libraries.

  • Under some platforms (many SVR4 systems) there is no way to force the linker to export all global symbols for use in DSO's when linking the diff --git a/docs/manual/dso.html.en b/docs/manual/dso.html.en index 235391c5c5..76db6fc5a1 100644 --- a/docs/manual/dso.html.en +++ b/docs/manual/dso.html.en @@ -364,9 +364,11 @@ $ apxs -i -a -n foo mod_foo.so use symbols from the Apache core, from the C library (libc) and all other dynamic or static libraries used by the Apache core, or from static library archives (libfoo.a) containing position - independent code. The only chance to use other code is to either make - sure the Apache core itself already contains a reference to it or loading - the code yourself via dlopen(). + independent code. The only chances to use other code is to either make + sure the Apache core itself already contains a reference to it, loading + the code yourself via dlopen() or enabling the + SHARED_CHAIN rule while building Apache when your platform + supports linking DSO files against DSO libraries.

  • Under some platforms (many SVR4 systems) there is no way to force the linker to export all global symbols for use in DSO's when linking the -- 2.40.0