Apache 2.0 uses libtool and has for some time now.
On AIX we're trying to use libtool 1.4.2 but are running into some
issues that perhaps someone can shed some light on.
background info:
Apache 2.0 uses code in libapr and libaprutil, implicitly loaded
with httpd.
As always, Apache 2.0 does dlopen() on DSOs configured in
httpd.conf. These DSOs reference symbols in the main executable
(httpd), libapr, libaprutil, and anything else needed by the DSO.
libtool+AIX behaviors which we don't understand:
(Some of this we can work-around with AIX-specific logic in our own
build. Some of this we might be able to patch into libtool. For all
of this, it would be useful if the suggested behavior is inappropriate
for some reason.)
1) after building our shared libraries, libtool is putting them in an
archive file and that archive file is what gets installed... why
is this? while this works on AIX, it is non-intuitive... people
expect foo.so, particularly with Apache DSOs like mod_include...
currently on AIX I need to use the Apache syntax
LoadModule mod_foo libfoo.a(libfoo.so.0)
and turn on the dlopen() flag that allows members to be loaded.
While the libfoo isn't a major problem for libraries used
implicitly by httpd (libapr and libaprutil), it is messy for DSOs
because of the Apache configuration file syntax implications.
So... really important for us to avoid the archive/member thing for
Apache DSOs. nice for us to avoid the archive/member thing for
libapr/libaprutil
It seems to me that doing run-time linking will trick libtool into
skipping the archive/member thing but we don't want run-time
linking.
2) export file format
libtool seems to be building a nice export file on AIX, but it is
missing a small detail which would allow it to be used as an
import file
remember that on AIX, a shared library which needs symbols from
another shared library must use import files to tell the loader
which symbols are expected from which shared libraries...
Apache builds libaprutil.a(libaprutil.so) which depends on
libapr.a(libapr.so). It would be nice if the export file for
libapr had "#! libapr.a(libapr.so)" at the top so it can be used as
an import file
3) implicitly specifying import files
(closely related to #2 above)
libaprutil depends on libapr
when I build libaprutil it would be nice for the libapr
import/export file to be specified by libtool; it should be able to
know that I'm building a shared library (libaprutil) which depends
on another shared library (libapr)
currently, libaprutil is not usable because the dynamic linker
doesn't know how to resolve the symbols
4) it would be nice to get libtool-generated export files for main
executables... libtool has the nice logic to generate the export
files... I don't know how to get one generated for the main
executable (e.g., .libs/httpd.exp to go with .libs/httpd)
we do have logic to generate our own export files, but if we get
libtool to implicitly use import files libtool would want to use a
file it had generated
Thanks and best wishes,
Jeff
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
_______________________________________________
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
