This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Elli Pirelli
Recipients Elli Pirelli
Date 2017-01-31.17:14:06
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1485882846.24.0.14620001579.issue29399@psf.upfronthosting.co.za>
In-reply-to
Content
Let me first apologize if this issue has already been reported and discussed before. I would be surprised if there are not a few developers that had to deal with this issue before, but i was unable to find an existing bug report or discussion about this. So, here it goes...


Importing/using Py_* symbols from python3.dll instead directly from python3?.dll can be a problem when python3.dll and python3?.dll reside in a directory that is not part of the standard DLL search path. An example would be an application that tries loading Python from a sub directory of the application.

The functions exported in python3.dll are export forwarders referencing the respective functions in python3?.dll.
python3.dll itself has no import dependency on python3?.dll.

Without an import dependency on python3?.dll, this DLL will be loaded when one of the export forwarders in python3.dll will be resolved, for example when calling GetProcAddress("Py_Main").

However, in such a case an altered DLL search path will be completely ignored, and python3?.dll will only be looked for in the standard DLL search paths. Since the sub directory with the python DLLs is not part of the standard DLL search paths, the resolution of the export fowarder(s) fails.

Trying to alter the DLL search path has no effect. Loading python3.dll with LoadLibraryEx and the flag LOAD_WITH_ALTERED_SEARCH_PATH does not help. Neither does calling SetDllDirectory or AddDllDirectory before loading python3.dll and/or before invoking GetProcAddress.

Note that loading python3.dll itself works fine. However, resolving one of the exports with GetProcAddress will fail if python3?.dll cannot be found in the standard DLL search path.

I don't know, if there is a way to make it work properly...

As of now the only two options out of this dilemma are either to put the python DLLs (and assorted files) in the same directory as the application exe (ugly mess) or to load python3?.dll instead of python3.dll (which sort of defeats the purpose of having python3.dll, i guess).

My suggestion for future Python 3 versions is to let python3.dll have a DLL dependency on python3?.dll. Linking python3.dll to python3?.dll (i.e., loading python3.dll will cause python3?.dll being loaded) allows using altered DLL search paths.
History
Date User Action Args
2017-01-31 17:14:06Elli Pirellisetrecipients: + Elli Pirelli
2017-01-31 17:14:06Elli Pirellisetmessageid: <1485882846.24.0.14620001579.issue29399@psf.upfronthosting.co.za>
2017-01-31 17:14:06Elli Pirellilinkissue29399 messages
2017-01-31 17:14:06Elli Pirellicreate