Skip to content

rustc: -L also indicates the location of native libraries #2197

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

Closed
wants to merge 1 commit into from

Conversation

brson
Copy link
Contributor

@brson brson commented Apr 14, 2012

-L currently specifies paths to search for Rust crates

Building crates that use native libraries is difficult. When the
library is located somewhere unexpected there is no way
to tell rustc additional paths to look in.

If libclang is located at . then rustc is not going to
know that and linking will fail.

To get around that I often end up inserting

#[link_args = "-L."] native mod m { }

into other crates to get them to build.

Now you just rustc -L . and it builds.

This doesn't do any rpathing so it's still up to somebody else
to put the library somewhere it will be found or use LD_LIBRARY_PATH

This feature comes with a single, XFAILed test, because I could
not think of a way to test it. Odd.

-L currently specifies paths to search for Rust crates

Building crates that use native libraries is difficult. When the
library is located somewhere unexpected there is no way
to tell rustc additional paths to look in.

If libclang is located at `.` then rustc is not going to
know that and linking will fail.

To get around that I often end up inserting

    #[link_args = "-L."] native mod m { }

into other crates to get them to build.

Now you just `rustc -L .` and it builds.

This doesn't do any rpathing so it's still up to somebody else
to put the library somewhere it will be found or use LD_LIBRARY_PATH

This feature comes with a single, XFAILed test, because I could
not think of a way to test it. Odd.
@brson brson mentioned this pull request Apr 16, 2012
@brson
Copy link
Contributor Author

brson commented Apr 16, 2012

Merged. Thanks!

@brson brson closed this Apr 16, 2012
bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 22, 2022
make Miri's scheduler proper round-robin

When thread N blocks or yields, we activate thread N+1 next, rather than always activating thread 0. This should guarantee that as long as all threads regularly yield, each thread eventually takes a step again.

Fixes the "multiple loops that yield playing ping-pong" part of rust-lang/miri#1388.
`@cbeuw` I hope this doesn't screw up the scheduler-dependent tests you are adding in your PR.
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.

1 participant