Skip to main content

2016-06-09: Compiler special meeting

Time: 14:00 UTC

Hangout link:



Compiler docker images:

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

Key points:

  • 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)
  • 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](

        * Private vote by next Thursday, fill out []([](
  • 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
  • MSYS2

    *   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?