httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Keith Wannamaker" <...@raleigh.ibm.com>
Subject RE: cvs commit: apache-1.3/src CHANGES Configure
Date Tue, 11 Jan 2000 18:37:03 GMT
| >> | Sorry, I still do not understand why using .sl for the shared core
| >> | breaks anything for the module building. The .sl is required for
| >> | SHARED_CORE and should not harm other stuff. What exactly
| does it break?
| >
| > The actual error messages are:
| >
| >               -o httpd buildmark.o modules.o
| > modules/standard/libstandard.a  main/libmain.a  ./os/unix/libos.a
| > ap/libap.a regex/libregex.a lib/expat-lite/libexpat.a  -lm -lpthread
| > /usr/ccs/bin/ld: Unsatisfied symbols:
| >    dir_module (data)
| >    action_module (data)
|
| Fine, but this looks like a problem with libstandard.a's mod_xxxx.o and
| not with any mod_xxxx.sl. I still do not see where SHLIB_SUFFIX_NAME=sl
| touches anything at the DSO build process. What you fix with removing

It causes /src/modules/standard/Makefile to have the wrong OBJS= definition.

| SHLIB_SUFFIX_NAME=sl is just fixing a symptom. The real problem is not
| that SHLIB_SUFFIX_NAME=sl is broken or breaks anything. What is broken
| is the stuff in code in src/Configure around line 1690 which bases
| decisions on this variable. So, by backing out SHLIB_SUFFIX_NAME=sl
| you fix a symptom in module building and break actually SHARED_CORE.
| Instead SHLIB_SUFFIX_NAME=sl should remain and the code in src/Configure
| corrected, so _both_ things work correctly.
|
| I've currently less time to look at the stuff in depth, but think the
| Ifollowing patch fixes it:

I have tested this fix and it does not correct the problem.
The make process still sets OBJS=(*.so) for /src/modules/standard/Makefile:
OBJS=mod_env.so mod_log_config.so mod_mime.so mod_negotiation.so
mod_status.so m
od_include.so mod_autoindex.so mod_dir.so mod_cgi.so mod_asis.so mod_imap.so
mod
_actions.so mod_userdir.so mod_alias.so mod_access.so mod_auth.so mod_so.o
mod_s
etenvif.so

Unless someone has time to suggest a complete fix, I think we should
go with the current fix to enable DSO's at the cost of breaking SHARED_CORE.
This is what was decided in the closing moments of the last release, anyway.

Keith Wannamaker
IBM HTTP Server

|
| Index: Configure
| ===================================================================
| RCS file: /e/apache/REPOS/apache-1.3/src/Configure,v
| retrieving revision 1.383
| diff -u -r1.383 Configure
| --- Configure   1999/12/20 14:50:55 1.383
| +++ Configure   2000/01/11 17:00:14
| @@ -1680,7 +1680,7 @@
|             modlibs="$modlibs $modlibs1"
|         fi
|         rm -f $tmpfile2 $tmpfile3
| -       if [ "x$ext" != "x$SHLIB_SUFFIX_NAME" ]; then
| +       if [ "x$ext" != "xso" ]; then
|             ext=o
|         fi
|     fi
| @@ -1688,7 +1688,7 @@
|         modname=`echo $modbase | sed 's/^.*\///' | \
|             sed 's/^mod_//' | sed 's/^lib//' | sed 's/$/_module/'`
|     fi
| -   if [ "x$ext" != "x$SHLIB_SUFFIX_NAME" ]; then
| +   if [ "x$ext" != "xso" ]; then
|         echo "Module $modname $modbase.$ext" >>$tmpfile
|     fi
|     #   optionally generate export file for some linkers
|
| Why? Because the .so extension on mod_foo.so is just a _convention_ in
| Apache. It is not required, because we manually load the files anyway.
| SHLIB_SUFFIX_NAME is different. It always has to match the extension
| the systems dynamic loader requires, because it is for loading a real
| _library_ under SHARED_CORE. So the above patch is correct, because
| using SHLIB_SUFFIX_NAME for the decision on the module DSO extension
| is already a violation of our intentions. Instead the rule is: .so
| is a convention for the module DSO extension, SHLIB_SUFFIX_NAME is
| the extension for shared _libraries_. So under HPUX mod_foo.so and
| libapache.sl _IS_ correct. Full stop ;)
|
|                                        Ralf S. Engelschall
|                                        rse@engelschall.com
|                                        www.engelschall.com
|



Mime
View raw message