apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arliss, Noah" <narl...@netegrity.com>
Subject Mixing C with C++ modules (HPUX)
Date Thu, 30 Jan 2003 15:43:41 GMT
Greetings,

This is my first post to the apr list. I've been working with William Rowe
on some issues encountered on the HPUX platform with apache 2.0. It has come
to my attention that for portability reasons, Apache 2.0.44 switched from
using dlopen to using shl_load on HPUX since shl_load is more widely
available. Unfortunately for us our module does not like shl_load, but will
run just fine when dlopen is used. I can attribute these problems to a
couple of potential problems that I have not yet had the time to narrow down
further:

1) shl_load is much more restrictive than dlopen (not allowing for TLS in
the shared object for example).
2) shl_load appears to have additional requirements with regards to mixing C
and C++ in the same 
   runtime space requiring calls to _main() from the C program if it's in
control.
3) shl_load does not like static initialization (even with BIND_NOSTART
removed from the shl_load call).

While it is completely understandable to provide a buildable environment to
the least common denominator it would be helpful for the C++ module
developers out there to be able to take advantage of the more robust dlopen
over shl_load. Right now if a customer wants to use my module in apache
2.0.44 I have to instruct them to edit the
httpd-2.0.43/srclib/apr/include/arch/unix/apr_private.h file to define
DSO_USE_DLFCN and undef DSO_US_SHL. This is a rather ugly installation step.

It would be great if one or more of the following changes could be made
(mostly from Bill's attached mail):

	1) Have the install dynamically look for dlopen in /usr/lib/dld.sl
or /usr/lib/libdld.sl. 
	   HPUX 11 supports dlopen in dld.sl B.11.25 or later.
	2) Have an override flag --prefer-dl that will allow me to force
using dlopen via the configure script.
	3) Have a -prepare-cplusplus flag that will tweak apache to better
support C++ modules. Enhancements here could 
	   include making sure that _main() gets called in apache on HPUX
