Skip to content

chore(example): add nvvm library path to LD_LIBRARY_PATH and add back the add example in CI #190

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

Merged
merged 1 commit into from
Apr 5, 2025

Conversation

adamcavendish
Copy link
Contributor

@adamcavendish adamcavendish commented Apr 5, 2025

When linking libnvvm.so.4 into librustc_codegen_nvvm.so shared library via the cust_raw package, we specified the following parameters in the build.rs:

  • cargo::rustc-link-search=native=xxx
  • cargo::rustc-link-lib=dylib=nvvm

According to the Cargo documentation, the path we added to the rustc-link-search parameter is not further populated to the LD_LIBRARY_PATH for search by the transitive dependencies.

These paths are also added to the dynamic library search path environment variable if they are within the OUT_DIR.

The behavior is intended to be limited to the OUT_DIR so the libnvvm.so.4, which lives as a part of the CUDA SDK, is excluded. Therefore, we must add it to the LD_LIBRARY_PATH manually in our container build stage.


Since this PR changes the container, we would need to retrigger a container build manully before we can see correct CI results.

Resolves #129.

… the `add` example in CI

When linking `libnvvm.so.4` into `librustc_codegen_nvvm.so` shared
library via the `cust_raw` package, we specified the following
parameters in the `build.rs`:

- cargo::rustc-link-search=native=xxx
- cargo::rustc-link-lib=dylib=nvvm

According to the [Cargo documentation](https://doc.rust-lang.org/cargo/reference/build-scripts.html#rustc-link-search),
the path we added to the `rustc-link-search` parameter is not further
populated to the `LD_LIBRARY_PATH` for search by the transitive
dependencies.

> These paths are also added to the dynamic library search path
> environment variable if they are within the OUT_DIR.

The behavior is intended to be limited to the OUT_DIR so the
`libnvvm.so.4`, which lives as a part of the CUDA SDK, is excluded.
Therefore, we must add it to the LD_LIBRARY_PATH manually in our
container build stage.
@adamcavendish
Copy link
Contributor Author

@jorge-ortega In addition, should we make the develop container packages public in the rust-gpu org so other people can download and use them if they want?

@jorge-ortega
Copy link
Collaborator

jorge-ortega commented Apr 5, 2025

I think that might be a question for @LegNeato

Any idea why setting the LD_LIBRARY_PATH and running ldconfig in container didn't seem to have an effect?

@jorge-ortega jorge-ortega merged commit 032361a into Rust-GPU:main Apr 5, 2025
9 of 19 checks passed
@adamcavendish
Copy link
Contributor Author

I think that might be a question for @LegNeato

Any idea why setting the LD_LIBRARY_PATH and running ldconfig in container didn't seem to have an effect?

Linux env must be exported before it can take effect. I did test via export LD_LIBRARY_PATH in container and it did work. ld.conf has a cache as well so it must be updated to take effect too.

@jorge-ortega
Copy link
Collaborator

I thought I tried export LD_LIBRARY_PATH=... and echo "/libvvm/path" >> /etc/ld.so.conf && ldconfig with no effect. I'll just leave it as a me problem. Thanks for covering this!

@LegNeato
Copy link
Contributor

LegNeato commented Apr 7, 2025

@jorge-ortega In addition, should we make the develop container packages public in the rust-gpu org so other people can download and use them if they want?

Yeah, I think that would be better rather than people having to figure out how to cobble together a build env.

@LegNeato
Copy link
Contributor

LegNeato commented Apr 7, 2025

@jorge-ortega In addition, should we make the develop container packages public in the rust-gpu org so other people can download and use them if they want?

Yeah, I think that would be better rather than people having to figure out how to cobble together a build env.

@adamcavendish I flipped these settings, the container packages should now be public.

@adamcavendish adamcavendish deleted the chore/example-add branch April 7, 2025 16:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Running examples: Dependency problems, Linux target, errors in codegen_nvvm
3 participants