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.

Sign up for GitHub

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

Jump to bottom

can't bootstrap compiler from the rust-src component because of file permissions #36488

Closed
japaric opened this issue Sep 15, 2016 · 10 comments · Fixed by rust-lang/rustup#1141
Closed

can't bootstrap compiler from the rust-src component because of file permissions #36488

japaric opened this issue Sep 15, 2016 · 10 comments · Fixed by rust-lang/rustup#1141
Labels
E-help-wanted Call for participation: Help is requested to fix this issue.

Comments

@japaric
Copy link
Member

japaric commented Sep 15, 2016 •
edited
Loading

All the files, even the scripts (*.sh), have their permissions set to 644.

Bootstrapping fails while executing alloc_jemalloc build script with the following error message:

$ chmod +x $(rustc --print sysroot)/lib/rustlib/src/rust/configure
$ $(rustc --print sysroot)/lib/rustlib/src/rust/configure --enable-rustbuild --target=arm-unknown-linux-gnueabi
$ make
<snip>
--- stderr
./config.status: line 1197: /home/japaric/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/liballoc_jemalloc/../jemalloc/include/jemalloc/internal/private_namespace.sh: Permission denied
./config.status: line 1201: /home/japaric/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/liballoc_jemalloc/../jemalloc/include/jemalloc/internal/private_unnamespace.sh: Permission denied
./config.status: line 1221: /home/japaric/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/liballoc_jemalloc/../jemalloc/include/jemalloc/internal/public_namespace.sh: Permission denied
./config.status: line 1225: /home/japaric/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/liballoc_jemalloc/../jemalloc/include/jemalloc/internal/public_unnamespace.sh: Permission denied
./config.status: line 1237: /home/japaric/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/liballoc_jemalloc/../jemalloc/include/jemalloc/jemalloc_rename.sh: Permission denied
./config.status: line 1241: /home/japaric/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/liballoc_jemalloc/../jemalloc/include/jemalloc/jemalloc_mangle.sh: Permission denied
./config.status: line 1245: /home/japaric/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/liballoc_jemalloc/../jemalloc/include/jemalloc/jemalloc_mangle.sh: Permission denied
./config.status: line 1249: /home/japaric/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/liballoc_jemalloc/../jemalloc/include/jemalloc/jemalloc.sh: Permission denied
<snip>

cc @brson @Diggsey

Meta

$ rustc -V
rustc 1.13.0-nightly (5531c314a 2016-09-12)
@japaric japaric mentioned this issue Sep 15, 2016
Open
@japaric
Copy link
Member Author

japaric commented Sep 15, 2016

You can't compile std with jemalloc enabled from the rust-src component either. The build fails with the same error message I posted above.

@brson brson added the A-build label Sep 20, 2016
@brson
Copy link
Contributor

brson commented Sep 20, 2016

Could be related to #25479.

rustup has code to explicitly fix permissions in the 'bin' directory, maybe others. Probably best though to figure out how to make this tarball carry the right permissions with it.

@bstrie bstrie mentioned this issue Sep 21, 2016
Closed
6 tasks
@japaric
Copy link
Member Author

japaric commented Dec 27, 2016

@alexcrichton @brson Is this now easier to fix now that we are using Travis for testing/packaging? (This is blocking Xargo from being able to (cross) compile std with the "jemalloc" feature enabled.)

@alexcrichton
Copy link
Member

Source tarballs are created from rustbuild now, but we're not using Travis for packaging. I don't think this bug fix should be any easier than before, though.

@brson brson added the E-help-wanted Call for participation: Help is requested to fix this issue. label Dec 28, 2016
@brson
Copy link
Contributor

brson commented Dec 28, 2016

This is going to involve hacking on both rustbuild and rustup. Ideally rustbuild will produce tarballs with the correct permissions and rustup will use those permissions when extracting the tarball.

japaric pushed a commit to japaric/rust that referenced this issue Jan 4, 2017
move the alloc_jemalloc allocator out of tree, default to alloc_system
6208fea 
See rust-lang#36963 for rationale

closes rust-lang#36963
fixes rust-lang#36488 (indirectly)
closes rust-lang#37975
@RalfJung
Copy link
Member

Couldn't the install.sh script fix permissions? I haven't figured out yet what is putting that script into the tarball, but it seems like a natural place.

@RalfJung
Copy link
Member

RalfJung commented May 25, 2017 •
edited
Loading

I suspect if we used 3be02fc on Linux, that would also preserve permissions. (Will test soon.)

@alexcrichton you went from hard-links to copies because of trouble on Windows. Would it be possible to still use hard-links on non-Windows platforms?

@RalfJung
Copy link
Member

RalfJung commented May 25, 2017 •
edited
Loading

Never mind, the permission copying seems to actually work. The tarball does contain the right permissions when I create it locally. If this is still a problem (which we can only really test once #41952 is fixed), the bug is somewhere in rustup.

@RalfJung
Copy link
Member

The tarball available at https://static.rust-lang.org/dist/rust-src-nightly.tar.xz has the right permissions (and same for the .gz). When I run install.sh to put things somewhere, the permissions are gone. I am not sure if rustup runs this script, but if to does, that's where the permissions get lost.

This was referenced May 30, 2017
Closed
Merged
bors added a commit to rust-lang/rustup that referenced this issue Jun 7, 2017
@bors
Auto merge of #1141 - RalfJung:permissions, r=Diggsey
6cac413 
set_file_perms: if the file is already executable, keep it executable

This was the smallest change I could come up with to fix <rust-lang/rust#36488>: Maintain the X bit when fixing up permissions.

However, the code is still somewhat inconsistent in that it does apply different rules when applied to a file vs. when applied to a directory -- the code recursively walking the directory still removes the X bits from all files, just like it previously ignored the "bin" directory. If you want, I can refactor this some more to be consistent here.

Fixes: #1140
@RalfJung
Copy link
Member

RalfJung commented Jun 8, 2017

The install.sh is probably still wrong (I did not look closer into this), but when things are installed via rustup, the permissions should now be good. (Well, once the next rustup is released.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
E-help-wanted Call for participation: Help is requested to fix this issue.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

set_file_perms: if the file is already executable, keep it executable RalfJung/rustup.rs
4 participants
@alexcrichton @brson @RalfJung @japaric