Is libgcc (as opposed to libgcc-ng) needed for openbabel?

[amarkpayne]

I recently ran into an issue where we thought that having packages that depend on libgcc and libgcc-ng caused problems (see conda issue here). We were told to rebuild all of our dependencies that required libgcc in favor of libgcc-ng, which included openbabel. I took a look at your conda recipe for 2.4.1 (python 2.7 version shown, but python 3.7 version has the same features) and found something interesting: openbabel requires libgcc-ng to build, but libgcc instead is listed as a requirement to run.

# This file created by conda-build 3.17.7
# meta.yaml template originally from:
# /recipe, last modified Sat Jan 19 10:20:14 2019
# ------------------------------------------------

package:
    name: openbabel
    version: 2.4.1
source:
    fn: openbabel-2-4-1.zip
    patches:
        - fix_babel_test_paths.diff
        - fix_data_path.diff
        - fix_library_path_search.diff
        - python_link.diff
    sha1: 6fefb2355601b665bea5840fe8e6f95bd48023c9
    url: https://github.com/openbabel/openbabel/archive/openbabel-2-4-1.zip
build:
    detect_binary_files_with_prefix: true
    number: '5'
    string: py27_5
requirements:
    build:
        - bzip2 1.0.6 h14c3975_5
        - ca-certificates 2018.03.07 0
        - cairo 1.14.12 h8948797_3
        - certifi 2018.11.29 py27_0
        - cmake 3.12.2 h52cb24c_0
        - eigen 3.2.8 2
        - expat 2.2.6 he6710b0_0
        - fontconfig 2.13.0 h9420a91_0
        - freetype 2.9.1 h8a8886c_1
        - glib 2.56.2 hd408876_0
        - icu 58.2 h9c2bf20_1
        - krb5 1.16.1 h173b8e3_7
        - libcurl 7.63.0 h20c2e04_1000
        - libedit 3.1.20170329 h6b74fdf_2
        - libffi 3.2.1 hd88cf55_4
        - libgcc-ng 8.2.0 hdf63c60_1
        - libpng 1.6.36 hbc83047_0
        - libssh2 1.8.0 h1ba5d50_4
        - libstdcxx-ng 8.2.0 hdf63c60_1
        - libuuid 1.0.3 h1bed415_2
        - libxcb 1.13 h1bed415_1
        - libxml2 2.9.8 h26e45fe_1
        - ncurses 6.1 he6710b0_1
        - openssl 1.1.1a h7b6447c_0
        - pcre 8.42 h439df22_0
        - pip 18.1 py27_0
        - pixman 0.36.0 h7b6447c_0
        - python 2.7.15 h9bab390_6
        - readline 7.0 h7b6447c_5
        - rhash 1.3.7 h1ba5d50_0
        - setuptools 40.6.3 py27_0
        - sqlite 3.26.0 h7b6447c_0
        - swig 3.0.12 h38cdd7d_3
        - tk 8.6.8 hbc83047_0
        - wheel 0.32.3 py27_0
        - xz 5.2.4 h14c3975_4
        - zlib 1.2.11 h7b6447c_3
    run:
        - bzip2 >=1.0.6,<2.0a0
        - cairo >=1.14.12,<2.0a0
        - libgcc
        - libxml2 >=2.9.8,<2.10.0a0
        - python >=2.7,<2.8.0a0
        - zlib >=1.2.11,<1.3.0a0
test:
    commands:
        - obabel --help
        - obabel -:c1ccccc1 --gen3d -omol2
        - obabel -:c1ccccc1 --gen3d -oinchi
        - obabel -:c1ccccc1 -opng -O img.png
    imports:
        - openbabel
        - pybel
about:
    home: http://www.openbabel.org/
    license: GPLv2
    summary: A chemical toolbox designed to speak the many languages of chemical data
extra:
    copy_test_source_files: true
    final: true

Is there a reason why openbabel needs libgcc to run as opposed to libgcc-ng even though it is built with libgcc-ng? If not this is probably not something worth immediately rebuilding your packages for (our issue ended up not being directly related to this anyways), but it might be worth updating the recipe so that future builds only depend on libgcc-ng. I am not a conda expert at all but based on the feedback we got from conda it appears that they want to move away from libgcc in favor of libgcc-ng.

[mwojcikowski]

Openbabel indirectly depends on libgcc-ng on build. The dependency in runtime is explicit. I will test the libgcc-ng and try to make that switch.

[amarkpayne]

Thanks @mwojcikowski for taking a look at this and making the fix!