Skip to content

mrustc: update to 20220125 #13817

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

Merged
merged 2 commits into from
Feb 12, 2022
Merged

mrustc: update to 20220125 #13817

merged 2 commits into from
Feb 12, 2022

Conversation

catap
Copy link
Contributor

@catap catap commented Jan 29, 2022

Description

It also:

  • blacklisted unsupported compillers;
  • added full rust and cargo bootsrap;
  • fixed build on macOS 10.6;
  • claim myself as maintainer.

Yeah, it brings rust to macOS 10.6.

This rust is installed under /opt/local/libexec/mrustc-1.39.

See: https://trac.macports.org/ticket/64146

Type(s)
  • bugfix
  • enhancement
  • security fix
Tested on

macOS 10.6.8 10K549 x86_64
Xcode 3.2.6 10M2518

macOS 12.1 21C52 x86_64
Xcode 13.2.1 13C100

Verification

Have you

  • followed our Commit Message Guidelines?
  • squashed and minimized your commits?
  • checked that there aren't other open pull requests for the same change?
  • referenced existing tickets on Trac with full URL?
  • checked your Portfile with port lint --nitpick?
  • tried existing tests with sudo port test?
  • tried a full install with sudo port -vst install?
  • tested basic functionality of all binary files?

@catap
Copy link
Contributor Author

catap commented Jan 29, 2022

And I'd love to share the picture:

Screen shot 2022-01-29 at 11 58 14 PM

Cc: @evanmiller @kencu

@catap
Copy link
Contributor Author

catap commented Jan 29, 2022

@g5pw / @herbygillot the next step will be integrate it into existed rust port. Because it requires some patches to rust and rust's llvm.... well.. I suggest to install mrustc as dependency and add a few symlinks for cargo and rust port :)

Do you have anything in mind?

@kencu
Copy link
Contributor

kencu commented Jan 29, 2022

Great work - lots of nice effort here. Will be important if MacPorts is to not soon lose 10.6 support soon, for sure.

BTW, I found something interesting here for you, on a separate but somewhat related topic. One of the fellows who is around MacPorts sometimes has written up a very detailed, exactly what happens when and in what code, description of how the darwin 10.7+ thread_local_storage program is implemented. Some details here I had not seen summarized before:

iains/gcc-darwin-arm64#1 (comment)

@kencu
Copy link
Contributor

kencu commented Jan 29, 2022

Now that you have a rust that works on 10.6, perhaps that could be used to step-by-step move towards a current rustc manually, at least. Then that could be used either directly, or as a bootstrap for rust instead of the one usually pulled by rustup.

I have done something very similar for ghc, and I use this to build all the current ports in macports that use ghc (shellcheck, pandoc, etc) on 10.6.8, and as a bootstrap compiler for newer ghc versions (every once in a while, I update them to the current releases):

https://github.com/kencu/ghc-for-older-darwin-systems/releases

@catap
Copy link
Contributor Author

catap commented Jan 29, 2022

@kencu it uses mrustc as the way to compile it and upstream is working to support 1.54.

To be honest it still needs some patches to LLVM and rust to make it works, but this port includes full bootstrapped rust :)

@kencu
Copy link
Contributor

kencu commented Jan 30, 2022

yep, I get it. But now that you have a working rustc, you could forget all about mrustc now, and use your working rust 1.39 to step up to the current rust, in a few steps, with whatever rust patches are needed of curse.

This is exactly what I did with ghc.

@catap
Copy link
Contributor Author

catap commented Jan 30, 2022

@kencu I'm too lazy to do it to be honest. To build rust 1.58 I must use rust 1.57+; it is 1.39 that means that I need to iterate the loop for 19 times.

This also includes to update patches to LLVM and rust. I do have everything ready for 1.54. Or at least as far as I can test.

@kencu
Copy link
Contributor

kencu commented Jan 30, 2022

if mrustc is likely to get you to 1.54, sure, faster then.

I haven’t looked at what the reach is for rust… for ghc it’s 2 jumps.

@catap
Copy link
Contributor Author

catap commented Jan 30, 2022

@kencu a few jumps is simpler :) but rust supports quite strange policy and can't be build but rust compiler that is more than a moth old.

@kencu
Copy link
Contributor

kencu commented Jan 30, 2022

