Skip to content
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

rustc doesn't handle relative symlinks to libraries #13890

Closed
yuriks opened this issue May 2, 2014 · 4 comments · Fixed by #13903
Closed

rustc doesn't handle relative symlinks to libraries #13890

yuriks opened this issue May 2, 2014 · 4 comments · Fixed by #13903

Comments

@yuriks
Copy link
Contributor

yuriks commented May 2, 2014

When rustc searches for libraries and encounters a symlink, instead of directly opening the link, it uses readlink and then uses the resulting path relative to cwd instead of relative to the link, causing it to fail to find the file.

The problem can be seen in the following excerpt from the output of strace on rustc:

...
[pid  2359] openat(AT_FDCWD, "/home/yuriks/projects/distrocast/.rust/lib/x86_64-unknown-linux-gnu", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
[pid  2359] getdents(3, /* 3 entries */, 32768) = 104
[pid  2359] getdents(3, /* 0 entries */, 32768) = 0
[pid  2359] close(3)                    = 0
[pid  2359] readlink("/home/yuriks/projects/distrocast/.rust/lib/x86_64-unknown-linux-gnu/librust-crypto-c53dba27-0.1.rlib", "../../../rust-crypto/librust-cry"..., 4096) = 53
[pid  2359] stat("../../../rust-crypto/librust-crypto-c53dba27-0.1.rlib", 0x7fd1ba017980) = -1 ENOENT (No such file or directory)
[pid  2359] write(2, "client.rs:5:1: 5:37 error: can't"..., 57client.rs:5:1: 5:37 error: can't find crate for `crypto`
...
@alexcrichton
Copy link
Member

I haven't been able to reproduce this functionality, can you give an example test case/scenario when this arises?

@yuriks
Copy link
Contributor Author

yuriks commented May 2, 2014

In my case I have the following directory structure:

distrocast
├── client.rs
├── rust-crypto
│   ├── librust-crypto-c53dba27-0.1.rlib
│   └── ...
├── .rust
│   └── lib
│       └── x86_64-unknown-linux-gnu
│           └── librust-crypto-c53dba27-0.1.rlib -> ../../../rust-crypto/librust-crypto-c53dba27-0.1.rlib
└── ...

And I run rustc client.rs (where client.rs does extern crate crypto = "rust-crypto") from the distrocast directory. rustc finds the .rust directory and the symlink, but interprets it incorrectly. If I change the symlink to be absolute it works.

@alexcrichton
Copy link
Member

I have been able to reproduce, thanks!

alexcrichton added a commit to alexcrichton/rust that referenced this issue May 2, 2014
The logic of the custom realpath function in metadata::loader was incorrect, but
the logic in util::fs was correct.

Closes rust-lang#13890
bors added a commit that referenced this issue May 3, 2014
The logic of the custom realpath function in metadata::loader was incorrect, but
the logic in util::fs was correct.

Closes #13890
@yuriks
Copy link
Contributor Author

yuriks commented May 3, 2014

Thanks!

arcnmx pushed a commit to arcnmx/rust that referenced this issue Jan 9, 2023
…Veykril

fix: unescape inline module names in module resolution

Fixes rust-lang#13884
jieyouxu added a commit to jieyouxu/rust that referenced this issue Dec 27, 2024
- Document test intent, backlink to rust-lang#13890 and fix PR rust-lang#13903.
- Fix the test logic: the `Makefile` version seems to not actually be
  exercising the "library search traverses symlink" logic, because the
  actual symlinked-to-library is present under the directory tree when
  `bar.rs` is compiled, because the `$(RUSTC)` invocation has an
  implicit `-L $(TMPDIR)`. The symlink itself was actually broken, i.e.
  it should've been `ln -nsf $(TMPDIR)/outdir/$(NAME) $(TMPDIR)` but it
  used `ln -nsf outdir/$(NAME) $(TMPDIR)`.
jieyouxu added a commit to jieyouxu/rust that referenced this issue Dec 27, 2024
- Document test intent, backlink to rust-lang#13890 and fix PR rust-lang#13903.
- Fix the test logic: the `Makefile` version seems to not actually be
  exercising the "library search traverses symlink" logic, because the
  actual symlinked-to-library is present under the directory tree when
  `bar.rs` is compiled, because the `$(RUSTC)` invocation has an
  implicit `-L $(TMPDIR)`. The symlink itself was actually broken, i.e.
  it should've been `ln -nsf $(TMPDIR)/outdir/$(NAME) $(TMPDIR)` but it
  used `ln -nsf outdir/$(NAME) $(TMPDIR)`.

Co-authored-by: Oneirical <manchot@videotron.ca>
jieyouxu added a commit to jieyouxu/rust that referenced this issue Dec 27, 2024
- Document test intent, backlink to rust-lang#13890 and fix PR rust-lang#13903.
- Fix the test logic: the `Makefile` version seems to not actually be
  exercising the "library search traverses symlink" logic, because the
  actual symlinked-to-library is present under the directory tree when
  `bar.rs` is compiled, because the `$(RUSTC)` invocation has an
  implicit `-L $(TMPDIR)`. The symlink itself was actually broken, i.e.
  it should've been `ln -nsf $(TMPDIR)/outdir/$(NAME) $(TMPDIR)` but it
  used `ln -nsf outdir/$(NAME) $(TMPDIR)`.

Co-authored-by: Oneirical <manchot@videotron.ca>
jieyouxu added a commit to jieyouxu/rust that referenced this issue Dec 27, 2024
- Document test intent, backlink to rust-lang#13890 and fix PR rust-lang#13903.
- Fix the test logic: the `Makefile` version seems to not actually be
  exercising the "library search traverses symlink" logic, because the
  actual symlinked-to-library is present under the directory tree when
  `bar.rs` is compiled, because the `$(RUSTC)` invocation has an
  implicit `-L $(TMPDIR)`. The symlink itself was actually broken, i.e.
  it should've been `ln -nsf $(TMPDIR)/outdir/$(NAME) $(TMPDIR)` but it
  used `ln -nsf outdir/$(NAME) $(TMPDIR)`.

Co-authored-by: Oneirical <manchot@videotron.ca>
jieyouxu added a commit to jieyouxu/rust that referenced this issue Dec 27, 2024
- Document test intent, backlink to rust-lang#13890 and fix PR rust-lang#13903.
- Fix the test logic: the `Makefile` version seems to not actually be
  exercising the "library search traverses symlink" logic, because the
  actual symlinked-to-library is present under the directory tree when
  `bar.rs` is compiled, because the `$(RUSTC)` invocation has an
  implicit `-L $(TMPDIR)`. The symlink itself was actually broken, i.e.
  it should've been `ln -nsf $(TMPDIR)/outdir/$(NAME) $(TMPDIR)` but it
  used `ln -nsf outdir/$(NAME) $(TMPDIR)`.

Co-authored-by: Oneirical <manchot@videotron.ca>
jieyouxu added a commit to jieyouxu/rust that referenced this issue Dec 28, 2024
- Document test intent, backlink to rust-lang#13890 and fix PR rust-lang#13903.
- Fix the test logic: the `Makefile` version seems to not actually be
  exercising the "library search traverses symlink" logic, because the
  actual symlinked-to-library is present under the directory tree when
  `bar.rs` is compiled, because the `$(RUSTC)` invocation has an
  implicit `-L $(TMPDIR)`. The symlink itself was actually broken, i.e.
  it should've been `ln -nsf $(TMPDIR)/outdir/$(NAME) $(TMPDIR)` but it
  used `ln -nsf outdir/$(NAME) $(TMPDIR)`.

Co-authored-by: Oneirical <manchot@videotron.ca>
Zalathar added a commit to Zalathar/rust that referenced this issue Dec 28, 2024
…inks, r=lqd

Migrate `libs-through-symlink` to rmake.rs

Part of rust-lang#121876.

This PR migrates `tests/run-make/libs-through-symlink/` to use rmake.rs.

- Regression test for rust-lang#13890.
- Original fix PR is rust-lang#13903.
- Document test intent, backlink to rust-lang#13890 and fix PR rust-lang#13903.
- Fix the test logic: the `Makefile` version seems to not actually be exercising the "library search traverses symlink" logic, because the actual symlinked-to-library is present under the `$(TMPDIR)` directory tree when `bar.rs` is compiled, because the `$(RUSTC)` invocation has an implicit `-L $(TMPDIR)`. The symlink itself was actually broken, i.e. it should've been `ln -nsf $(TMPDIR)/outdir/$(NAME) $(TMPDIR)` but it used `ln -nsf outdir/$(NAME) $(TMPDIR)`. The rmake.rs version now explicitly separates the two directory trees and sets the CWD of the `bar.rs` rustc invocation so that the actual library is *not* present under its CWD tree.

I.e. it is now

```
$test_output/           # rustc foo.rs -o actual_lib_dir/libfoo.rlib
    actual_lib_dir/
        libfoo.rlib
    symlink_lib_dir/    # CWD set; rustc -L . bar.rs
        libfoo.rlib --> $test_output/actual_lib_dir/libfoo.rlib
```

Partially supersedes rust-lang#129011.
This PR is co-authored with `@Oneirical.`

r? compiler
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Dec 28, 2024
Rollup merge of rust-lang#134829 - jieyouxu:migrate-libs-through-symlinks, r=lqd

Migrate `libs-through-symlink` to rmake.rs

Part of rust-lang#121876.

This PR migrates `tests/run-make/libs-through-symlink/` to use rmake.rs.

- Regression test for rust-lang#13890.
- Original fix PR is rust-lang#13903.
- Document test intent, backlink to rust-lang#13890 and fix PR rust-lang#13903.
- Fix the test logic: the `Makefile` version seems to not actually be exercising the "library search traverses symlink" logic, because the actual symlinked-to-library is present under the `$(TMPDIR)` directory tree when `bar.rs` is compiled, because the `$(RUSTC)` invocation has an implicit `-L $(TMPDIR)`. The symlink itself was actually broken, i.e. it should've been `ln -nsf $(TMPDIR)/outdir/$(NAME) $(TMPDIR)` but it used `ln -nsf outdir/$(NAME) $(TMPDIR)`. The rmake.rs version now explicitly separates the two directory trees and sets the CWD of the `bar.rs` rustc invocation so that the actual library is *not* present under its CWD tree.

I.e. it is now

```
$test_output/           # rustc foo.rs -o actual_lib_dir/libfoo.rlib
    actual_lib_dir/
        libfoo.rlib
    symlink_lib_dir/    # CWD set; rustc -L . bar.rs
        libfoo.rlib --> $test_output/actual_lib_dir/libfoo.rlib
```

Partially supersedes rust-lang#129011.
This PR is co-authored with `@Oneirical.`

r? compiler
poliorcetics pushed a commit to poliorcetics/rust that referenced this issue Dec 28, 2024
- Document test intent, backlink to rust-lang#13890 and fix PR rust-lang#13903.
- Fix the test logic: the `Makefile` version seems to not actually be
  exercising the "library search traverses symlink" logic, because the
  actual symlinked-to-library is present under the directory tree when
  `bar.rs` is compiled, because the `$(RUSTC)` invocation has an
  implicit `-L $(TMPDIR)`. The symlink itself was actually broken, i.e.
  it should've been `ln -nsf $(TMPDIR)/outdir/$(NAME) $(TMPDIR)` but it
  used `ln -nsf outdir/$(NAME) $(TMPDIR)`.

Co-authored-by: Oneirical <manchot@videotron.ca>
poliorcetics pushed a commit to poliorcetics/rust that referenced this issue Dec 28, 2024
…inks, r=lqd

Migrate `libs-through-symlink` to rmake.rs

Part of rust-lang#121876.

This PR migrates `tests/run-make/libs-through-symlink/` to use rmake.rs.

- Regression test for rust-lang#13890.
- Original fix PR is rust-lang#13903.
- Document test intent, backlink to rust-lang#13890 and fix PR rust-lang#13903.
- Fix the test logic: the `Makefile` version seems to not actually be exercising the "library search traverses symlink" logic, because the actual symlinked-to-library is present under the `$(TMPDIR)` directory tree when `bar.rs` is compiled, because the `$(RUSTC)` invocation has an implicit `-L $(TMPDIR)`. The symlink itself was actually broken, i.e. it should've been `ln -nsf $(TMPDIR)/outdir/$(NAME) $(TMPDIR)` but it used `ln -nsf outdir/$(NAME) $(TMPDIR)`. The rmake.rs version now explicitly separates the two directory trees and sets the CWD of the `bar.rs` rustc invocation so that the actual library is *not* present under its CWD tree.

I.e. it is now

```
$test_output/           # rustc foo.rs -o actual_lib_dir/libfoo.rlib
    actual_lib_dir/
        libfoo.rlib
    symlink_lib_dir/    # CWD set; rustc -L . bar.rs
        libfoo.rlib --> $test_output/actual_lib_dir/libfoo.rlib
```

Partially supersedes rust-lang#129011.
This PR is co-authored with `@Oneirical.`

r? compiler
flip1995 added a commit to flip1995/rust that referenced this issue Jan 9, 2025
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 a pull request may close this issue.

2 participants