On Jan 21, 2016 9:32 AM, "Donald Stufft" <don...@stufft.io> wrote: > > > > On Jan 20, 2016, at 10:55 PM, Nathaniel Smith <n...@pobox.com> wrote: > > > > The permitted external shared libraries are: :: > > > > libpanelw.so.5 > > libncursesw.so.5 > > libgcc_s.so.1 > > libstdc++.so.6 > > libm.so.6 > > libdl.so.2 > > librt.so.1 > > libcrypt.so.1 > > libc.so.6 > > libnsl.so.1 > > libutil.so.1 > > libpthread.so.0 > > libX11.so.6 > > libXext.so.6 > > libXrender.so.1 > > libICE.so.6 > > libSM.so.6 > > libGL.so.1 > > libgobject-2.0.so.0 > > libgthread-2.0.so.0 > > libglib-2.0.so.0 > > > Forgive my, probably stupid, question… but why these libraries? Are these > libraries unable to be reasonably statically linked like glibc is?
It's not a stupid question at all :-). What we want is a list of libraries that are present, and compatible, and relevant, across the Linux distributions that most people use in practice. Unfortunately, there isn't really any formal specification or published data on this -- the only way to make such a list is to make a guess, start distributing software to lots of people based on your guess, wait for bug reports to come in, edit your list to avoid the problematic libraries, add some more libraries to your list to cover the new packages you've added to your distribution and where you think the risk is a worthwhile trade off versus just static linking, then repeat until you stop getting bug reports. This is expensive and time consuming and requires data we don't have, so we delegated: the list in the PEP is exactly the set of libraries that Continuum's Anaconda distribution links to and a subset of the libraries that Enthought's Canopy links to [1]. They've both been going through the loop above for years, with lots of packages, and lots of lots of downloads, so we're piggybacking off their effort. Here's the list of packages in Anaconda: http://docs.continuum.io/anaconda/pkg-docs -n [1] why only a subset of Canopy's libraries? because when we analyzed the latest release of Canopy we found several weird libraries that we knew must be mistakes and being pulled in by code paths that were never used in practice, so we decided to be conservative about trusting their library list. We're in contact with their distribution folks and might add some more libraries to this list if they come back to us and assure us that those libraries have actually been tested.
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