I see you’re right about that… they can only build with the one before… yeah, that is a lot of steps.

https://news.ycombinator.com/item?id=18686720

@catap
Copy link
Contributor Author

catap commented Jan 30, 2022

@kencu the issue that I need bootstrap not only rust, but also cargo... seems like insanity, isn't it?

Copy link
Contributor

@evanmiller evanmiller left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very cool! Just a few minor comments from me


version 20220111
version 20220115
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't really matter but the title says 20220125 (which I think is the correct value)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed!

@@ -59,46 +62,120 @@ compiler.blacklist *gcc*
# depends_run-append port:[string map {"macports-gcc-" "gcc"} ${configure.compiler}]
#}

# https://github.com/thepowersgang/mrustc/pull/192
patchfiles-append patch-mrustc-macos-bootstrap.diff
# Patches avaialble as git branch: https://github.com/catap/mrustc/tree/macports
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

avaialble => available

set pythonfullpath /usr/bin/python2.7
} else {
set pythonfullpath ${prefix}/bin/python2.7
depends_lib-append port:python27
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be depends_run? (depends_run is used if there is no library linkage.)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In llvm/clang, it is listed as depends_lib, because you need it for both build and run (depends_build + depends_run = depends_lib). Here you only need it for the build I believe, and not at runtime, so it could be depends_build.

Copy link
Contributor Author

@catap catap Jan 30, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@evanmiller nope, the only reason to use python2.7 is make clang's cmake happy. After it is built, python2.7 is useless.

After a coffee I realized that you both mean. Thanks!

foreach f {rustc cargo} {
xinstall -m 0755 -W ${worksrcpath}/output-${rust_version} $f \
${destroot}${prefix}/libexec/mrustc-${rust_version_major}/bin
system -W ${destroot}${prefix}/bin/ "ln -s ../libexec/mrustc-${rust_version_major}/bin/$f ./mrustc-${f}"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't wait to build some things with it :-)

}

# Run a Hello, world! test
test.env RUSTC_VERSION=${rust_version} MRUSTC_LIBDIR=output-${rust_version}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

MRUSTC_LIBDIR was intentional because it needs to know where the built libraries are before they are installed. (Otherwise the test phase will look for libraries in ${prefix}.)

@catap catap force-pushed the mrustc branch 2 times, most recently from e7cdd3b to 14be6b1 Compare January 30, 2022 12:47
@catap catap requested a review from kencu January 30, 2022 13:24
@catap catap force-pushed the mrustc branch 2 times, most recently from 3d29286 to ed61855 Compare January 30, 2022 16:11
@Gcenx
Copy link
Contributor

Gcenx commented Jan 30, 2022

I’ll be keeping an eye on your mrustc fork as mrustc seems to be the only sane way to bootstrap for i686-apple-darwin

@catap catap force-pushed the mrustc branch 4 times, most recently from 707b926 to 8ce5058 Compare January 30, 2022 20:09
@evanmiller
Copy link
Contributor

I am seeing some build failures locally (10.6.8) that look like upstream bugs – something about non-UTF-8 C sources and then an unrecognized symbol in the generated C code. I will try again with your latest patches and report back.

@catap catap force-pushed the mrustc branch 4 times, most recently from 85d05ad to 90e4cac Compare February 9, 2022 19:03
@kencu
Copy link
Contributor

kencu commented Feb 9, 2022

If you can now go clang -> mrustc -> rustc 1.54 then that is a real leap forward!

Thanks, will try.

@catap
Copy link
Contributor Author

catap commented Feb 9, 2022

@kencu I'll ping you when it's done. Right now I'm polishing it :)

@catap
Copy link
Contributor Author

catap commented Feb 9, 2022

@kencu anyway, I have strange question. Right now CI fails because of wrong checksum and the issue that port fetches both distfiles from github.

Do you know any nice way to overstep this issue?

Figured it out.

@catap catap force-pushed the mrustc branch 6 times, most recently from 6a3a647 to ad4222e Compare February 10, 2022 15:07
@catap catap marked this pull request as ready for review February 10, 2022 15:07
@catap
Copy link
Contributor Author

catap commented Feb 10, 2022

@kencu, @evanmiller, @Gcenx it's ready for review.

Feel free to install mrustc-rust and enjoy usual rust and cargo in /op/local/libexec/mrustc-rust. I haven't pushed the next steps because building time of this is incredible (~5 hours) and I hope to have a green mark from CI.

Anyway, if your machine has enough RAM (enough means 8G) feel free to edit this port file and uncomment lines 180-181 what reduce building time significantly.

The root cause of such memory consumption is paralell run of clang which is compiling:

-rw-r--r--  1 macports  wheel   834M Feb 10 15:15 rustc-build/librustc_query_impl.rlib.c
-rw-r--r--  1 macports  wheel   431M Feb 10 16:00 rustc-build/librustc_mir.rlib.c
-rw-r--r--  1 macports  wheel   399M Feb 10 15:04 rustc-build/librustc_middle.rlib.c

P.S. I do have as the next step rust-1.54 without any wrappers and install_name_tool -change hacks, and testing rust-1.55

@evanmiller
Copy link
Contributor

Have you tested GCC support since the Core2 patches were merged? Would be nice to support it at least with the base mrustc.

@catap
Copy link
Contributor Author

catap commented Feb 10, 2022

@evanmiller I've started with building LIBS and it moved forward, but not sure had I allow to finish or interrupt.

Anyway, support of gcc on macOS 10.6 is tricky and I prefer to not waste time on it.

@kencu
Copy link
Contributor

kencu commented Feb 10, 2022

Last night I installed these:

  mrustc @20220209_0 (active) requested_variants='' platform='darwin 10' archs='x86_64' date='2022-02-09T21:39:41-0800'
  mrustc-rust @20220209_0 (active) requested_variants='' platform='darwin 10' archs='x86_64' date='2022-02-10T03:04:57-0800'
  rust-legacy-bootstrap @20220209_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2022-02-09T21:26:22-0800'

and they seem to provide a working rustc and cargo, versions 1.54.

SnowLeopardServerVM:mrustc $ /opt/local/libexec/mrustc-rust/bin/cargo  -V
cargo 1.54.0
SnowLeopardServerVM:mrustc $ /opt/local/libexec/mrustc-rust/bin/rustc  -V
rustc 1.54.0-stable-mrustc

I'm not sure what you changed after that, but these seem to work.

Now have to figure out how to get MacPorts to accept them as replacements for rust/cargo, until such time as they are used to bootstrap to current rust versions in the real ports.

Looking good.

@catap
Copy link
Contributor Author

catap commented Feb 10, 2022

@kencu I've updated used version of mrustc which allows to run without any additional patches to it :)

I also fixed a build of cargo which produces unworking cargo if libgit2 was installed.

Regarding integration: my plan is backport my legacy patch to current master and introduce a few rust-... ports. As soon as it merged I start to push them one-by-one.

After that I plan to rename current rust port to rust-upstream which allows to remove near of all hacks that it has :)

