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

Issues with crt2.o and dllcrt2.o from mingw. #53454

Closed
crlf0710 opened this issue Aug 17, 2018 · 2 comments · Fixed by #67429
Closed

Issues with crt2.o and dllcrt2.o from mingw. #53454

crlf0710 opened this issue Aug 17, 2018 · 2 comments · Fixed by #67429
Labels
A-linkage Area: linking into static, shared libraries and binaries A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows C-bug Category: This is a bug. O-windows-gnu Toolchain: GNU, Operating system: Windows T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue.

Comments

@crlf0710
Copy link
Member

Those crt2.o and dllcrt2.o files have to match the gcc.exe used. So for example when i use win-gnu target in a msvc toolchain, I'll install my own copy of MINGW, and it should provide gcc.exe and those .o files, and i shouldn't use the rust-provided one.

So I suggest:

  1. We package these files in "rust-mingw" component instead of current "rust-std" component in win-gnu builds.
  2. Make people able to use an environment variable or something to specify where to pick these .o files in the linker command.
@retep998 retep998 added the O-windows-gnu Toolchain: GNU, Operating system: Windows label Aug 18, 2018
@crlf0710 crlf0710 mentioned this issue Oct 14, 2018
Closed
This was referenced Nov 24, 2018
Closed
Merged
Closed
@oli-obk oli-obk mentioned this issue Dec 6, 2018
Merged
@crlf0710 crlf0710 mentioned this issue Dec 9, 2018
Closed
2 tasks
@Screwtapello Screwtapello mentioned this issue Jan 23, 2019
Merged
rivy added a commit to rivy/rs.coreutils that referenced this issue Mar 13, 2019
@rivy
fix gnu CI build on AppVeyor
c6b9688 
* includes workaround for ongoing `gcc` library issues
  - see github:rust-lang/rust#47048 and github:rust-lang/rust#53454
rivy added a commit to rivy/rs.coreutils that referenced this issue Mar 13, 2019
@rivy
improve AppVeyor CI
b666a3b 
* improves clarity and logging of the AppVeyor config
* "install" is more generic and more easily usable within other rust crates
* includes a fix/workaround for ongoing `gcc` library issues
  - see github:rust-lang/rust#47048 and github:rust-lang/rust#53454
rivy added a commit to rivy/rs.coreutils that referenced this issue Mar 13, 2019
@rivy
CI: improve AppVeyor CI
c921bbd 
* improves clarity and logging of the AppVeyor config
* "install" is more generic and more easily usable within other rust crates
* includes a fix/workaround for ongoing `gcc` library issues
  - see github:rust-lang/rust#47048 and github:rust-lang/rust#53454
rivy added a commit to rivy/rs.coreutils that referenced this issue Mar 13, 2019
@rivy
CI: improve AppVeyor CI
2d190e5 
* improves clarity and logging of the AppVeyor config
* "install" is more generic and more easily usable within other rust crates
* includes a fix/workaround for ongoing `gcc` library issues
  - see github:rust-lang/rust#47048 and github:rust-lang/rust#53454
rivy added a commit to rivy/rs.coreutils that referenced this issue Mar 13, 2019
@rivy
CI: fix and improve AppVeyor CI
98b3d65 
* includes a fix/workaround for ongoing `gcc` library issues
  - see github:rust-lang/rust#47048 and github:rust-lang/rust#53454
  - note: this fix is required for successful gcc/gnu compilation of `expr` on windows
* improves clarity and logging of the AppVeyor config
* "install" is more generic and more easily usable within other rust crates
rivy added a commit to rivy/rs.coreutils that referenced this issue Mar 13, 2019
@rivy
CI: fix and improve AppVeyor CI
35051d7 
* includes a fix/workaround for ongoing `gcc` library issues
  - see github:rust-lang/rust#47048 and github:rust-lang/rust#53454
  - note: this fix is required for successful gcc/gnu compilation of `expr` on windows
* improves clarity and logging of the AppVeyor config
* "install" phase is more generic and more easily usable within other rust crates
@rivy rivy mentioned this issue Mar 13, 2019
Merged
DrSensor added a commit to DrSensor/scdlang that referenced this issue Apr 4, 2019
@DrSensor
Disable build matrix for mingw
d0016ad 
rust-lang/rust#53454
meltinglava pushed a commit to meltinglava/coreutils that referenced this issue Jun 6, 2019
@rivy @meltinglava
CI: fix and improve AppVeyor CI
5610ac6 
* includes a fix/workaround for ongoing `gcc` library issues
  - see github:rust-lang/rust#47048 and github:rust-lang/rust#53454
  - note: this fix is required for successful gcc/gnu compilation of `expr` on windows
