Mark libiconv 1.18=*_0 on Windows as broken due to a ABI break #1395
Conversation
| packages: | ||
| - win-64/libiconv-1.18-h135ad9c_0.conda |
There was a problem hiding this comment.
Can we mark all 1.18 builds as broken? I think this makes for a saner mental model of the ecosystem, aside from the fact that - a priori - those symbol removals might also be observable on unix under some circumstances?
There was a problem hiding this comment.
Can we mark all 1.18 builds as broken? I think this makes for a saner mental model of the ecosystem, aside from the fact that - a priori - those symbol removals might also be observable on unix under some circumstances?
I explicitly checked and there is no ABI regression on Linux, see conda-forge/libiconv-feedstock#48 (comment) , and I guess this is expected as I think the regression in our vendored CMakeLists.txt build system used on Windows. I did not marked as broken the *nix packages for 1.18 to avoid unwanted regression on packages that were already built again libiconv 1.18 and so a have a libiconv>=1.18 run constraint, but I get your point, so if you like I can add also all other 1.18 builds as broken.
The
libiconv1.18=*_0 build on Windows contains an ABI break that creates a problem in pkg-config and due to the use of pkg-config in a activation script, also in the installation of any package that depends (even transitively) ongdk-pixbuf. While we look into a fix, the best option is to mark the problematic package as broken.Related issues:
Checklist:
@conda-forge/core @conda-forge/libiconv @conda-forge/pkg-config @conda-forge/gdk-pixbuf @conda-forge/vtk @conda-forge/ffmpeg