And when add a simple wrapper-port rust which installs rust-upstream for modern OS and some legacy port for old one.

To be honest everything is ready and just wait to be delivered opened :)

@catap
Copy link
Contributor Author

catap commented Feb 10, 2022

Restarted CI because it was too long for 10.15; probably overload machine.

@catap
Copy link
Contributor Author

catap commented Feb 10, 2022

Wired. One dependencies compiled ~1.5 hours on 10.15:
Screenshot 2022-02-11 at 00 29 52

but on 11 it was something like ten seconds:
Screenshot 2022-02-11 at 00 31 23

@evanmiller
Copy link
Contributor

Lint says:

port lint rust-legacy-bootstrap:
Warning: Line 27 should say "use_configure no" instead of declaring an empty configure phase

I think at this point I wouldn't worry about CI and I would just let the build bots tell you about any platform issues.

It also:
 - switched to rust 1.54.0;
 - blacklisted unsupported compilers;
 - added full rust and cargo bootstrap;
 - fixed build on macOS 10.6;
 - claim myself as maintainer.

 See: https://trac.macports.org/ticket/64146
@catap
Copy link
Contributor Author

catap commented Feb 11, 2022

@kencu may I ask you to move forward with this version and force to bulldbots to test it?

@kencu kencu merged commit 8799784 into macports:master Feb 12, 2022
@catap catap deleted the mrustc branch February 12, 2022 10:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

5 participants