2016-06-09: Compiler special meeting

Time: 14:00 UTC

Hangout link: https://hangouts.google.com/call/v5olhwzpfzgzpoq5i3wthjpqpie

Attendees

Agenda

Compiler docker images:

Centers of discussion:

  • Need of libstdc++ updates / shadowing

  • Language compatibility needs (C++11/14)

As time allows: MSYS2 on Windows

Notes

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,

Future

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

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