Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows bootloaders in releases posted on PyPI requires msvcr*.dll #2343

Closed
NathanDunfield opened this issue Jan 1, 2017 · 17 comments

Comments

@NathanDunfield
Copy link

commented Jan 1, 2017

The documentation says that the Windows bootloader "is a self-contained static executable that imposes no restrictions on the version of Python being used". In fact, this is not the case for the bootloaders that are posted on PyPI: the ones for PyInstaller 3.2 depend on msvcr100.dll and the ones for PyInstaller 3.1.* (which I was using to get around a bug in 3.2) depend on msvcrt.dll. Anyway, this can result in "crash on startup" for some PyInstaller Windows apps based on Python 2.7 (which uses msvcr90.dll) when one imports certain other binary Python modules.

Following the documentation, compiled my own Windows bootloaders using the MSVC compilers on AppVeyor, and these were free of any reference to msvcr*.dll and eliminated the crashes I was having completely. So perhaps the official releases were built with some other toolchain? Regardless, it would be great if future releases were truly static, as it took a lot of time to track down what was causing my problem. Here is my AppVeyor build script as well as a wheel built off the current tip in case this is helpful to someone.

@marcelstoer

This comment has been minimized.

Copy link

commented Jan 4, 2017

the ones for PyInstaller 3.2 depend on msvcr100.dll

Yep, just hit that as well.

@marcelstoer

This comment has been minimized.

Copy link

commented Jan 6, 2017

Using the latest dev through pip install https://github.com/pyinstaller/pyinstaller/archive/develop.zip fixes this but GitHub ain't PyPI, I know...

@htgoebel

This comment has been minimized.

Copy link
Member

commented Feb 3, 2017

I take the last comment as "fixed", esp since 3.2.1 is released in the meantime.

@htgoebel htgoebel closed this Feb 3, 2017

@htgoebel htgoebel added this to the Pyinstaller 3.2.1 milestone Feb 3, 2017

@htgoebel htgoebel added the v3.2 label Feb 3, 2017

@htgoebel htgoebel changed the title Windows bootloaders in releases posted on PyPI are not actually static. Windows bootloaders in releases posted on PyPI requires msvcr*.dll Feb 3, 2017

@NathanDunfield

This comment has been minimized.

Copy link
Author

commented Feb 4, 2017

@htgoebel: Unfortunately, both PyInstaller 3.2.1 and the development version still depend on "msvcrt.dll", so I think you should reopen this ticket. I believe what @marcelstoer is referring to is that they no longer depend on "msvcr100.dll", which fixed his problem, but it doesn't fix mine.

You can use dumpbin.exe /dependents on the contents of PyInstaller/bootloader/Windows/-*/run*.exe to see the current references to "msvcrt.dll" in contrast to the version I compiled by hand.

@htgoebel

This comment has been minimized.

Copy link
Member

commented Feb 4, 2017

Thanks for coming back to this. I'm sorry that 3.2.1 does not solve the problem.

We are using MinGW for building the boolader since this can be used for cross-building. I just found this blog entry saying:

When compiling C projects, use {i686,x86_64}-w64-mingw32-gcc. The resulting binary will depend on at least KERNEL32.DLL and whatever MSVCRT.DLL is on clients' systems. Therefore, you'll need to make sure clients have the Microsoft C Runtime installed to use your software.

This is not a good news :-(

Edit: Addendum:
Said blog-entry links to outdated urls, here are working ones:

@htgoebel htgoebel reopened this Feb 4, 2017

@htgoebel

This comment has been minimized.

Copy link
Member

commented Feb 4, 2017

@codewarrior0 Any idea how we can solve this? E.g. by using clang?

@htgoebel

This comment has been minimized.

Copy link
Member

commented Feb 4, 2017

@codewarrior0

This comment has been minimized.

Copy link
Member

commented Feb 4, 2017

@NathanDunfield Which version of Windows does this issue happen on?

@NathanDunfield

This comment has been minimized.

Copy link
Author

commented Feb 4, 2017

@codewarrior0: I have the issue on both Win7 and Win10, haven't tried other versions.

I don't know how you're building the bootloaders now, but AppVeyor provides both MinGW and every version of the Microsoft compilers. I have used it to build various Python modules using both toolchains. Here is the AppVeyor build script that I used to produce bootloaders that don't depend on msvcr*.dll.

@codewarrior0

This comment has been minimized.

Copy link
Member

commented Feb 4, 2017

So the only thing you changed is to build with MSVC 9.0?

@NathanDunfield

This comment has been minimized.

Copy link
Author

commented Feb 4, 2017

Yes, switching to MSVC solves the problem. It doesn't have to be MSVC 9.0, I also tested with MSVC 14.0 (=Visual Studio 2015). In fact, for the 64-bit bootloader, you need to use the more recent version. In particular, the --msvc_version flag on line 10 of my build script isn't needed, though MSVC 9.0 produces somewhat smaller binaries than MSVC 14.0. On line 11 of the build script, it just uses AppVeyor's default which is MSVC 14.0.

@codewarrior0

This comment has been minimized.

Copy link
Member

commented Feb 5, 2017

That's a bit surprising. I remember building the bootloader using MSVC 9.0, 10.0, and 14.0 about a year ago and the resulting binaries always depended on the MSVCR??.DLL appropriate to the compiler. Something must have changed with our wscript between then and now to cause MSVC to start linking the C runtime statically.

@htgoebel

This comment has been minimized.

Copy link
Member

commented Feb 5, 2017

I prefer to find a solution which does not require proprietary software (mvsc) to build.

@htgoebel

This comment has been minimized.

Copy link
Member

commented Feb 27, 2017

I spent quite some time on this again again and chatted the mingw-guys:

  • When using MSVC compiler, it links statically with msvcrt.
  • When using mingw (as we do), there is no static msvcrt, thus it links to msvcrt.dll.
  • Option would be to statically link with some other runtime-library, but I'm not aware of one.
    • I tried building newlib with mingw, but this failed. I also tries to use the pre-build newlib coming with cygwin, but linking failed with "multiple definition" errors.
@htgoebel

This comment has been minimized.

Copy link
Member

commented Mar 13, 2017

Another possibility would be to used some stub c-library like https://github.com/nothings/stb which we used earlier already.

@htgoebel

This comment has been minimized.

Copy link
Member

commented Jun 27, 2017

I updated our Vagrantfile's Windows machine so we can build the bootloader using Visual C++ (see #2415 (comment)). I ask you to try the bootloaders in that branch and maybe even the Vagrantfile and building the bootloaders. Instructions how to test this easily are in teh aforementioned comment.

Thanks a lot.

@NathanDunfield

This comment has been minimized.

Copy link
Author

commented Jun 28, 2017

@htgoebel I checked out the new bootloaders with "dumpbin /dependents" and they all look great --- no references to any msvc*.dll as desired. I also tried them out in the application that prompted my initial report, and they work fine there as well. So I definitely think #2415 would solve #2343, which is excellent news!

@htgoebel htgoebel closed this in aef61ed Jul 17, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.