[C++-sig] Can boost_python dll be delay loaded?

David Aldrich David.Aldrich at EU.NEC.COM
Fri Jul 30 18:01:24 CEST 2010


Hi Niall

Thanks again for your answers and help.

Best regards

David

> -----Original Message-----
> From: cplusplus-sig-bounces+david.aldrich=eu.nec.com at python.org
> [mailto:cplusplus-sig-bounces+david.aldrich=eu.nec.com at python.org] On
> Behalf Of Niall Douglas
> Sent: 30 July 2010 16:48
> To: Development of Python/C++ integration
> Subject: Re: [C++-sig] Can boost_python dll be delay loaded?
> 
> On 30 Jul 2010 at 10:56, David Aldrich wrote:
> 
> > > I thought that the application installer registered the DLL manifests
> > > at their locations? It's like registering COM or .NET objects, in
> > > fact I think it's the same mechanism nowadays.
> >
> > Well, I don't plan to use an application installer. Most of our users
> > build and run the application from within a svn working copy.
> 
> It's usually easy enough to rig up a COM object registration into a
> build system. Surely it would similar for manifest stuff.
> 
> > > As for why it doesn't work when others do, I would guess it's due to
> > > how the BPL machinery sets itself up on process init. During static
> > > init the BPL library sets up all sorts of runtime information which
> > > is later used by BPL clients, and during all of this it is extremely
> > > important that everything be kept in precisely the right order.
> >
> > I don't understand the intricacies of Boost's initialisation, nor do I
> > even know when it happens. I naively thought that nothing would happen
> > until I explicitly call a boost_python API method. Does the fact that I
> > have included <boost/python.hpp> mean that some boost initialisation
> > will occur before main() is reached?
> 
> Rather it is when the BPL DLL is loaded into the process that it
> performs its static init which sets up the internal environment ready
> for your client code to call BPL APIs. The BPL DLL, like any complex
> metaprogrammed C++ DLL nowadays, will expect to be initialised before
> main() gets called and would be unlikely to work if main() gets
> called first.
> 
> > > Your best bet it would seem now is to have PATH
> > > modified on app install, but that is a very lazy way out and is
> > > indeed banned in lots of corporate environments.
> >
> > Sadly, I think that is the only solution. Thanks again for your help.
> 
> The only other I can think of is putting a symbolic link to the BPL
> DLL in the same directory as the executable. Symbolic links are Vista
> or later only sadly, though you could install Microsoft's Unix
> subsystem on XP and get symbolic links that way :)
> 
> HTH,
> Niall
> 
> --
> Technology & Consulting Services - ned Productions Limited.
> http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no:
> 472909.
> 
> 
> 
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig
> 
> 
>  Click
> https://www.mailcontrol.com/sr/QPy1GWmUWovTndxI!oX7Uqfv98hA5qioKLUaEvLrmgO
> mhsjStaar8uC2P7BlaqMtj6B2UVGAGYT63Umxp4EWgA==  to report this email as
> spam.


More information about the Cplusplus-sig mailing list