Drop -ng suffix for runtime libraries, but keep compat-wrappers

[h-vetinari]

This is a follow-up to a long-standing transition that has been in stasis. As noted in #134

Longterm it would be nice to get rid of the runtime suffix everywhere; the last respective linux builds are:

• libgcc: 5.2.0 (Aug. 2018)
• libgfortran: 3.0.0 (Aug. 2018)
• libstdcxx: never published for linux

This should be fixable with some simple run-constraints (plus keeping -ng as a wrapper until we've switched over the strong run-exports for maybe a few years).

The windows variants never introduced the suffix in the first place; drop it for the others too, but keep compatibility wrappers for a good while.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

[h-vetinari]

@conda-forge-admin, please rerender

[h-vetinari]

Draft due to rerendering errors: conda-forge/conda-smithy#2012

[h-vetinari]

This is ready now @conda-forge/ctng-compilers; I recommend to review commit by commit, the diff makes more sense that way.

[h-vetinari]

For some reason, ee7613f had fallen out of the last rebase - sorry.

[isuruf]

This would break all downstream recipes with error_overlinking: true. Probably needs a run_exports section in libgcc-ng to fix that.

[isuruf]

We also need to run a mini-migrator that changes

ignore_run_exports:
  - libstdcxx-ng

to

ignore_run_exports_from:
  - {{ compiler('cxx') }}

[h-vetinari]

This would break all downstream recipes with error_overlinking: true. Probably needs a run_exports section in libgcc-ng to fix that.

My plan was to update the compiler activation as well of course. I don't think many recipes depend directly on libgcc-ng or libgfortran...? There's 5 feedstocks that have an explicit build or host dep on the -ng libraries (plus a handful that have a run-dep that should instead rely on the run-export). That said, I don't mind putting a run-export on libgcc-ng as an additional safety.

We also need to run a mini-migrator [...]

Looking around, this only affects about 20 recipes. I think it would be less effort to fix them manually (I can do that) than write a migrator for all corner cases (and attach it to which migration...?).

[h-vetinari]

OK, I've opened PRs for every feedstock that uses one of the -ng libraries somewhere in meta.yaml, with the following exceptions:

• if -ng libraries are only used in run; those can/will be handled with a linter rule
• dead/archived feedstocks
  • https://github.com/conda-forge/go-gvisor-feedstock
  • https://github.com/conda-forge/gwframes-feedstock
  • https://github.com/conda-forge/heavydb-ext-feedstock
  • https://github.com/conda-forge/omniscidb-feedstock
  • https://github.com/conda-forge/tensorflow-estimator-feedstock

This leaves the following to-dos (not counting above-linked PRs that are green already):

• cuda-nvcc-impl (should probably remove -ng suffix once we merge this PR)
• deno (same)
• gds-base 3.0.1 gds-feedstock#20 (broken on osx)
• gst-python v1.24.6 gst-python-feedstock#58 (broken on windows)
• improve ignore_run_exports, don't refer to -ng packages tensorflow-hub-feedstock#23 (broken)
• uutils-coreutils v0.0.27; handle libstdcxx without -ng uutils-coreutils-feedstock#9 (broken on windows)

[h-vetinari]

@isuruf, with the exception of ncurses & tzdata awaiting merge (and cuda-nvcc-impl/deno which need this PR), all buildable feedstocks (i.e non-failing CI) are now free of -ng packages in build/host/ignore. For run-deps I'm going to add a lint-check, but this needs this PR first. Could you PTAL?

[h-vetinari]

All good now?

[isuruf]

Thanks

[SylvainCorlay]

Hey @h-vetinari this seems to be causing clobbering between libgcc and libgcc-ng. Is this expected ?

[SylvainCorlay]

If we have an environment with just libgcc-ng 14.1.0 and no libgcc, when a user modifies the environment it results in libgcc 14.1.0 being added, with the warning:

Warning  libmamba [libgcc-14.1.0-h77fa898_1] The following files were already present in the environment:
    - lib/libatomic.so
    - lib/libatomic.so.1
    - lib/libatomic.so.1.2.0
    - lib/libgcc_s.so
    - lib/libgcc_s.so.1
    - lib/libitm.so
    - lib/libitm.so.1
    - lib/libitm.so.1.0.0
    - lib/libquadmath.so
    - lib/libquadmath.so.0
    - lib/libquadmath.so.0.0.0
    - share/info/libgomp.info
    - share/info/libquadmath.info
    - share/licenses/gcc-libs/RUNTIME.LIBRARY.EXCEPTION
and then this results in all of those "colliding" files not being in the environment anymore!

[h-vetinari]

Hey @h-vetinari this seems to be causing clobbering between libgcc and libgcc-ng. Is this expected ?

Sorry about that. This shouldn't be possible based on the very tight run-constraints that we've added. Could you please open an issue with more details?