Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Brian Ward
    @WardBrian
    Would the process to make a newer version look a lot like adding a fresh package?
    Philippe Blain
    @phil-blain
    There is some mentions of the mingw situation in issue #1044
    Brian Ward
    @WardBrian
    I've not tried clang, it's what we use on MacOS so it is possible it will work? We cannot use msvc for various reasons (inherited from before my time)
    Isuru Fernando
    @isuruf
    No. It's a lot of work to add a new gcc package as that requires rebuilding all downstream packages
    Brian Ward
    @WardBrian
    Thanks @phil-blain, that's useful. It seems that any discussion there stalled a couple years ago however.
    Brian Ward
    @WardBrian
    @isuruf I haven't given up entirely, but initial efforts suggest using clang targetting msvc is not going to work for this project, so I'm back to wondering about the feasibility of repackaging newer versions of gcc from msys (even if the pinned version stays at 5.3?)
    Isuru Fernando
    @isuruf
    @WardBrian, it's a quite involved process. I'll try to write down the list of things to do and also some design decisions we'll have to take
    Btw, what's the issue with using clang targetting msvc? Maybe I can help
    Keith Kraus
    @kkraus14
    Anyone know an easy way to get my own RPATH entry in front of the conda environment when building / linking using the conda-forge compilers? I currently have code that sets things like a BUILD_RPATH and INSTALL_RPATH target property in CMake, but it looks like the LDFLAGS setting is putting the conda environment before it in the produced library.
    Isuru Fernando
    @isuruf
    This is not for creating a conda package right?
    Keith Kraus
    @kkraus14
    No it is not, for local development testing stuff
    Keith Kraus
    @kkraus14
    i.e. building some local gtests and I want my BUILD_RPATH to first point to the directory where my library is being built instead of the $CONDA_PREFIX/lib. Right now seems like my choices are use $LD_LIBRARY_PATH, or don't install the compilers package but just manually install gcc / gxx
    Isuru Fernando
    @isuruf
    maybe we should remove the rpath entry from https://github.com/conda-forge/ctng-compiler-activation-feedstock/blob/main/recipe/activate-gcc.sh#L98
    Matthew R. Becker
    @beckermr
    n00b question: how does this relate to thr default spec changes rhat were put in?
    Keith Kraus
    @kkraus14
    Do we still care about cos6 environments? I just ran into an issue in this PR conda-forge/nvcc-feedstock#80 where it looks like the latest gcc / gxx 7.5 builds were built on cos7 which makes them require glibc 2.14 and breaks cos6 compatibility.
    Matthew R. Becker
    @beckermr
    Those builds should not require cos7 so this is a bug.
    I have seen this when building numba too.
    I think the simplest fix is to override the docker container.
    We settled on building with a cos6 ABI but using the cos7 container.
    Some builds/packages get confused.
    Keith Kraus
    @kkraus14
    Where is the cos6 ABI set?
    Matthew R. Becker
    @beckermr
    the compilers use a cos6 sysroot package by default
    the ABI for the compilers themselves is another thing
    IDK how that works
    or really most of this! ;)
    Keith Kraus
    @kkraus14
    Looks like gcc 7.5.0 got removed from the build matrix before the glibc sysroot versioning change was made
    Keith Kraus
    @kkraus14
    @xhochy I think you were working on this and looks like you made the latest changes and have a gcc-7.5.0 branch on ctng-compilers. Any insights here?
    Uwe L. Korn
    @xhochy
    All I did was backport a patch from Debian to the feedstock. We do some separation based on the GCC build numbers. I don't know what exactly but you have to continue on that branch if you want to have newer gcc-7.5.0 builds.
    Matthew R. Becker
    @beckermr
    So when we made the sysroot swappable, we had to define a boundry for compilers that were or were not capable of doing that.
    gcc 7.5.0 is right before that
    Keith Kraus
    @kkraus14
    So to be clear I don't know exactly what's going on, but in a PR for something that uses cos6 images with gcc 7.5 I got:
    2022-04-25T15:23:58.2451571Z /home/conda/feedstock_root/build_artifacts/nvcc_1650900156699/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_p/bin/x86_64-conda-linux-gnu-c++: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /home/conda/feedstock_root/build_artifacts/nvcc_1650900156699/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_p/bin/x86_64-conda-linux-gnu-c++)
    Matthew R. Becker
    @beckermr
    i'd open an issue with more details
    hard to diagnose here
    maybe you have already and I missed it
    Keith Kraus
    @kkraus14
    Yea, discussion happening on this PR: conda-forge/nvcc-feedstock#80
    Matthew R. Becker
    @beckermr
    if so sorry!
    ahhh thank you!
    Keith Kraus
    @kkraus14
    I'll open an issue on the ctng-compilers feedstock though for more targeted discussion
    Matthew R. Becker
    @beckermr
    right
    we may want to set the docker image to the cos6 one for the gcc 7 builds
    to avoid w/e this is
    Keith Kraus
    @kkraus14
    Looks like it got a memcpy symbol from GLIBC 2.14 somehow
    Issue opened here: conda-forge/ctng-compilers-feedstock#97
    Keith Kraus
    @kkraus14
    FYI -- I opened a PR here marking the builds as broken: conda-forge/admin-requests#431. Not sure if we'd prefer a repodata patch, or if the answer is that we no longer support cos6 environments and that it's fine to use the glibc 2.14 symbols now.
    Isuru Fernando
    @isuruf
    ctng builds (i.e. <=7.5) is using the system gcc from the docker image, so you have to use the cos6 docker image
    3 replies
    jakirkham
    @jakirkham

    How should we be handling this ( https://github.com/conda-forge/xgboost-feedstock/pull/88#issuecomment-1119533913 )?

    cc @xhochy (for vis)

    1 reply
    Keith Kraus
    @kkraus14
    Is there a reason that there isn't run_exports for libgcc-ng and libstdcxx-ng where if someone gets 12.x in their host environment they'd need >=12.x in their run environment? It looks like right now only the compilers themselves have run_exports and they export greater than or equal to the compiler version. Wouldn't the linker potentially find newer GLIBC / GLIBCXX versioned symbols effectively breaking the compatibility with anything less then >=12.x?
    31 replies
    Chris Burr
    @chrisburr
    Debugging in the gdal issue mentioned in the main channel I've come to the same conclusion
    Matthew R. Becker
    @beckermr
    @/all see this PR: conda-forge/ctng-compiler-activation-feedstock#75
    proposal is to pin to 12x or greater