2016-06-09: Compiler special meeting¶
Time: 14:00 UTC
Hangout link: https://hangouts.google.com/call/v5olhwzpfzgzpoq5i3wthjpqpie
Compiler docker images:
* `docker pull condaforge/linux-anvil`
Built on Quay ( https://quay.io/repository/condaforge/linux-anvil )
Mirrored ( https://hub.docker.com/r/condaforge/linux-anvil/ )
CentOS 6, GCC 4.4.7, Devtoolset2 (GCC 4.8)
Source code ( https://github.com/conda-forge/docker-images/tree/fbde090bd608caa720d5caad861aa382a8bf3f5c/linux-anvil )
* CentOS 5, GCC 4.4, Devtoolset2 (GCC 4.8)
GCC 4.8 on PATH by default
Centers of discussion:
Need of libstdc++ updates / shadowing
Language compatibility needs (C++11/14)
As time allows: MSYS2 on Windows
Overview of the Docker images
conda-forge and bioconda seems to use same GCC version
Need to monitor if we need to ship libstdc++
* Not needed if use Devtoolset
But users may still need to install if they are missing this library, like Arch linux, so we may want to ship this anyway
Need to say what language standard we are going to support C++14?
Legacy ABI support for old libraries (dual API, issues with older/newer ABI)
History on conda-forge
Initial conda-forge used gcc package
sometimes this would cause issues if packages were not pinned
switched to devoolset2 which does the static linking trick,
Use devtoolset4? (GCC 5.3, available on CentOS6)
Build our own compiler toolchain
GCC 6, could have some issues
Could have devtoolset2 and devtoolset4 installed in same Docker image
* Need to have some mechanism to activate a particular toolset
Using devtoolset does limit OS (CentOS5 only supports devtoolset2 not 4)
Could we build our own devtoolset?
* Patches are available (srpm)
Not small task, but do we want to take this on?
Here is a link for some source ( https://git.centos.org/commit/rpms!devtoolset-4-gcc/e14f97005a3d22e658d01d0fc8899f5bda1982ca )
Using Docker image from Continuum
* Would need to ship libstdc++ and keep it up to date to avoid shadowing system version (need to be newer than users with newest version)
Not many package in defaults link against libstdc++
Have been shipping and has not seen issue yet…
Julia has been doing this
libgfortran was broken because defaults was shipping old version which causes issues if user has more recent version of library installed
Could we have a version of libstdc++ conda package which nothing depends on but users could install if they are missing a system libstdc++?
Current infrastructure may not be able to support building gcc, but we could user other systems for this.
Continuum needs to support CentOS 5, conda-forge is happy with CentOS6 as minimum glibc version
John will do this. (After some discussion it became unclear whether this was best approach; so, holding off for now.)
Should have common build environment
How to support fortran on Mac
* New to use gfortran and have packages depend on libgfortran? package
May be out of date, should we update?
Port this solution to Linux?
* Either use patches or ship libstdc++
Have same package for Mac and Linux OR use devtoolset magic?
* Want time to think and advantages and disadvantages for both * [Hackpad](https://conda-forge.hackpad.com/Devtools-vs-Ship-libstdc-Oz7Qqr4WrOr) * Private vote by next Thursday, fill out (http://goo.gl/forms/CexagdweBOKZZDjv1)[http://goo.gl/forms/CexagdweBOKZZDjv1](http://goo.gl/forms/CexagdweBOKZZDjv1)
Come up with a list of gcc 6.x problems that are encountered.
Why use clang vs gcc on Mac
* gcc has been remove in recent version of OS X
* Can be useful to get devtools
What about “alternative” MSYS2 Python environment
Visual Studio and MSYS2 gcc are not compatible
gfortran is big target (at least for Jonathan)
msys2-w64 packages/channels on Anaconda Cloud
OpenBLAS… does seem to be working on Windows
Does this work with VS 2015?
Use ATLAS instead of OpenBLAS for windows numpy?
* Would need to repackage binary ATLAS DLL
Get some BLAS build even if it is not the best
How are SciPy Windows wheels being built?