[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler

Mark Mikofski added the comment: still have the `link.exe` 1561 error without `extra_args=['/DLL']` issue. is there a patch? It goes in `distutils._msvccompiler` right? -- nosy: +bwanamarko ___ Python tracker

[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler

Changes by Steve Dower : -- resolution: -> out of date status: open -> closed ___ Python tracker ___

[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler

Christoph Gohlke added the comment: Just to confirm: the following script fails with `ImportError: DLL load failed` on Python 3.5.0rc2. It fails around the 120th extension. The script passes on Python 3.4.3. Also, Python 3.5.0rc2 (not Python 3.4.3) requires the `extra_postargs=['/DLL']`

[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler

Christoph Gohlke added the comment: > Do you know where that time is being spent? The incremental linker. > I'd guess it's probably O(N**2) with the number of obj file Doesn't seem so. For example the pyrxp 2.1 package contains only 23 C files and takes minutes to link. Most packages compile

[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler

Steve Dower added the comment: It may be possible to dynamically link the Fortran library in a similar fashion, though it depends on what code the compiler generates. For Python's purposes, statically linking it probably isn't a bad idea. I'll have to check out whether the FLS limitation

[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler

Christoph Gohlke added the comment: I have now recompiled hundreds of Python packages and C/C++/Fortran libraries with the `/MT /GL /LTCG /NODEFAULTLIB:libucrt.lib ucrt.lib` flags. Many packages test OK, only few crashes. Some more findings: The /MT flag forces to also statically link the

[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler

Steve Dower added the comment: The FLS limit is definitely still there, and it still seems to be 127, which would explain the issues. Best fix I have for this is to build with /MD and force vcruntimeXXX.dll to always be copied alongside builds. That will solve the installation issue and the

[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler

Christoph Gohlke added the comment: Two findings regarding the new semi-static linking options: Distutils now creates libraries (.lib) that may not be readable by subsequent versions of Visual C++ https://msdn.microsoft.com/en-us/library/0zza0de8.aspx. Build times and static library sizes

[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler

Marc-Andre Lemburg added the comment: If I understand you correctly, the only advantage of using /MT is not require admin privileges for installation of the VC2015 runtime libs. Since VC2015 will be used by a lot of applications in a few months, and it's likely that MS will ship the runtime as

[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler

Steve Dower added the comment: Unfortunately applocal deployment doesn't solve the versioning issue - you'll always need to use VS 2015 to build for Python 3.5. There are only a few more libraries that are affected by /MT. msvcp140.dll is the most likely one here. Doing the same /nodefaultlib

[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler

Steve Dower added the comment: We can't have Python run VCredist because it requires administrative privileges and installing Python does not require those. This is actually one of the biggest complaints about the current installer, but because it looks like the design and not a bug it only

[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler

Marc-Andre Lemburg added the comment: On 17.08.2015 18:24, Steve Dower wrote: We can't have Python run VCredist because it requires administrative privileges and installing Python does not require those. This is actually one of the biggest complaints about the current installer, but

[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler

Steve Dower added the comment: Why not [require administrative privileges]? Because some people want to use Python and don't have administrative permissions on their own machine (e.g. students, employees, researchers, etc.) The standard approach is to rebuild extension for every minor

[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler

Christoph Gohlke added the comment: The matplotlib extensions compiled with Python 3.5.0rc1 (/MT) are larger than those compiled with 3.5.0b4 (/MD). The C++ runtime is statically linked. This seems undesirable for the same reasons the UCRT is not linked statically. In Introducing the

[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler

Christoph Gohlke added the comment: Another /MT only issue: cryptography-1.0 and other libraries depending on openssl fail to link to static MT openssl-1.0.1p: cryptlib.obj : error LNK2001: unresolved external symbol __iob_func This can be fixed manually [1]. [1]

Re: [issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler

On 15.08.2015 22:41, Steve Dower wrote: Marc-Andre: there are a few concerns with including DLLs that aren't new with any of the 3.5 changes. * depending on another CRT version is fine *if* it is available (users may have to be told/helped to install the redistributable themselves) *

[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler

Christoph Gohlke added the comment: FWIW, I rebuilt static libraries for zlib, jbig, jpeg, openjpeg, tiff, webp, lcms, and freetype with /MT flag (a tedious task) and was able to build matplotlib and Pillow using Python 3.5.0rc1. As expected there is no dependency on the vcruntime DLL. Even

[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler

Steve Dower added the comment: I expect that, but most extensions don't seem to be in that category so this will help remove the administrator barrier. Thanks for going through that tedious process. I'll put up a patch later today and submit for 3.5.0. --

[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler

Steve Dower added the comment: Actually, on rereading this (during daylight hours, previous response was before 6am my time) the patch wouldn't help. I need to write some porting notes for rebuilding static libraries with suitable settings. I'll base it on my initial post and find somewhere

[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler

Changes by Steve Dower steve.do...@python.org: -- components: +Documentation, Extension Modules priority: release blocker - high ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24872 ___

[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler

Christoph Gohlke added the comment: Matplotlib and my own extensions are using C++ sources but do not depend on msvcp140.dll, just the ucrt. Am I missing something? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24872

[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler

Christoph Gohlke added the comment: Thanks for going through that tedious process ~140 libraries to go. I hit the wall last night trying to build Boost DLLs. Boost's build tool b2 does not allow `link=shared runtime-link=static`, hence the `/MT /LTCG /NODEFAULTLIB:libucrt.lib ucrt.lib` magic

[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler

Steve Dower added the comment: Boost requires C++ anyway doesn't it? So the full redist will be required. These options are only useful for pure C sources. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24872

[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler

Steve Dower added the comment: Probably I'm missing something. Maybe there's a subset of C++ that doesn't rely on it - a decent amount of the standard template library is generated at compile time. If the dependency isn't there, it'll be fine. Do you think it'll be worth having a check box

[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler

Changes by Steve Dower steve.do...@python.org: -- nosy: +larry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24872 ___ ___ Python-bugs-list

[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler

New submission from Steve Dower: The C Runtime used for Python 3.5 and later consists of two DLLs. One, ucrtbase.dll, is an operating system component that can be assumed to be available and up to date (or will be installed by the Python installer). The second DLL is vcruntimeXXX.dll, where

[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler

Christoph Gohlke added the comment: Thank you for looking into this. I just tried '/NODEFAULTLIB:msvcrt.lib' with Pillow and matplotlib but still get the linker errors: tiff.lib(jbig.obj) : error LNK2001: unresolved external symbol __imp_memchr freetype.lib(ftbase.obj) : error LNK2001:

[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler

Marc-Andre Lemburg added the comment: What effect does this static linking of the VC runtime have on libraries that extension modules link at dynamically ? E.g. say I have an extension which links against an ODBC driver DLL using a different VC runtime than the one used to build Python. In

[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler

Steve Dower added the comment: I guess those imports are expected to come from vcruntime. Rebuilding the static libraries may be the only option then, sorry (on the bright side, VC 14 has much better C99 support than earlier versions, so things should be better once we get past the problems