2.4.x kineto backport#372
Conversation
Explicitly pass `-Wl,-z,noexecstack` to the linker, to ensure that `libpytorch_cpu.so` is compiled without an executable stack. This is necessary because the raw assembly in oneDNN triggers: ``` $BUILD_PREFIX/bin/../lib/gcc/x86_64-conda-linux-gnu/13.3.0/../../../../x86_64-conda-linux-gnu/bin/ld: warning: ittptmark64.S.o: missing .note.GNU-stack section implies executable stack ``` ...and glibc 2.41 no longer permits loading libraries with executable stack. Fixes conda-forge#350
When building with `mkl`, upstream build system uses the same OpenMP implementation as `mkl`, which is `llvm-openmp`. In generic variant, the upstream can use either `llvm-openmp` or `libgomp`, but `llvm-openmp` takes precedence if it is installed. In CUDA-enabled builds, `llvm-openmp` was installed as an indirect dependency, and therefore the package used it rather than `libgomp`. For consistency and to avoid need to patch the build system, just depend on `llvm-openmp` for all Linux targets.
…nda-forge-pinning 2025.03.12.11.34.20
|
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 ( I do have some suggestions for making it better though... For recipe/meta.yaml:
This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/13941794401. Examine the logs at this URL for more detail. |
|
Confirmed that it's looking for the library via |
|
I think this should be good enough. To avoid further changes to the build system, I've went ahead and removed |
This is effectively a waste of our time. Other people's tech debt should not be your burden @mgorny Feel free to just "stop" on this front. |
|
Not a big deal — it's just a matter of copying the build |
|
To expedite the process, I am locally building 'linux_aarch64_c_compiler_version13' and will share the build log once it's complete. |
That's kind of you, but IMO not necessary. There's no big congestion on the server at the moment, so we can just let this build normally. |
Agreed. I was concerned that the build was being pushed back due to other PR. Uploading the log, just in case: |
Checklist
0(if the version changed)conda-smithy(Use the phrase@conda-forge-admin, please rerenderin a comment in this PR for automated rerendering)This is a fork of #341, on top of which I attempted enabling Kineto with CUPTI. Unfortunately, I couldn't get it to work — possibly it needs more CUDA lookup fixes from 2.5.x. But that's too much for my feverish brain right now. Still, opening a draft in case anyone wanted to try some more.