Hi Niall Thanks again for your answers and help.
Best regards David > -----Original Message----- > From: cplusplus-sig-bounces+david.aldrich=eu.nec....@python.org > [mailto:cplusplus-sig-bounces+david.aldrich=eu.nec....@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@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. _______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
