On 19 May 2015 at 16:22, Chris Barker <chris.bar...@noaa.gov> wrote: > The other issue is social: this would really only be a benefit if a wide > variety of packages shared the same libs -- but each of those packages is > maintained by different individuals and communities. So it's had to know if > it would get used. I could put up a libpng wheel, for instance, and who > knows if the Pillow folks would have any interest in using it? or the > matplotlib folks, or, ... And this would be particularly difficult when the > solution was hacked together...
Honestly, I still haven't seen a solid explanation of why (at least on Windows) static linking isn't a viable option. If someone were to create and publish a Python compatible static ".lib" file for the various hard-to-build dependencies, extensions could specify that you link with it in setup.py, and all the person building the wheel has to do is download the needed libraries for the build. If there's a technical reason why dynamic linking at runtime is better than static linking (sufficiently better that it justifies all the effort needed to resolve the issues involved), then I've yet to see a good explanation of it. The only things I've seen are disk space, or maintenance (where this usually means "it's easier to release a new DLL with a security fix than get all the various statically linked packages updated - that's a valid point, but given how hard it is to get a working dynamic linking solution in this environment, I have to wonder whether that argument still holds). All of this applies to Windows only, of course - dynamic linking and system management of shared libraries is very much a per-platform issue, and I don't pretend to know the trade-offs on OSX or Linux. Paul _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
