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 erik.bray
Recipients erik.bray
Date 2016-06-23.15:20:36
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1466695238.23.0.601958974473.issue27374@psf.upfronthosting.co.za>
In-reply-to
Content
When building Python on Cygwin, both a libpython-X.Y.dll and a
libpython-X.Y.dll.a are created (see https://cygwin.com/cygwin-ug-net/dll.html).

The latter is an "import library"
consisting of stubs for functions in the DLL so that it can be linked
to statically when building, for example, extension modules.

The odd bit is that in the altbininstall target if the
$(DLLLIBRARY) variable (which references the .dll itself) is defined then only it is installed, while $(LDLIBRARY) (which in this cases references the .dll.a import library) is *not* installed, except in $(prefix)/lib/pythonX.Y/config, which is not normally on the linker search path, or even included by
python-config --ldflags.

Therefore static linking to libpython fails, unless the search path is explicitly modified, or a symlink is created from $(prefix)/lib/pythonX.Y/config/libpython.dll.a to $(prefix)/lib.  In fact the Makefile already does the latter, again not if $(DLLLIBRARY) is defined.

In fact Cygwin's own package for Python manually creates the latter symlink in its install script.  But I would consider it a bug in Python's Makefile that it doesn't handle this.

I first asked on Python-dev about this back in April but got no reply (understandably) probably due to the lack of core devs who can comment on Cygwin :)
History
Date User Action Args
2016-06-23 15:20:38erik.braysetrecipients: + erik.bray
2016-06-23 15:20:38erik.braysetmessageid: <1466695238.23.0.601958974473.issue27374@psf.upfronthosting.co.za>
2016-06-23 15:20:38erik.braylinkissue27374 messages
2016-06-23 15:20:37erik.braycreate