> Right. There's a small problem which is that the base linux system > isn't just "CentOS 5", it's "CentOS 5 and here's the list of libraries > that you're allowed to link to: ...", where that list is empirically > chosen to include only stuff that really is installed on ~all linux > machines and for which the ABI really has been stable in practice over > multiple years and distros (so e.g. no OpenSSL). > > So the key next step is for someone to figure out and write down that > list. Continuum and Enthought both have versions of it that we know > are good... > > Does anyone know who maintains Anaconda's linux build environment?
I strongly suspect it was originally set up by Aaron Meurer. Who maintains it now that he is no longer at Continuum is a good question. We build "generic Linux binaries" for Julia and I co-maintain that environment. It's using CentOS 5 (for now, until we hit an issue that is easiest to fix by upgrading the builders to CentOS 6 - I don't think we have any real users on CentOS 5 any more so no one would notice the bump), but we avoid using the Red Hat devtoolset. We tried it initially, but had issues due to the way they attempt to statically link libstdc++ and libgfortran. The -static-libgfortran GCC flag has been broken since GCC 4.5 because libgfortran now depends on libquadmath, and it requires rather messy modification of every link line to change -lgfortran to an explicit absolute path to libgfortran.a (and possibly also libquadmath.a) to really get libraries like BLAS and LAPACK statically linked. And if you want to statically link the GCC runtime libraries into a .so, your distribution's copies of libstdc++.a, libgfortran.a, etc must have been built with -fPIC, which many are not. Some of the issues where this was discussed and worked out were: https://github.com/JuliaLang/julia/issues/8397 https://github.com/JuliaLang/julia/issues/8433 https://github.com/JuliaLang/julia/pull/8442 https://github.com/JuliaLang/julia/pull/10043 So for Julia we wound up at building our own copy of latest GCC from source on CentOS 5 buildbots, and shipping private shared-library copies of libgfortran, libstdc++, libgcc_s, and a few others. This works on pretty much any glibc-using Linux distribution as new or newer than the buildbot. It sadly doesn't work on musl distributions, ah well. Rust has been experimenting with truly static libraries/executables that statically link musl libc in addition to everything else, I'm not sure how practical that would be for numpy, scipy, etc. If you go this route of building gcc from source and depending on private copies of the shared runtime libraries, it ends up important that you pick a newer version of gcc than any of your users. The reason is for packages that require compilation on the user's machine. If you build and distribute a set of shared libraries using GCC 4.8 but then someone on Ubuntu 15.10 tries to build something else (say as an example, pyipopt which needs a library that uses both C++ and Fortran) from source using GCC 5.2, the GCC 4.8 runtime libraries that you built against will get loaded first, and they won't contain newer-ABI symbols needed by the GCC 5.2-built user library. Sometimes this can be fixed by just deleting the older bundled copies of the runtime libraries and relying on the users' system copies, but for example libgfortran typically needs to be manually installed first. _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
