I've noticed that shl_load has been patched to remove BIND_NOSTART whihc is fantastic. I was wondering if in addition to this change whether it was also made possible to build apache 2.0 on HPUX in a way that forces it to use dlopen instead of shl_load. As I mentioned below, I've been able to get apache to run perfectly under this scenerio, but not with shl_load, even with BIND_NOSTART removed. If there's a configuration script setting or some way to override the default of shl_load that would be most useful.
Thanks, Noah -----Original Message----- From: Arliss, Noah Sent: Friday, February 07, 2003 12:23 PM To: 'William A. Rowe, Jr.'; dev@apr.apache.org; dev@httpd.apache.org Cc: Arliss, Noah; [EMAIL PROTECTED] Subject: RE: [PATCH] HPUX static's and Mixing C with C++ modules I'll try to clarify things as best I can. First off, BIND_VERBOSE would be fantastic. I had to add it in order to get my module to load at all with shl_load, even though it still would not function. If there was a good reason to remove BIND_VERBOSE that history would be nice to have. The shl_load call would look better as: + shl_t os_handle = shl_load(path, BIND_IMMEDIATE|BIND_VERBOSE, 0L); or + shl_t os_handle = shl_load(path, BIND_IMMEDIATE, 0L); at a minimum. The contradiction with item 3 and 4 below stem from a strange stacktrace I found for my apache 2.0 module. In apache 1.3 to get our module to run we wrote a mod_so.c shim that did not have BIND_NOSTART in the shl_load line. We use mod_so to load our shim, and then use the shim to load our module, so for apache 1.3 removing BIND_NOSTART fixed the problem. In apache 2.0 I have not yet had time to further trouble shoot the issue completely. A couple weeks ago I was testing with the latest apache 2.0 source and ran into trouble (with shl_load). I found a stack trace I saved away that appeared to be in the static initialization phase of one of our third party dependancies. I know I removed BIND_NOSTART from the apache 2.0 source, but I haven't had time to further track it. I haven't completely lost hope of getting my module to run under shl_load (since our 1.3 module does), but it is a cost of time issue, especially with the more robust dlopen available (on the HP platforms we support) and our major apache 2.0 dev effort already completed. As for the _main() issue, it should be up to the module author the more that I think about it. According to the HP docs I included in my original post, _main() should be called from the main() function of the C application, but our 1.3 module calls it in the initializer phase and has been running without problems. Is there a chance we could patch the apache 1.3 shl_load call for BIND_NOSTART as well? If so I can get rid of my shim which would be fantastic! To sum it all up: The patch looks good, module developers should handle _main, and dlopen would be really really nice to have. Thanks again, Noah -----Original Message----- From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED] Sent: Thursday, January 30, 2003 11:32 AM To: dev@apr.apache.org; dev@httpd.apache.org Cc: Arliss, Noah; [EMAIL PROTECTED] Subject: [PATCH] HPUX static's and Mixing C with C++ modules Of course I'm really happy to *finally* get some feedback on that issue (since we have few HPUX participants here, my pleas for comments went mostly unanswered.) The small bit below deserves *instant* reaction; since it can be done with very little extra logic. It seems other issues with HPUX shl_load() were identified earlier by Alexis and Joe (Joe follows this list so I didn't explicitly cc him above) ... for the resolution of BIND_VERBOSE read; http://www.contactor.se/~dast/svn/archive-2002-12/0474.shtml I'm hoping they can provide extra feedback on this patch. [And, by the way, I'm concerned that patch lost some useful diagnostics info - perhaps we should reenable BIND_VERBOSE for --maintainer-mode?] Anyways... An example thread of someone struggling here; http://h21007.www2.hp.com/cxx-dev/CXX/cxx-dev.0203/0071.html So... I'd ask you all to check out this patch (which seems very reasonable) and let me know if you encounter any issues. And Arliss... please give us some citations or reconciliation between the two comments below (they seem contradictary); At 09:43 AM 1/30/2003, Arliss, Noah wrote: >3) shl_load does not like static initialization (even with BIND_NOSTART >removed from the shl_load call). > >It would be great if one or more of the following changes could be made >(mostly from Bill's attached mail): > > 4) Remove BIND_NOSTART from the bits set when calling shl_load since >that explicitly stops any static > initialization. It would be great if I could get this one into >both apache 1.3 and 2.0. Note that this code has existed since rev 1.7 of apache-1.3/src/os/unix/os.c and has never been touched since it was introduced... Revision <http://cvs.apache.org/viewcvs.cgi/*checkout*/apache-1.3/src/os/unix/os.c?re v=1.7>1.7 / <http://cvs.apache.org/viewcvs/apache-1.3/src/os/unix/os.c?rev=1.7&content-t ype=text/vnd.viewcvs-markup>(view) - <http://cvs.apache.org/viewcvs/apache-1.3/src/os/unix/os.c?annotate=1.7>anno tate - <http://cvs.apache.org/viewcvs/apache-1.3/src/os/unix/os.c?r1=1.7>[select for diffs] , Sun Apr 12 15:49:28 1998 UTC (4 years, 9 months ago) by rse Branch: <http://cvs.apache.org/viewcvs/apache-1.3/src/os/unix/os.c?only_with_tag=MAI N>MAIN Changes since 1.6: +43 -0 lines Diff to <http://cvs.apache.org/viewcvs/apache-1.3/src/os/unix/os.c.diff?r1=1.6&r2=1. 7>previous 1.6 (<http://cvs.apache.org/viewcvs/apache-1.3/src/os/unix/os.c.diff?r1=1.6&r2=1 .7&diff_format=h>colored) Although I though we have no chance under HP/UX for using shared objects I today figured out that their proprietary shl_xxx system calls are very close to the dlopen-style interface. And because our os/unix/ stuff already provides an abstraction layer we now can provide DSO support for HP/UX by emulating the dlopen-style interface while not changing anything inside mod_so ;-) So I think we are safe adopting these changes. The fact that this code was only modified once (the VERBOSE change) shows that the entire logic could stand a good vetting. The next question to answer (after these patches are applied) is who's job is it to call _main()? I presume that would be the module author's - if they desired it. But I'm looking for additional feedback and thoughts. Bill