* improves clarity and logging of the AppVeyor config
* "install" phase is more generic and more easily usable within other rust crates
@marmistrz marmistrz mentioned this issue Jul 18, 2019
Closed
@DCjanus DCjanus mentioned this issue Jul 26, 2019
Merged
@Amanieu
Copy link
Member

Amanieu commented Oct 29, 2019

Could we always use the crt2.o from the host toolchain? We can get the path by invoking i686-w64-mingw32-gcc -print-file-name=crt2.o

@mati865
Copy link
Contributor

mati865 commented Oct 29, 2019 •
edited
Loading

That was my idea about solving it but couldn't manage to make simple fix.
Probably the best way here would be calling cc once to get the path and cache it. Since it will be the C toolchain lib dir possibility of finding conflicting Rust libs should be zero.

Edit: nowadays also msvcrt.a and mingwex.a also cause issues and the list will grow since Rust shipped libs become more out of sync from mingw-w64 headers installed on the system.
Generally every mingw-w64 lib that is shipped by Rust should be replaced with system one if it's available.

@jonas-schievink jonas-schievink added A-linkage Area: linking into static, shared libraries and binaries A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Nov 19, 2019
@jonas-schievink jonas-schievink added the T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue. label Nov 28, 2019
@mati865 mati865 mentioned this issue Jan 7, 2020
Merged
This was referenced Jan 21, 2020
Closed
Closed
Closed
bors added a commit that referenced this issue Jan 31, 2020
@bors
Auto merge of #67429 - mati865:mingw-ultimate-fix, r=<try>
3392cc9 
windows-gnu: prefer system crt libraries if they are available

This is my proposal (based on `Amanieu`'s idea) on how to fix #47048 and related issues.

The origin of the issue is the fact Rust ships mingw-w64 libraries but no headers and prefers own libraries over the system ones.
This leads to situation when headers aren't compatible with libraries (mingw-w64 doesn't provide any forward compatibility and AFAIK backwards compatibility is guaranteed only within major release series).

It's easier to understand how this PR works when looking at the linker invocation before and with this PR: https://www.diffchecker.com/GEuYFmzo
It adds system libraries path before Rust libraries so the linker will prefer them.
It has potential issue when system has files with the same names as Rust but that could be avoided by moving Rust shipped mingw-w64 libraries from `lib/rustlib/x86_64-pc-windows-gnu/lib` to say `lib/rustlib/x86_64-pc-windows-gnu/lib/mingw`. Then adding linker paths in this order: Rust libraries, system libraries, Rust shipped mingw-w64 libraries.

I don't know if it's worth to cache system libraries path. You can look for `cache: ` string during build Rust: https://pastebin.com/kGEQZGWP
I think there are enough calls to justify caching.

Fixes #47048
Fixes #49078
Fixes #53454
Fixes #60912
@bors bors closed this as completed in 58b8343 Feb 5, 2020
Enselic added a commit to Enselic/bat that referenced this issue Jan 5, 2021
@Enselic
CICD: Build: Enable *-pc-windows-gnu builds again (with 'stable')
2fb1ebd 
All the referenced issues have been closed:
rust-lang/rust#47048
rust-lang/rust#53454
rust-lang/cargo#6754

Since we can (and should) use 'stable' on these targets too, we don't
need the TOOLCHAIN logic any longer, so remove it.
Enselic added a commit to Enselic/bat that referenced this issue Jan 6, 2021
@Enselic
CICD: Build: Enable x86_64-pc-windows-gnu again
f7640f8 
All the referenced issues [1] have been Closed, so use "stable" for
everything. Now `i686-w64-mingw32-gcc` fails with this instead

    error: linker `i686-w64-mingw32-gcc` not found

so keep it disabled. There is probably a simple solution for this that
is obvious to someone used to cross-compiling Rust programs on
Windows...

[1]
rust-lang/rust#47048
rust-lang/rust#53454
rust-lang/cargo#6754
sharkdp pushed a commit to sharkdp/bat that referenced this issue Jan 6, 2021
@Enselic @sharkdp
CICD: Build: Enable x86_64-pc-windows-gnu again
c67b439 
All the referenced issues [1] have been Closed, so use "stable" for
everything. Now `i686-w64-mingw32-gcc` fails with this instead

    error: linker `i686-w64-mingw32-gcc` not found

so keep it disabled. There is probably a simple solution for this that
is obvious to someone used to cross-compiling Rust programs on
Windows...

[1]
rust-lang/rust#47048
rust-lang/rust#53454
rust-lang/cargo#6754
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-linkage Area: linking into static, shared libraries and binaries A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows C-bug Category: This is a bug. O-windows-gnu Toolchain: GNU, Operating system: Windows T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

windows-gnu: prefer system crt libraries if they are available mati865/rust
5 participants
@Amanieu @crlf0710 @retep998 @mati865 @jonas-schievink