[SOLVED]_ftol2 could not be located in msvcrt.dll

Hi
When i run panda3d.exe of my own compile on Windows i’ve got this error:

The procedure entry point _ftol2 could not be located in the dynamic link library msvcrt.dll

The Windows machine(XP) is not the same machine(win7x64) that i built Panda3d on it.
But the downloaded runtime from panda3d.org runs fine.
These are dlls beside “panda3d.exe” when i install my built:

atl100.dll  mfc100u.dll  mfcm100u.dll  msvcr100.dll  mfc100.dll  mfcm100.dll  msvcp100.dll

So what wrong with my built?
Thanks.

I don’t think Panda itself has a direct dependency on msvcrt.dll. It may be one of the thirdparty packages or DLLs we ship along.

Use Dependency Walker on the target system and feed it one of the Panda DLLs that fails to load in order to find out which of the libraries pulls in msvcrt.dll as dependency, and specifically, the _ftol2 symbol.
dependencywalker.com/
Maybe it’s as easy as deleting a DLL, but maybe one of the thirdparty packages needs to be recompiled.

Also see this:
stackoverflow.com/questions/1856 … ink-librar

The error is related to libpanda.dll which has dependency to msvcrt.dll. this is my file list in “C:\Documents and Settings\Mehdi\Local Settings\Application Data\Panda3D\hosts\127.0.0.1_930cb61b13e95041\panda3d\seifi_1.9\win_i386” which is very different from your built:

API-MS-Win-Core-Console-L1-1-0.dll
API-MS-Win-Core-DateTime-L1-1-0.dll
API-MS-Win-Core-Debug-L1-1-0.dll
API-MS-Win-Core-DelayLoad-L1-1-0.dll
API-MS-Win-Core-ErrorHandling-L1-1-0.dll
API-MS-Win-Core-Fibers-L1-1-0.dll
API-MS-Win-Core-File-L1-1-0.dll
API-MS-Win-Core-Handle-L1-1-0.dll
API-MS-Win-Core-Heap-L1-1-0.dll
API-MS-Win-Core-IO-L1-1-0.dll
API-MS-Win-Core-LibraryLoader-L1-1-0.dll
API-MS-Win-Core-Localization-L1-1-0.dll
API-MS-Win-Core-LocalRegistry-L1-1-0.dll
API-MS-Win-Core-Memory-L1-1-0.dll
API-MS-Win-Core-Misc-L1-1-0.dll
API-MS-Win-Core-NamedPipe-L1-1-0.dll
API-MS-Win-Core-ProcessEnvironment-L1-1-0.dll
API-MS-Win-Core-ProcessThreads-L1-1-0.dll
API-MS-Win-Core-Profile-L1-1-0.dll
API-MS-Win-Core-String-L1-1-0.dll
API-MS-Win-Core-Synch-L1-1-0.dll
API-MS-Win-Core-SysInfo-L1-1-0.dll
API-MS-Win-Core-ThreadPool-L1-1-0.dll
API-MS-Win-Core-Util-L1-1-0.dll
API-MS-Win-Security-Base-L1-1-0.dll
cg.dll
cgD3D9.dll
cgGL.dll
Config.prc
IPHLPAPI.DLL
KERNELBASE.dll
libp3direct.dll
libp3dpython.dll
libp3dtool.dll
libp3dtoolconfig.dll
libp3tinydisplay.dll
libp3windisplay.dll
libpanda.dll
libpandadx9.dll
libpandaexpress.dll
libpandafx.dll
libpandagl.dll
libpandaphysics.dll
Microsoft.VC90.CRT.manifest
mscoree.dll
msvcm90.dll
MSVCP100.dll
msvcp90.dll
MSVCR100.dll
MSVCR90.dll
msvcrt.dll
nsi.dll
p3dpython.exe
p3dpythonw.exe
panda3d.seifi_1.9.win_i386.mf
panda3d.seifi_1.9.win_i386.xml
python27.dll
select.pyd
unicodedata.pyd
usage.xml
winnsi.dll
_hashlib.pyd
_socket.pyd
_ssl.pyd
_vfsimporter.pyd

Is this because i use python 2.76 instead of python 2.6 like in your built?

My build was Python 2.7 as well, but the difference might be that I compiled it from source using MSVC 2010. It might explain the existence of the VC90 manifest. I can’t be entirely sure, though.

I’m not really sure when you’re using your own Python 2.7.6 build when my own Python build (now the official 1.9.0 thirdparty packages) has a more recent Python version.

I see. i was comparing it with downloaded runtime by viewing an online demo which is older version.
I’m going to rebuild it with new thirdparties to see if it’ll work for me.

Just to make sure that i have the right thirdparty package, i downloaded it from here :
panda3d.org/download/panda3d … -win32.zip
And the included python is this:

