Help - Perl, XS and global constructors

I have a third-party dynamic library that I'm trying to write an xsub
for.  It was written in C++, and it apparently has global constructors
that need to be initialized.  Building a static xsub works fine, but
the dynamic build always crashes in one function (naturally, it's a
function that needs to be called before almost all of the others in the
library).  With the static build running in wdb, I can actually see
code in the library being called from __do_global_ctors(), but not so
with a dynamic build, so I'm pretty sure it's a constructor problem.

Before I go into the gritty details, let me just ask the basic
question: can a dynamically loaded xsub be written for a library that
has global constructors that need to be initialized?

In my search for a solution, I came to believe that this was possible,
due to references to the CCsimple example in CookbookB.  It gives a
recipe for building a new perl executable that handles C++ constructors
(which I've done).  But how would perl know what constructors need to
be run, when the xsub (and hence the library) aren't loaded until the
perl interpreter starts running?  Did I misunderstand the CCsimple
example?  Note that my xsub code itself doesn't use c++, just the
library (and I only know that because it requires stdc++ to be linked
in).

I'm running HPUX 11, with a perl 5.8.6 that I built myself.  I've tried
building perl and the xsub with the HP ANSI C compiler (we don't have
the c++ compiler), g++ (with ld for linking), and g++ (for both
compiling and linking, which of course eventually calls ld anyway).
They all seem to behave about the same.

Any suggestions/guidance?  I can give more details about the xsub once
someone confirms that this is indeed possible.

Thanks.

  Older versions of perl would load shared libraries on HP-UX by calling
shl_load with a BIND_NOSTART flag.  That prevented shared library
initializers from running and calling c++ constructors.  Your 5.8.6 version
of perl should have had that corrected already.  Apparently it is not
corrected.  Look for BIND_NOSTART in ext/DynaLoader/dl_hpux.xs of your
perl source and take it out.

-- 
Mike Stroyan,  XXXX@XXXXX.COM 

No, I think dl_hpux.xs is correct.  Here's the applicable section:
----------------------------------------------------------------------------
    if (dl_nonlazy) {
      bind_type = BIND_IMMEDIATE|BIND_VERBOSE;
    } else {
      bind_type = BIND_DEFERRED;
      /* For certain libraries, like DCE, deferred binding often causes
run
       * time problems.  Adding BIND_NONFATAL to BIND_IMMEDIATE still
allows
       * unresolved references in situations like this.  */
      /* bind_type = BIND_IMMEDIATE|BIND_NONFATAL; */
    }
    /* BIND_NOSTART removed from bind_type because it causes the shared
library's       */
    /* initialisers not to be run.  This causes problems with all of
the static objects */
    /* in the library.     */
#ifdef DEBUGGING
    if (dl_debug)
        bind_type |= BIND_VERBOSE;
#endif /* DEBUGGING */
----------------------------------------------------------------------------
There's no other occurrence of BIND_NOSTART in the file.

It sounds like you're saying this should work though, which is
encouraging.  Maybe it's not as simple as the global constructors
simply not getting called (which is less encouraging).

Any tips on how to debug this with wdb?  I tried setting a breakpoint
in the library at the same place where it goes to in the static build,
and it never hit it.  But maybe there's something going wrong earlier.
I tried a "catch load", but I got lost pretty quickly trying to step
through the library loading with no debug info.

Thanks for your help!

I was finally able to get dynamic loading to work, but it's not the
ideal solution (although it is usable).

I built a static perl with an empty xsub (as described in
CookbookB/CCsimple), but I also linked in *all* of the required
libraries (the vendor lists lots of shared libraries that need to be
linked to in addition to the one I'm writing the xsub for; previously,
I had only tried linking the new perl with the one where it was
crashing).  Using this perl, I can now dynamically load the extension
for the library I want to access.

I'm guessing that this makes the program's startup code aware of the
libraries, and it handles the initialization just as if it were a full
static build.  Since the libraries in question are still shared, the
new perl executable isn't any bigger than the original (in fact, it's a
little smaller for some odd reason).  I suppose I could also rebuild
perl from scratch and give these as required libraries, but this is
easier.

The really bad thing was that I had to do the link by hand.  I tried
defining LIBS in the "perl Makefile.PL" command line, but it didn't get
passed to the final link.  No idea why.

I'd still like a better solution if someone can come up with one, but I
can live with this.