-
-
Notifications
You must be signed in to change notification settings - Fork 51
2.4.x kineto backport #372
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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 |
recipe/patches/0008-Fix-CUPTI-lookup-to-include-target-directory.patch
Outdated
Show resolved
Hide resolved
h-vetinari
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you!
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.