Python 2.7.5 (default, May 15 2013, 22:43:36) [MSC v.1500 32 bit (Intel)] on win32

So it’s built by MSVC 2008 according to stackoverflow.com/a/2676904/459938 .
Sorry for asking alot, cause it’s gonna be a long compile process!

You’re right. It was a different build of Python that I had compiled with VC2010; not the one that made it into the thirdparty packages.

However, looking in depends.exe, python27.dll has no dependency on msvcrt.dll. So python is not the problem. You’d have to look which library is dragging in the msvcrt.dll dependency.

You could try compiling without support for several thirdparty packages like libpng, libtiff, openssl and zlib, and see if the dependency persists.

I’ve ran few tests. that error seems to happen only on XP machine(i have tested on two Win7 and one Xp).
I guess i’m stuck in DLL Hell!
Since you haven’t built runtime distribution on Windows yet, i’ve checked bot logs here: buildbot.panda3d.org/builders/rt … ps/compile
They are pretty the same as my log. only difference is about SSE2. could SSE2 be related to WinXP ?

I’ve tracked down p3dpython.exe dll dependency with depends.exe and i found there is a IPHLPAPI.DLL which may cause the error. here is my full log: dll_error.log (5.48 KB)
and this is info for this dll on Windows 7: win7dll.info/iphlpapi_dll.html
and for Windows XP: xpdll.nirsoft.net/iphlpapi_dll.html
They have different dependencies.
I’m not sure if i compile Panda on an XP machine what would be the result. But i guess the Panda build system should skip some basic system dlls in order to avoid dll hell!

It would be nice to have your runtime distribution on win32 to compare running results with mine.
Thanks.

It’s a DLL that’s part of windows. I don’t think we should be including it. You could try removing it from the build and see if it works then.

In fact, I suggest that this might be the problem: that ppackage is overzealous in picking up dependencies and accidentally picking up some Windows 7 system DLLs.

Since the buildbot is also Win7, it is likely that it’ll get the same results (rather than if it were a WinXP machine, in which case it couldn’t pick up old DLLs). I’m afraid I don’t have a WinXP machine to try it on myself.

But wait, you said that MSVCRT.lib is a direct dependency of libpanda.dll. This does still sound to me like a problem. You might specify /NOD:MSVCRT.lib to the linker command-line (search for /NOD and add it to the rest) to prevent it from being picked up, but that might cause a different error. It’d be good to find the thirdparty package that pulls in MSVCRT.lib.

That’s exactly what i meant. this package is my problem:
c:\documents and settings\mehdi\local settings\application data\panda3d\hosts\127.0.0.1_930cb61b13e95041\panda3d\seifi_1.9\win_i386
Which is the main package. i have some basic system dll there like IPHLPAPI.DLL or bunch of dlls like API-MS-Win-Core-***.dll or even KERNELBASE.DLL !!
If i remove them they’ll come back as soon as i run my app. plus i removed or replaced MSVCRT.DLL in this folder with WinXP system32 one, then i ran p3dpython.exe but with the same error: _ftol2 could not be located in msvcrt.dll. it’s a complex conflict :frowning:
If you checked my attached log at line 40 i have MSVCRT.DLL loaded:

Loaded "c:\windows\system32\MSVCRT.DLL" at address 0x77C10000.  Successfully hooked module.

But then at the end:

Loaded "c:\documents and settings\mehdi\local settings\application data\panda3d\hosts\127.0.0.1_930cb61b13e95041\panda3d\seifi_1.9\win_i386\IPHLPAPI.DLL" at address 0x40C90000.  Successfully hooked module.
Second chance exception 0xC0000139 (DLL Not Found) occurred in "c:\windows\system32\NTDLL.DLL" at address 0x7C967406.

It tries to load IPHLPAPI.DLL from package not the system32 one which in depends.exe shows that it has dependency to different MSVCRT.DLL. also there is a utility called ListDLLs in here technet.microsoft.com/en-us/sys … 96656.aspx which gaves me interesting log for p3dpython.exe:

  *** Loaded msvcrt.dll differs from file image:
  *** File timestamp:         Tue Jul 14 05:37:59 2009
  *** Loaded image timestamp: Wed Oct 29 13:18:57 2008

I’m going to dig more but do i have to start over compile process for every changes in source files? or there is a way to just create packages in stage folder with less overzealous dependency checking?

I found these threads on msdn forums which may leads to solution:
social.msdn.microsoft.com/Forum … =vcgeneral
social.msdn.microsoft.com/Forum … -and-win-7
I guess i should check/update opengl32.dll in both Windows.

If you dig in direct/src/p3d/Packager.py search for “excludeSystemFiles”. You’ll see a list of dlls there where you can add the ones to exclude.

Makepanda shouldn’t rebuild anything unnecessarily as long as you don’t change the flags you pass to it and any C++ header or source files.

