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

rustup.sh is being confused by dash into 32 bit install on 64 bit linux host #17850

Closed
farcaller opened this issue Oct 7, 2014 · 5 comments
Closed

Comments

@farcaller
Copy link
Contributor

Specifically,

# Detect 64 bit linux systems with 32 bit userland and force 32 bit compilation
if [ $CFG_OSTYPE = unknown-linux-gnu -a $CFG_CPUTYPE = x86_64 ]
then
    file -L "$SHELL" | grep -q "x86[_-]64"

this check fails with 1, as /bin/sh on default ubuntu 14.04 has an empty $SHELL.

A trivial fix is to use /bin/bash in shebang and update the rustup docs as appropriate.

@brson
Copy link
Contributor

brson commented Oct 7, 2014

This exact line appears on Rust's configure script, which correctly does a 64-bit build on 64-bit ubuntu. Is there something else going on?

@brson brson changed the title Rust installer is being confused by dash into 32 bit install on 64 bit linux host rustup.sh is being confused by dash into 32 bit install on 64 bit linux host Oct 7, 2014
@brson
Copy link
Contributor

brson commented Oct 7, 2014

rustup.sh correctly installs x86_64 rustc on my install of 14.04

@brson
Copy link
Contributor

brson commented Oct 7, 2014

Perhaps under normal operation most people are doing this in an interactive (bash) shell, so $SHELL happens to be set.

@farcaller
Copy link
Contributor Author

Can't reliably reproduce outside of docker's ubuntu:14.04, closing.

@sourcefrog
Copy link
Contributor

I'm hitting something similar, though not quite the same.

Running current rustupup on Debian Jessy from inside of zsh:

+ local _ostype=unknown-linux-gnu
+ local _cputype=x86_64
+ [ unknown-linux-gnu = unknown-linux-gnu -a x86_64 = x86_64 ]
+ local _bin_to_probe=zsh
+ [ -z zsh -a -e /usr/bin/env ]
+ [ -n zsh ]
+ grep -q x86[_-]64
+ file -L zsh
+ [ 1 != 0 ]
+ local _cputype=i686
+ local _arch=i686-unknown-linux-gnu

It seems the problem is $SHELL is just plain zsh with no path, so running file -L $shell fails.

lnicola pushed a commit to lnicola/rust that referenced this issue Aug 13, 2024
internal: Reply to requests with defaults when vfs is still loading

There is no reason for us to hit the database with queries when we certainly haven't reached a stable state yet. Instead we just reply with default request results until we are in a state where we can do meaningful work. This should save us from wasting resources while starting up at worst, and at best save us from creating query and interning entries that are non-meaningful which ultimately just end up wasting memory.
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

No branches or pull requests

3 participants