search

msys2 / MINGW-packages

Package scripts for MinGW-w64 targets to build under MSYS2.
https://packages.msys2.org
BSD 3-Clause "New" or "Revised" License
2.29k stars 1.22k forks source link

Python doesn't come with static library #3562

Open uwehermann opened 6 years ago

uwehermann commented 6 years ago

Hi, please consider also providing a static Python library. It currently comes with a .dll and .dll.a (but no .a file). Python3 is one of two missing dependencies that would allow us to build sigrok (see www.sigrok.org) natively on Windows using MSYS2. Thanks!

lazka commented 6 years ago

Why can't you use the shared one?

uwehermann commented 6 years ago

We currently have working scripts to cross-build everything statically on Linux via MXE (mxe.cc), historically that didn't have shared libs support, everything was statically built. Even today we're still building everything statically, makes our NSIS installers and some other things easier as well.

Would be great if MSYS would consistently provide static as well as shared libs for everything as well, there's always pros and cons for both (and I'm sure we're not the only ones doing static builds for various reasons).

MSYS2 already ships both shared and static libs for quite a bunch of stuff, including glib, libusb, Qt, boost, and so on. Would be great if MSYS2 Python would do the same.

mingwandroid commented 6 years ago

Is this not an itch you can scratch? I.e. do the work and prove it works well then submit a pr?

lazka commented 6 years ago

(You didn't really answer my question)

mingwandroid commented 6 years ago

There are definite benefits to linking the Python interpreter itself statically too. Faster start up time and it allows you to consider enabling lto and pgo, but that's not going to be easy!

I don't know if anyone's ever attempted this on Windows though. Probably not.

At $day_job I build our Python interpreters statically with lto and pgo on Linux and macOS and they are much faster for it.

mingwandroid commented 6 years ago

.. lto and pgo can be used outside of static too. My windows msvc-based Python 3 builds for the Anaconda Distribution do this but combining all 3 features works best (at least on the other platforms).

But still the why? question is relevant. Pgo ads significant build time costs and all of it requires a big amount of work.

uwehermann commented 6 years ago

I'm afraid my spare time and Python knowledge may not be sufficient to scratch this specific itch myself right now. I might have a go at the other one (libzip, issue #3561) which is probably doable, but Python is likely too complex for me to tackle given my limited spare time.

Yes, in theory we could also try to use shared builds for everything (more work on our side, but it's doable, I assume). I don't see why the reason for our specific case would matter all that much, though. I can't imagine we're the only ones who ever want to use static builds (?)

As mingwandroid mentioned, there can be various reasons to prefer static builds either way. And seeing that MSYS2 already supports static builds for a lot of other stuff (Qt5 for example, which is also highly complex, or boost or whatnot) I don't see why Python should be an exception here.

Or, turning around the whole argument, why not remove static builds for all other MSYS2 packages if static builds are not a thing MSYS2 wants to support? (rethorical question, please don't do that, having static builds is a good thing :)

As for the "I don't know if anyone's ever attempted this on Windows though", yeah, I'm not really sure how complex that stuff is either. I think MXE (mxe.cc) didn't provide Python cross-builds either last time I checked (maybe for different reasons? don't know; it's been a while since I looked, though). However, that's a cross-build situation, which is probably more complex even than trying a native build.

I think the official Windows builds from python.org do ship static libs in general (?) so I'm assuming it should be possible in theory.

Another theoretical option would be to copy the .h files and .a libs from an upstream Windows build, but I'm not sure that would work if the rest of our libs come from MSYS2, right? I think I read in some other issue that Python (and potentially other libs on MSYS2?) are built in a way that's not compatible with anything outside of MSYS2.

irakhlin commented 6 years ago

Just for reference here I have used https://github.com/python-cmake-buildsystem/python-cmake-buildsystem to successfully build python2 using mingw64. To truly work correctly it would still need some additional changes to work into our build system but its an interesting starting point.