You can of course run the command that makepanda uses to build the package manually, as long as you set up your environment properly. You’d first have to copy your modified direct/src/p3d/Packager.py to built_seifi/direct/p3d/ and then run ppackage.py manually, emulating the proper environment.

C:\thirdparty\win-python\python.exe -OO -B direct/src/p3d/ppackage.py -i "built/stage" -a "1.9" direct/src/p3d/panda3d.pdef

(Substitute with the version of Python you are using, of course, and set PYTHONPATH properly to point to built_seifi and built_seifi/bin, etc.)

I’m almost sure that some of Win7 specific dlls should be removed from the package in order to my built works.
So i added some system dlls that should have not been packed into my built(panda3d.seifi_1.9.win_i386.mf.pz) like kernelbase.dll or msvcrt.dll in “excludeSystemFiles”. then i set PYTHONPATH and tried to run the command from panda source directory:

C:\Panda3d\src> thirdparty\win-python\python.exe -OO -B direct\src\p3d\ppackage.py -i "built_seifi/stage" -a "1.9" .\direct\src\p3d\panda3d.pdef

But i’ve got this:

This script must be run using a version of Panda3D that has been built
for distribution.  Try using ppackage.p3d or packp3d.p3d instead.
If you are running this script for development purposes, you may also
set the Config variable panda-package-host-url to the URL you expect
to download these contents from (for instance, a file:// URL).

?

As I said, the environment must be set up such that it uses the rtdist build. This means setting your PATH and PYTHONPATH settings to point to the appropriate directories in built_seifi (I think PATH to built_seifi/bin and PYTHONPATH to both built_seifi and built_seifi/bin).

Finally it’s solved.
I added these DLLs in “excludeSystemFiles”:

'KERNELBASE.DLL', 'IPHLPAPI.DLL', 'iphlpapi.dll', 'msvcrt.dll', 'VERSION.dll', 
'VERSION.DLL', 'version.dll', 'winnsi.dll', 'nsi.dll',

And this pattern in “excludeSystemGlobs”:

GlobPattern('API-MS-Win-Core-*.dll'),

At first i couldn’t get rid of VERSION.dll so i added different caps but maybe i’m wrong.
Then i removed stage folder and re-run makepanda…And now i’m happy! :smiley:

By the way after i set the PATH and PYTHONPATH as you said, i’ve got complain about couldn’t find VC compiler. then i used VC command prompt and ran the command successfully.

Thanks for your supports.

Great! I’ll be making these changes to the GitHub repository soon. Thanks so much for your efforts!

So none of these DLLs are required on Windows XP? It doesn’t give a missing DLL error when you run it on WinXP?

Except for "API-MS-Win-Core-.dll", the WinXP has its own version of those dlls in system32. by including them from Win7 the conflict will happen. and i’m sure the API-MS-Win-Core-.dll files won’t be needed on XP.
But to make sure i will setup a fresh virtual WinXP machine to see how my app will run there. Also i’ll test it on Win8.1 too.

Yeah, it’s working nice!
I’ve tested my build on an old WinXP machine with intel onboard vga and the result was pretty good!

Great to hear! Thanks for your help!
Note that excludeSystemFiles requires files added to be in lowercase, otherwise it won’t match case insensitively.

I altered Packager.py to print out a tree of dependencies. Here’s what I found out:
It’s msvcrt.dll that pulls in the dependencies to KERNELBASE.dll and API-MS-Win-Core-*.dll. So, as long as the target computer has a version of msvcrt.dll that doesn’t have these new-fangled DLLs, it should work.

And indeed, if I only add iphlpapi.dll and msvcrt.dll to the list, it doesn’t pick up any of the others, at least not as part of the panda3d package (though it’s still good to add them to excludeSystemGlobs, of course).

These are DLLs that pull in msvcrt:

  • msi.dll, pulled in by _msi.pyd, part of Python
  • msacm32.dll, pulled in by fmodex64.dll, part of FMOD Ex
  • the ffmpeg DLLs

Could you check for me if either of those still works in your WinXP box without shipping msvcrt? The easiest to check would probably be msi, by seeing if you can use the Python msilib module.

If it still works, then that means we don’t need to ship msvcrt.dll at all. If you get missing DLL errors, we’d have to copy msvcrt.dll from an old copy of the MSVC redistributable package and make sure we link to that instead.

I just made a simple terrain example into a p3d file with this extera code:

print(msilib.gen_uuid())

And it just worked.(i removed my SDK and Panda3d folder in app data before running)
From what i googled msvcrt.dll should not redistribute by final C++ application. that’s why microsoft invented vc++ runtimes which contain msvcrtxx.dll and … . i guess these act like a proxy for system msvcrt.dll (but i’m not a C++ developer) :wink: