Robert Boehne <[EMAIL PROTECTED]> writes: > In Jeff's earier post his item #3 states he's got an unusable > library. We don't want that, but I don't have enough information > to determine why this is the case. Could you post enough for > me to reproduce it?
I don't think you need to reproduce it. One test case is apache 2.0 :) yank the "--disabled-shared" hack for doing subconfigures in httpd-2.0/configure.in and watch the segfaults (I could give you more information if you're willing to go to the trouble... really!). I finally understood what was happening after reading part of the "C and C++ Application Development on AIX" redbook at http://www.redbooks.ibm.com/redbooks/SG245674.html, where it says that when not using run-time linking a shared object that references another shared object needs to use an import file. I can't cut and paste very effectively from the HTML view, but it is the several paragraphs right before section 3.2.1.1. When I redo the part of the build performed by libtool to use the proper import files when linking shared objects that rely on other shared objects, the segfaults due to unresolved symbols disappear. So my build goes like: do the real build using libtool relink libaprutil to specify the import list for libapr relink Apache DSOs to specify the import lists for libapr and libaprutil I'm also relinking httpd and libapr but I don't think that is necessary. Probably the only thing I get out of that is a different libpath wired into httpd since my link puts libapr and libaprutil in a different place. -- 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