Package mingw dependencies #16957

vadimcn · 2014-09-03T07:56:14Z

Package rustc's mingw dependencies into Windows installer to avoid requiring a separate mingw install.

alexcrichton · 2014-09-03T14:25:37Z

src/librustc/back/link.rs

@@ -1401,6 +1401,9 @@ fn link_args(cmd: &mut Command,
        cmd.arg("-nodefaultlibs");
    }

+    // Rust does its' own LTO
+    cmd.arg("-fno-lto").arg("-fno-use-linker-plugin");


Should we only run these on windows, or is this ok for all invocations of gcc?

LTO is off by default, so why does this need to be done?

@alexcrichton: I think this is ok for all platforms. That'll be one less gcc dependency to worry about if we ever switch to direct linker invocation.
@thestinger: gcc still tells linker to load its' lto plugin, I guess on the off chance that one of the libraries being linked was compiled with lto.

This breaks clang builds on OSX since clang doesn't know the argument: -fno-use-linker-plugin

You should be able to work around this with export ARCHFLAGS="-Wno-error=unused-command-line-argument-hard-error-in-future".

Not sure what to do about this in the long term.

Can clang vs gcc be detected before the option is passed? If it's known which one is being called, then this can be passed to gcc but not clang.

alexcrichton · 2014-09-03T14:26:54Z

This is amazing 👾!

brson · 2014-09-04T00:21:37Z

😻 @vadimcn, my hero.

brson · 2014-09-04T00:25:27Z

Am I correct in thinking that once we do the first snap after this that the toolchains on the bots will no longer be used, or is the snapshot bundling unchanged? It may make upgrading the toolchain very awkward if our snapshot is always overriding it.

vadimcn · 2014-09-04T00:43:36Z

😎

Am I correct in thinking that once we do the first snap after this that the toolchains on the bots will no longer be used, or is the snapshot bundling unchanged?

No, this does not affect snaps. Rust devs are still expected to install msys/mingw.

Stuff's only gonna get bundled into Windows installer. And even then, /bin is appended to the PATH, so any locally installed toolchain will take precedence.

vadimcn · 2014-09-04T01:28:00Z

r?

alexcrichton · 2014-09-04T03:52:22Z

src/librustc/metadata/filesearch.rs

+        };
+        debug!("new PATH: {}", String::from_utf8_lossy(new_path.as_slice()));
+        os::setenv("PATH", new_path);
+    }


Ah I just realize that this may yield surprising results when dealing with usage like rustdoc --test. In that case each test is compiled within the same process, which means that PATH will be appended to repeatedly (which may end badly).

Could this perhaps be wrapped in a Once or something similar?

Wouldn't that already be a problem with FileSearch::add_dylib_search_paths()?

Hm yes indeed. I suppose we can just wait and see what happens!

alexcrichton · 2014-09-04T04:27:03Z

r? @brson, this all looks good to me, but I want to be extra sure that we're covered on the licensing front

vadimcn · 2014-09-04T07:48:31Z

On second thought, maybe there already was a problem with over-long paths. Doctests do fail on Windows after all.

brson · 2014-09-05T02:46:31Z

@alexcrichton @vadimcn it does seem like we need to do some due diligence on the licensing here.

This directory is included with both the snaps and the installer. Right now it lists two specific files as being GPLv3+runtime exception.

Figuring out the exact license of all these bins will suck, but I'm guessing they are all either GPLv3 or GPLv3+runtime exception.

A number of these files have names that are frighteningly close to MS DLLs (libkernel32.a, libmsvcrt.a, libuser32.a). Are we sure these are part of cygwin/mingw?

If we are confident that these are all GPLv3 or GPLv3+runtime exception then (I think) I would be satisfied just changing the text of the third-party README to be something like:

"Certain binaries in this distribution do not originate from the Rust project, but are distributed with it in its binary form. These binaries, including gcc and other parts of the GNU compiler toolchain, are licensed either under the terms of the GNU General Public License, or the GNU General Public License with the GCC Runtime Library Exception, as published by the Free Software Foundation, either version 3, or (at your option) any later version. See the files COPYING3 and COPYING.RUNTIME respectively.

You can obtain a copy of the source of these libraries from the MinGW-builds project[1].

[1]: link to somewhere useful"

…n LTO.

vadimcn · 2014-09-11T08:27:05Z

Updated license notice, fixed overlong paths (also for dylibs).

vadimcn · 2014-09-11T08:27:12Z

r?

…bin/) to PATH during linking, so that rustc can invoke them.

gcc, ld, ar, dlltool, windres go into $(RUST)/bin/rustlib/<triple>/bin/ platform libraries and startup objects got into $(RUST)/bin/rustlib/<triple>/lib/

