Issue3308
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.
Created on 2008-07-07 00:16 by rogerbinns, last changed 2022-04-11 14:56 by admin. This issue is now closed.
Files | ||||
---|---|---|---|---|
File name | Uploaded | Description | Edit | |
localtime.zip | rogerbinns, 2008-07-07 02:26 | Trivial extension showing issue with localtime(), msvc9 and Python 2.6 |
Messages (12) | |||
---|---|---|---|
msg69361 - (view) | Author: Roger Binns (rogerbinns) | Date: 2008-07-07 00:16 | |
My extension (apsw) builds and runs just fine on Linux, Mac and Windows for Python 2.3, 2.4 and 2.5. For Linux and Mac Python 2.6 beta 1 and Python 3.0 beta 1 also work just fine. However on Windows using MinGW and Python 2.6 beta 1 and Python 3.0 beta 1 the pyd fails to load claiming the "specified procedure cannot be found". The compile/link is just fine and pexports shows the procedure is present. # Compile lines c:/python26/python setup.py build --compile=mingw32 install c:\mingw\bin\gcc.exe -mno-cygwin -mdll -O -Wall -DSQLITE_THREADSAFE=1 -DNDEBUG=1 -DEXPERIMENTAL=1 -DAPSW_USE_SQLITE_AMALGAMATION=\"C:\apsw\sqlite3.c\" -Ic:\python26\include -Ic:\python26\PC -c apsw.c -o build\temp.win32-2.6\Release\apsw.o writing build\temp.win32-2.6\Release\apsw.def c:\mingw\bin\gcc.exe -mno-cygwin -shared -s build\temp.win32-2.6\Release\apsw.o build\temp.win32-2.6\Release\apsw.def -Lc:\python26\libs -Lc:\python26\PCbuild -lpython26 -lmsvcr90 -o build\lib.win32-2.6\apsw.pyd # Running ImportError: DLL load failed: The specified procedure could not be found. # Pexports C:\apsw>pexports build\lib.win32-2.6\apsw.pyd LIBRARY apsw.pyd EXPORTS initapsw When using Python 3.0 things are substantially the same except the init function is PyInit_apsw. MinGW was installed using the default configuration with the automated installer http://sourceforge.net/forum/forum.php?forum_id=817299 The libmsvcr90.a is part of MinGW found in c:\MinGW\lib |
|||
msg69364 - (view) | Author: Roger Binns (rogerbinns) | Date: 2008-07-07 01:16 | |
I figured maybe it was something to do with MSVC 90 dlls. <pre> C:\apsw>dir \*msvc*90* /s Volume in drive C has no label. Volume Serial Number is F4A5-1661 Directory of C:\MinGW\lib 12/27/2007 08:23 AM 554,136 libmsvcr90.a 12/27/2007 08:23 AM 555,910 libmsvcr90d.a 2 File(s) 1,110,046 bytes Directory of C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_d08d0375 11/06/2007 08:23 PM 224,768 msvcm90.dll 11/07/2007 01:19 AM 568,832 msvcp90.dll 11/07/2007 01:19 AM 655,872 msvcr90.dll 3 File(s) 1,449,472 bytes Directory of C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.30411.0_x-ww_71382c73 04/10/2008 10:52 PM 225,280 msvcm90.dll 04/11/2008 04:32 AM 572,928 msvcp90.dll 04/11/2008 04:32 AM 655,872 msvcr90.dll 3 File(s) 1,454,080 bytes Total Files Listed: 8 File(s) 4,013,598 bytes 0 Dir(s) 22,924,242,944 bytes free </pre> Process Explorer shows Python 2.6 exe using MSVCR90.dll from the 71382c73 WinSxS directory. Using Process Monitor for the 'import apsw' invocation shows the cp437 encoding being looked for and found, then the apsw.pyd being looked for, found, opened, LoadImage, ReadFile and CloseFile. Then a file named angle bracket stdin angle bracket it looked for and not found (presumably to show the error message). |
|||
msg69367 - (view) | Author: Roger Binns (rogerbinns) | Date: 2008-07-07 02:26 | |
I can't prove it since Python gives no further information than a procedure cannot be found, but using a bunch of other tools I think this may be due at least to the use of localtime() and it not being present in the msvcr90.dll but is in the vc version 7 dlls which is why earlier versions of Python have no issue. If the above is the case then I have no idea where the actual underlying cause lies. Is MinGW missing header information that should mangle localtime() to one of the other variants used by msvc (_s suffix, _ prefix, 32/64 in there somewhere)? Is the Python header causing issues? Attached is a trivial extension providing the issue with localtime. |
|||
msg69370 - (view) | Author: Martin v. Löwis (loewis) * ![]() |
Date: 2008-07-07 04:29 | |
Can you please check the event log at the point of failure, and report any events it may have recorded? |
|||
msg69373 - (view) | Author: Roger Binns (rogerbinns) | Date: 2008-07-07 04:44 | |
I cleared all event categories, and then ran Python followed by the import (which fails). No events in any category appeared. |
|||
msg69380 - (view) | Author: Martin v. Löwis (loewis) * ![]() |
Date: 2008-07-07 05:17 | |
Do you have a copy of depends.exe? If so, how does it resolve the DLLs referenced in apsw.pyd? |
|||
msg69381 - (view) | Author: Roger Binns (rogerbinns) | Date: 2008-07-07 05:57 | |
I didn't have a copy of depends.exe since it doesn't appear to come with MinGW. System is basically VirtualBox VM with fresh install of XP Pro SP2, upgraded to SP3 and TortoiseSVN, Firefox, Xemacs, MinGW and Python versions installed. I found a GUI program named depends which is what I used to figure out that the issue appeared to be localtime() missing in msvcr90.dll. BTW did you notice msg69367 and the attached file that shows the problem in a trivial test case? The gui depends program found the following issues: - No localtime in msvcr90.dll - DWMAPI.DLL not found (not mentioned on link line so no idea why depends wants it) - MPR.DLL & SHLWAPI.DLL are red but I don't know why (again not mentioned on link line) I think that the localtime() symbol is the underlying cause. However this isn't exactly Python's fault (Python's headers don't do anything to the localtime symbol but there may be defines that cause "secure crt" to be used which wants localtime_s to be used instead). Maybe MinGW is supposed to be redefining localtime to one of the _/32/64/s variants but isn't. In any event the net result is that if a Python extension uses current MinGW and localtime() then it will compile and link correctly on Python 2.3, 2.4, 2.5, 2.6b1 & 3.0b1. However it won't run on 2.6b1 or 3.0b1 due to some sort of mismatch between those versions of Python using new MSVC runtime and/or MinGW. |
|||
msg69382 - (view) | Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * ![]() |
Date: 2008-07-07 12:36 | |
It seems that mingw is unable to compile the simplest program containing a call to localtime(): $ echo "#include <time.h> > int main() { localtime(NULL); }" > t.c $ gcc -mno-cygwin t.c -lmsvcr90 Then starting "a.exe" displays a modal box with the message: "The procedure entry point localtime could not be located in the dynamic link library msvcr90.dll." So the problem is not python-specific, and should be reported to Mingw. However, I discovered that it works if you include time.h this way: #define __MSVCRT_VERSION__ 0x0700 /* whatever above 0x0601 */ #include <time.h> #define time_t __time64_t #define localtime _localtime64 #define time _time64 |
|||
msg69393 - (view) | Author: Roger Binns (rogerbinns) | Date: 2008-07-07 19:18 | |
In MinGW's defense the MSVC 7 dll does include localtime. Since Python/distutils only says that MSVC 9 dll is being used at link time, how exactly is MinGW (or any other code) supposed to know that localtime should be provided some other way? Maybe distutils should be defining __MSVCRT_VERSION__ to 0x0900 for the compile phase as well for Python 2.6/3.0. If that was the case then at least I could work around the issue (the localtime call isn't actually in my code but a library I statically link in) and still work correctly on earlier Pythons which don't need any workarounds. |
|||
msg69394 - (view) | Author: Martin v. Löwis (loewis) * ![]() |
Date: 2008-07-07 20:19 | |
> BTW > did you notice msg69367 and the attached file that shows the problem in > a trivial test case? I didn't understand it, so I ignored it. What use of localtime, by whom, what tools? The mentioning of localtime seems to come out of nowhere. (later messages clarified these, apparently: if localtime is called in an extension, then the extension won't load, otherwise, it will load) > The gui depends program found the following issues: That's likely the one that I was asking for. > In any event the net result is that if a Python extension uses current > MinGW and localtime() then it will compile and link correctly on Python > 2.3, 2.4, 2.5, 2.6b1 & 3.0b1. However it won't run on 2.6b1 or 3.0b1 > due to some sort of mismatch between those versions of Python using new > MSVC runtime and/or MinGW. That sounds rather like a bug in MinGW. Can you ask on one of their lists? |
|||
msg69404 - (view) | Author: Roger Binns (rogerbinns) | Date: 2008-07-07 23:39 | |
I will ask on the MinGW lists. I am still curious as to how MinGW is supposed to know which MSVC library will be used at compile time since distutils doesn't tell it until link time. As a seperate issue Python isn't too helpful when an extension doesn't load :-) |
|||
msg69406 - (view) | Author: Roger Binns (rogerbinns) | Date: 2008-07-08 01:48 | |
I guess you can close this now. Unfortunately SourceForge goes out of its way to not make an easy link for the MinGW mailing list but you can see the messages on 8th July 2008: http://sourceforge.net/mailarchive/forum.php?forum_name=mingw-users&viewmonth=200807&viewday=8 Basically MinGW erroneously ships a .lib saying localtime is in MSVCR90.DLL when it isn't. That means there is no link failure but the pyd will fail to load without information as to why. Fixing the .lib means that localtime is picked up from MSVCRT.DLL (ie no version in name) and everything appears to work well. The MinGW project also claims they only support MSVCRT.DLL and not any of the numbered ones, so basically it is luck they work. Noone pointed out any compile time directives to direct versioning of MSVCRT. I guess this is more fuel for the semi-regular flame war about free software and free compilers on Windows, but not in this ticket! |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-11 14:56:36 | admin | set | github: 47558 |
2008-07-08 05:04:44 | loewis | set | status: open -> closed resolution: wont fix versions: + 3rd party |
2008-07-08 01:48:45 | rogerbinns | set | messages: + msg69406 |
2008-07-07 23:39:03 | rogerbinns | set | messages: + msg69404 |
2008-07-07 20:19:33 | loewis | set | messages: + msg69394 |
2008-07-07 19:18:51 | rogerbinns | set | messages: + msg69393 |
2008-07-07 12:36:05 | amaury.forgeotdarc | set | nosy:
+ amaury.forgeotdarc messages: + msg69382 |
2008-07-07 05:57:24 | rogerbinns | set | messages: + msg69381 |
2008-07-07 05:17:18 | loewis | set | messages: + msg69380 |
2008-07-07 04:44:06 | rogerbinns | set | messages: + msg69373 |
2008-07-07 04:29:42 | loewis | set | nosy:
+ loewis messages: + msg69370 |
2008-07-07 02:26:58 | rogerbinns | set | files:
+ localtime.zip messages: + msg69367 |
2008-07-07 01:16:05 | rogerbinns | set | messages: + msg69364 |
2008-07-07 00:16:19 | rogerbinns | create |