Just a side note here; although I haven't the faintest idea about the intricacies of dynamic loading on HP-UX, I _do_ know that in some situations, even plain C code needs constructor-like initialization when a shared library is loaded. This leads me to guess that BIND_NOSTART might be bad even for C, not just C++.
Arliss, Noah wrote: >I understand BIND_NOSTART has been in the code since it was first checked >into apache 1.3. I also understand the desire not to break existing >functionality. I can tell you that BIND_NOSTART prevents any C++ module >developer from being able to take advantage of static initialization. I'd be >more than happy to leave that code be if I had a definative way to enable >dlopen instead of shl_load. > >-N > >-----Original Message----- >From: Joe Orton [mailto:[EMAIL PROTECTED]] >Sent: Saturday, February 08, 2003 5:01 AM >To: [EMAIL PROTECTED]; [EMAIL PROTECTED] >Subject: Re: [PATCH] HPUX static's and Mixing C with C++ modules > > >Hi, > >On Fri, Feb 07, 2003 at 12:23:09PM -0500, Arliss, Noah wrote: > > >>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: >> >> > >BIND_VERBOSE means the library writes error message to whatever file you >happen to have open as fd 2 - which is unacceptable for a library. (the >app may have closed stderr and be using fd 2 for something completely >different). You get exactly the same error string back via >apr_dso_error() anyway, which is the defined interface for retrieving >the error string. > >Changing the call to: > > > >>+ shl_t os_handle = shl_load(path, BIND_IMMEDIATE, 0L); >> >> > >seems fine to me, FWIW, but as Will says, the BIND_NOSTART has been >there since the code was first checked into Apache 1.3, so there may be >some subtle reason why it's needed. > >Regards, > >joe > > -- Brane Čibej <[EMAIL PROTECTED]> http://www.xbc.nu/brane/
