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

A portable Version of Rust Compiler for Windows #3459

Closed
JamilH opened this issue Sep 11, 2012 · 13 comments
Closed

A portable Version of Rust Compiler for Windows #3459

JamilH opened this issue Sep 11, 2012 · 13 comments
Labels
E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot. O-windows Operating system: Windows

Comments

@JamilH
Copy link

JamilH commented Sep 11, 2012

Hi,

It would be great if there was a portable version of rust compiler for windows. I am asking for this becuase the installer requires admin rights to be installed. Here in my Uni, I dont have those rights. Secondly even with admin right, I had issues on my PC because of missing DLLs, most probably becuase of MinW dependence. Maybe it is too much to ask but it would be a great time saver.

@graydon
Copy link
Contributor

graydon commented Sep 12, 2012

This is not possible in the near term since we rely on a system linker (and will, when we're using the visual studio linker, depend on theirs). In the longer term it might be possible when we have transitioned to a new compiler driver based on clang and possibly clang's linker (which the LLVM people are working on). Not sure what the time horizon on that is.

See also #1768, #2238

@ghost ghost assigned graydon Sep 12, 2012
@LeDominik
Copy link

After having quite some fun installing in Windows (already had 3 different MinGW Versions running) perhaps a possible solution would be to bundle the required MinGW stuff directly with rust binary installer, just like Haskell Platforms "batteries included". Combined with the new rust launcher #2238 (which could be the only thing on the windows path) this would be quite elegant...

Does that make sense or is it not feasible/helpful?

@thestinger
Copy link
Contributor

I don't think the well covered milestone makes sense for this. It's just about making installation more convenient.

@catamorphism
Copy link
Contributor

Visiting for bug triage. I don't think this is a blocker.

@vadimcn
Copy link
Contributor

vadimcn commented Dec 31, 2013

@brson, @alexcrichton: Maybe it's time to start invoking ld directly, at least on Windows?
Then we could bundle ld (and whatever else is needed from binutils) into the distribution package and stop depending on mingw environment.

cc #9367

@alexcrichton
Copy link
Member

I would be wary about bundling system linkers because I would imagine that they have a very large array of dependencies which are always a moving target to pin down. We could in theory bundle a linker for just windows, which initially seems odd to me, but considering how our entire windows situation is a little odd (having a system requirement unlike other OSes) maybe it isn't that odd after all.

I personally do not know how much we depend on mingw, but I would be very surprised if our actual only dependency was on the system linker. It seems like we could have easily leaked in dependencies over time without knowing it, and I'm also unsure of how you'd figure this out (other than just building with something other than mingw and seeing what happens).

I suppose all in all, I don't consider myself knowledgeable enough to say yea or nea as to whether we should be doing this at this time. Some things that I'd be worried about would be bundling too many dependencies (maybe ok for windows?) and preventing mingw dependencies from leaking into rust in the future. I'd also want to know that someone has a clear understanding of the path forward on windows away from mingw in the long term (I'm not sure if one exists today).

@vadimcn
Copy link
Contributor

vadimcn commented Jan 2, 2014

Yes, I am talking about Windows only. Unix-ish platforms can be expected to have binutils installed, but on WIndows it is traditional that compilers carry all the stuff they need.
Aside from the linker, there's of course a bunch of mingw libraries which implement various bits of C runtime. Starting with libgcc dll. Some of that can probably be eliminated, maybe even all of it.

But, in general, I assume we do want to have Rust distribution independent of MinGW?

@alexcrichton
Copy link
Member

We do eventually not want to require mingw, but I don't think the answer is to bundle all of mingw that we need. When we say we want to drop the mingw dep, at least in my mind, I think we're saying that we want to be buildable/bootstrappable in multiple environments other than MinGW. This means we should have logic/snapshots for msvc and friends, not just make it so our mingw version runs everywhere.

@retep998
Copy link
Member

retep998 commented Jun 8, 2014

Considering Clang can compile object files that are linkable using MSVC's linker, it is definitely within the realm of possibility for Rust to use MSVC's linker as well.

@thestinger
Copy link
Contributor

Rust can't ever redistribute the MSVC linker. It's a dead end.

@vadimcn
Copy link
Contributor

vadimcn commented Oct 3, 2014

This issue was fixed via #16957.

@alexcrichton
Copy link
Member

Awesome, thanks @vadimcn!

@octplane
Copy link
Contributor

Note that the installer still requires Admin. privileges to perform correctly, which makes this bug title still valid. Should the bug be renamed and another regarding the installer portability be opened?

bors pushed a commit to rust-lang-ci/rust that referenced this issue May 15, 2021
fix line numbering in missed spans and handle file_lines in edge cases
RalfJung pushed a commit to RalfJung/rust that referenced this issue Aug 10, 2024
Don't panic on `miri_print_borrow_state()` under `-Zmiri-disable-stacked-borrows`.

Fixes rust-lang#3459

Instead, just print "attempted to print borrow state, but no borrow state is being tracked" directly to ~~stdout~~ stderr and return successfully. Alternately, the diagnostic machinery could be used to print a structured error/warning.

 (Does not address the comment about nothing being printed for `miri_print_borrow_state` with `alloc_id = 0`)
RalfJung pushed a commit to RalfJung/rust that referenced this issue Aug 18, 2024
Don't panic on `miri_print_borrow_state()` under `-Zmiri-disable-stacked-borrows`.

Fixes rust-lang#3459

Instead, just print "attempted to print borrow state, but no borrow state is being tracked" directly to ~~stdout~~ stderr and return successfully. Alternately, the diagnostic machinery could be used to print a structured error/warning.

 (Does not address the comment about nothing being printed for `miri_print_borrow_state` with `alloc_id = 0`)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot. O-windows Operating system: Windows
Projects
None yet
Development

No branches or pull requests

9 participants