when using shl_load 
	   (see
http://www.arnold.af.mil/hpc/hp/cpp/otherlangs.htm#OtherLanguages).
	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.

Having the ability to use dlopen instead of shl_laod will greatly increase
the ease for us to support Apache 2.0.44 and later, in particular on HPUX.

Thanks,

Noah Arliss


-----Original Message-----
From: William A. Rowe, Jr. [mailto:wrowe@covalent.net]
Sent: Friday, January 17, 2003 11:16 AM
To: Arliss, Noah
Subject: Re: HP/UX shl over dl patch


Ahhh... let me guess; you have singletons about?  Those would (quite
possibly)
be your TLS issues.  Perhaps burried in the c++ library code itself.

As far as choosing between dl/shl, that puts us in an interesting
position...
binary v.s. c++ compatibility.

It sounds like we need one of three options;

  - a configure option --prefer-dl (meaning do the dlopen() tests prior to
any
    platform method tests.)

  - a configure option --binary-build (meaning choose the safest course on
    all platforms for compatibility.)

  - dynamically check for dlopen() by shl_load()ing libdl.so and using the
    dl() methods if shl_sym() locates the dl() methods.  

  - a configure option --prepare-cplusplus (meaning make whatever platform 
    tweaks are needed to link to or load c++ objects and modules.)

I really sort of like the third option, myself, both for the shl/dl debate
and for
the sendfile() in clib v.s. sendfile() in libsendfile.so.  Both of these
vary by
kernel patch level, so they are very tricky to config for binary builds.  

Let me know your thoughts on these three.  Only the third would allow a user
who grabs a binary (opensource) build of libapr to use your module without 
extra patches.

For your development work, see 

http://cvs.apache.org/viewcvs/apr/configure.in.diff?r1=1.489&r2=1.490

and you can use patch with the -R option to reverse this patch.

Bill

----- Original Message ----- 
From: "Arliss, Noah" <narliss@netegrity.com>
To: "'William A. Rowe, Jr.'" <wrowe@covalent.net>
Sent: Friday, January 17, 2003 7:49 AM
Subject: RE: HP/UX shl over dl patch


> Bill,
> 
> Your patches work fine in general for apache, but leave my module burried
in
> the mud. It appears that the mixing of C and C++ in combination with the
> static initialization of one of our dependant libraries do not work well
> when shl_load is called. Based on what you've said about binary distro's
not
> working on all systems it seems I will get very little traction with the
> group on reverting back to dlopen as the desired method for loading
modules.
> Instead maybe you could tell me how at compile time to change that
> preference from shl_load to dlopen. Is there a flag I can set? This way I
> can at least put together a document for our customers to work from.
> 
> Thanks for all your help and input, I was hoping by just changing the call
> to shl_load it would work. Since it didn't there's no need for me to
submit
> a patch to apr.
> 
> -N
> 
> P.S. I didn't copy the full source tree of apache over to hp, just apr and
> apr-util. I'm assuming this was not enough to properly test your libtool
> patch since even with a newly built env for apr and apr-util, I'm still
> getting 555 protection on lib. I'll try to copy the full thing over this
> afternoon.
> 
> -----Original Message-----
> From: William A. Rowe, Jr. [mailto:wrowe@covalent.net]
> Sent: Thursday, January 16, 2003 2:44 PM
> To: Arliss, Noah
> Subject: Re: HP/UX shl over dl patch
> 
> 
> Simply because dlopen() is available only within a subset of patched
hpux-11
> releases.  I confirmed that one of our boxes with an older install of hpux
> is missing dlopen within its libdl.  This means that binary hpux11 builds
> may
> or may not work on other hpux11 machines.
> 
> However, if this is true, your module would be broken on some subset of
> platforms in the first place, irrespective of this toggle.
> 
> One important question; are you building apr with pthreads?
> 
> Another interesting question; which dependent library do you suspect of
> using TLS, or is this your module's own code?
> 
> Bill
> 
> 
> 
> ----- Original Message ----- 
> From: "Arliss, Noah" <narliss@netegrity.com>
> To: "'William A. Rowe, Jr.'" <wrowe@covalent.net>
> Sent: Thursday, January 16, 2003 11:32 AM
> Subject: RE: HP/UX shl over dl patch
> 
> 
> > Bill,
> > 
> > We may have a large problem here. I finally got your patches applied and
> > verified that the next rev of apache 2.0 is built using shl_load. Our
> module
> > however will not load under the shl_load call in apache 2.0. I'm not
sure
> > why this is exactly, but my current working theory is the following: 
> > 
> > We link with pthreads because we have background threads that run within
> our
> > module. If you read the man page for shl_load, under warnings is the
> > following:
> > 
> > Use caution when building shared libraries with external library
> > dependencies.  Any library that contains Thread Local Storage (TLS)
> > should not be used as a dependency.  If a dependent library contains
> > TLS, and it is not loaded during program startup (that is, not
> > linked
> > against the executable), the dynamic loader fails to perform the
> > operation.
> > 
> > dlopen has not exhibited any problems for us at the moment. May I ask
what
> > the motivation is to move to shl_load rather than dlopen?
> > 
> > -N
> > 
> > -----Original Message-----
> > From: William A. Rowe, Jr. [mailto:wrowe@covalent.net]
> > Sent: Thursday, January 16, 2003 9:37 AM
> > To: Arliss, Noah
> > Subject: Re: HP/UX shl over dl patch
> > 
> > 
> > Try grabbing the gnu *source* package for libtool-1.4.2 or 1.4.3, patch
it
> > and then
> > build/install it.
> > 
> > Sorry... that patch isn't meant to apply to an already-installed
libtool.
> > 
> > Bill
> > 
> > ----- Original Message ----- 
> > From: "Arliss, Noah" <narliss@netegrity.com>
> > To: "'William A. Rowe, Jr.'" <wrowe@covalent.net>
> > Sent: Thursday, January 16, 2003 6:23 AM
> > Subject: RE: HP/UX shl over dl patch
> > 
> > 
> > > Bill,
> > > 
> > > It looks like the patch doesn't have the path to aclocal.m4 which is
in
> > > /srclib/apr-util/sml/expat/aclocal.m4. My guess is if it could find
> > > aclocal.m4 it would then have trouble finding ltmain.in which I cannot
> > find
> > > in my source tree (ltmain.sh is in a few directories, but not in the
> > > httpd-2.0 root). Are all of this files supposed to be in the same
> > directory?
> > > Is there a step I should be taking before running the patch command?
> > > 
> > > -N
> > > 
> > > -----Original Message-----
> > > From: William A. Rowe, Jr. [mailto:wrowe@covalent.net]
> > > Sent: Wednesday, January 15, 2003 4:52 PM
> > > To: narliss@netegrity.com
> > > Subject: Fw: HP/UX shl over dl patch
> > > 
> > > 
> > > Sorry, that was dos line-ended, this one is not.
> > > 
> > > Bill
> > > 
> > > ----- Original Message ----- 
> > > From: "William A. Rowe, Jr." <wrowe@covalent.net>
> > > To: <narliss@netegrity.com>
> > > Sent: Wednesday, January 15, 2003 6:36 AM
> > > Subject: Re: HP/UX shl over dl patch
> > > 
> > > 
> > > > Noah,
> > > > 
> > > >   Please take a quick look at this, and let me know what you think.
> The
> > > extra 
> > > > $rm statements are due to the chmod 555 hp/ux bogosity, and I've
> > modified
> > > the
> > > > code to use -Wl,+s so we search SHLIB_PATH.
> > > > 
> > > >   Depending on your shl patch, we might be able to make all the
fixes
> > > within libtool.
> > > > 
> > > > Bill
> > > > 
> > > > 
> > > 
> > > 
> > 
> > 
> 
> 

Mime
View raw message