Package rustc's mingw dependencies into Windows installer to avoid requiring a separate mingw install. Closes #11782

seanmonstar · 2014-09-12T01:10:18Z

Does this make rustc work from cmd.exe?

retep998 · 2014-09-12T02:06:00Z

@seanmonstar rustc has always worked from cmd.exe. All you needed to do was make sure that mingw was on the PATH. Now that the required mingw tools are bundled in the Rust installer, you no longer need to have mingw in your PATH.

seanmonstar · 2014-09-12T02:14:01Z

Finding mingw a pain to get working correctly on each Windows install, I've
just not bothered. So, this means that my not having mingw is no longer an
issue.

ghost · 2014-09-12T05:37:56Z

@seanmonstar Yes , you won't require mingw after this.

…lnicola fix: check for client support of relative glob patterns before using them Fixes rust-lang#16955

alexcrichton reviewed Sep 3, 2014
View reviewed changes

vadimcn force-pushed the package-gcc branch from 859b6c5 to 4067ace Compare September 3, 2014 21:55

alexcrichton reviewed Sep 4, 2014
View reviewed changes

Remove dependency on GCC's LTO linker plugin, since Rust does its' ow…

76c02af

…n LTO.

vadimcn force-pushed the package-gcc branch from 4067ace to 484edd0 Compare September 11, 2014 08:25

vadimcn added 3 commits September 11, 2014 09:40

Append target-specific tools directory ($(RUST)/bin/rustlib/<triple>/…

c05ba8a

…bin/) to PATH during linking, so that rustc can invoke them.

Update license notice.

0ac9e9b

Package rustc's mingw dependencies into Windows installer.

7085b3e

gcc, ld, ar, dlltool, windres go into $(RUST)/bin/rustlib/<triple>/bin/ platform libraries and startup objects got into $(RUST)/bin/rustlib/<triple>/lib/

vadimcn force-pushed the package-gcc branch from 484edd0 to 7085b3e Compare September 11, 2014 16:40

bors added a commit that referenced this pull request Sep 11, 2014

auto merge of #16957 : vadimcn/rust/package-gcc, r=brson

06c0b1d

Package rustc's mingw dependencies into Windows installer to avoid requiring a separate mingw install. Closes #11782

bors closed this Sep 12, 2014

bors merged commit 7085b3e into rust-lang:master Sep 12, 2014

vadimcn mentioned this pull request Oct 3, 2014

A portable Version of Rust Compiler for Windows #3459

Closed

vadimcn deleted the package-gcc branch March 1, 2015 08:03

bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 31, 2024

Auto merge of rust-lang#16957 - poliorcetics:ab/push-tlzsqmqqurxs, r=…

899db83

…lnicola fix: check for client support of relative glob patterns before using them Fixes rust-lang#16955

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Package mingw dependencies #16957

Package mingw dependencies #16957

vadimcn commented Sep 3, 2014

alexcrichton Sep 3, 2014

thestinger Sep 3, 2014

vadimcn Sep 3, 2014

ahmedcharles Sep 12, 2014

vadimcn Sep 12, 2014

ahmedcharles Sep 12, 2014

alexcrichton commented Sep 3, 2014

brson commented Sep 4, 2014

brson commented Sep 4, 2014

vadimcn commented Sep 4, 2014

vadimcn commented Sep 4, 2014

alexcrichton Sep 4, 2014

vadimcn Sep 4, 2014

alexcrichton Sep 4, 2014

alexcrichton commented Sep 4, 2014

vadimcn commented Sep 4, 2014

brson commented Sep 5, 2014

vadimcn commented Sep 11, 2014

vadimcn commented Sep 11, 2014

seanmonstar commented Sep 12, 2014

retep998 commented Sep 12, 2014

seanmonstar commented Sep 12, 2014

ghost commented Sep 12, 2014

Package mingw dependencies #16957

Package mingw dependencies #16957

Conversation

vadimcn commented Sep 3, 2014

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alexcrichton commented Sep 3, 2014

brson commented Sep 4, 2014

brson commented Sep 4, 2014

vadimcn commented Sep 4, 2014

vadimcn commented Sep 4, 2014

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alexcrichton commented Sep 4, 2014

vadimcn commented Sep 4, 2014

brson commented Sep 5, 2014

vadimcn commented Sep 11, 2014

vadimcn commented Sep 11, 2014

seanmonstar commented Sep 12, 2014

retep998 commented Sep 12, 2014

seanmonstar commented Sep 12, 2014

ghost commented Sep 12, 2014