Darwin fixes #1
Darwin fixes #1
Conversation
copart-jafloyd
force-pushed
the
darwin_fixes
branch
from
8658f07
to
383ef79
Compare
|
rebased on master |
copart-jafloyd
force-pushed
the
darwin_fixes
branch
2 times, most recently
from
3e94612
to
ea60985
Compare
|
rebased on master |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
cognifloyd
force-pushed
the
darwin_fixes
branch
from
7e921aa
to
80e5d5f
Compare
This comment has been minimized.
This comment has been minimized.
cognifloyd
force-pushed
the
darwin_fixes
branch
from
80e5d5f
to
324ca03
Compare
This comment has been minimized.
This comment has been minimized.
cognifloyd
force-pushed
the
darwin_fixes
branch
from
324ca03
to
72347f1
Compare
|
rebased on master (dropped symlink sdk changes in favor of Fabian's update in master and dropped cmake commit as |
|
I submitted the required ebuild changes to
The last thing to do to get the clang based bootstrap working on ~x64-macos is finish reworking the sys-libs/tapi ebuild. |
cognifloyd
force-pushed
the
darwin_fixes
branch
from
72347f1
to
96f5eaf
Compare
This is for the clang-based bootstrap. Uses C_INCLUDE_PATH and CPLUS_INCLUDE_PATH env vars to add the darwin-specific include paths. It uses EPREFIX/MacOSX.sdk similar to the DARWIN_USE_GCC bootstrap. Also, this should work with either CommandLineTools or Xcode provided developer compiler + headers. Bug: https://bugs.gentoo.org/757513 Signed-off-by: Jacob Floyd <cognifloyd@gmail.com>
cognifloyd
force-pushed
the
darwin_fixes
branch
from
96f5eaf
to
4d01233
Compare
This "bootstraps" libtapi in stage2 by symlinking the system lib into EPREFIX/tmp. It also downloads the macports build of libtapi to use their compiled headers, which allows linking with the system lib. Once we have a gentoo-built copy of libtapi, we might want to create an archive with only the headers in it so that we can bootstrap without downloading the macports build. Bug: https://bugs.gentoo.org/758167 Signed-off-by: Jacob Floyd <cognifloyd@gmail.com>
Newer llvm requires gnuconfig, so bootstrap it in stage2. Bug: https://bugs.gentoo.org/758167 Signed-off-by: Jacob Floyd <cognifloyd@gmail.com>
libunwind is not available yet, and has more deps than we care to deal with, so just compile libcxx without libunwind in stage2 & stage3. Bug: https://bugs.gentoo.org/758167 Signed-off-by: Jacob Floyd <cognifloyd@gmail.com>
llvm and clang need to be built with the same libc++. If you don't build with the same libc++ then you get weird errors where comparing std::error_code's fails because llvm has one errc enum, and clang has a different one. Also, make sure to use our libc++, not the system provided libc++ in both stage 2 and stage3 when building llvm and clang. To make this work, we need to control CPLUS_INCLUDE_PATH carefully at several points. Bug: https://bugs.gentoo.org/758167 Signed-off-by: Jacob Floyd <cognifloyd@gmail.com>
- Patch stage1 bootstrapped python to disable _scproxy module (which is what the ebuild does. - Adjust the PATH to include newer llvm (11 and 12) paths - Drop llvm-nm darwin hack for newer llvm (not needed any more) Bug: https://bugs.gentoo.org/758167 Signed-off-by: Jacob Floyd <cognifloyd@gmail.com>
cognifloyd
force-pushed
the
darwin_fixes
branch
from
4d01233
to
ba5867a
Compare
- Increase verbosity to print make commands and bootstrap PVs. - Also fix a typo in a comment. - print pakage list during emerge -e system Signed-off-by: Jacob Floyd <cognifloyd@gmail.com>
Prefer releases over rc Signed-off-by: Jacob Floyd <cognifloyd@gmail.com>
gettext needs nls support on darwin or it doesn't build with the newer bison. Signed-off-by: Jacob Floyd <cognifloyd@gmail.com>
cognifloyd
force-pushed
the
darwin_fixes
branch
from
ba5867a
to
43b2a28
Compare
bootstrap_setup happens at the end of stage1, but we need the MacOSX.sdk symlink in order to bootstrap everything during stage1. A function lets us do this in both places as needed.
- bootstrap cmake (stage1) on a Darwin profile without GCC, such that we can bootstrap llvm without having to get cmake which has too many (problematic) deps - use native-cctool to avoid bootstrapping binutils-apple, which is difficult to get given its (compiler) dependencies (this make a bunch of things unnecessary from #1) Signed-off-by: Fabian Groffen <grobian@gentoo.org>
|
stage1 and stage2 are fixed now |
|
Also, how are you with stage3? Looks like you added commits and closed bugs after you said stage1/2 were fixed. |
|
Yes, after two bootstraps I've entered a state of extreme depression where I believe things are messed up considerably due to multiple factors (platform being arm64-macos). I still have a deep dislike for llvm/clang, and part of it may be in the way Gentoo tries to ship it in separate parts, but also, it seems all too brittle to ever get stable enough over releases and newer ebuilds. I have a stage3 prefix, where frankly the (arm64) system starts acting up badly not being able to perform the most basic tasks, yet it seems there's no way out whatsoever, GCC on arm64 isn't ready yet, and llvm we really should be using 12, but we're with 11. I've beaten the ld64 horse for most of the past year, and I think it's sort of successful: got a linker, no need for tapi, yet the assembler is bound to fall back to the host. The good thing of that is that at we're slightly better than native-cctools, in providing our own cruft, yet, it isn't the full deal. Likely never is going to come, so whatever, at least that's under control. |
|
Did you try with my branch? I got nearly all the way through As far as 12 goes, apple jumped the gun releasing their v12 before llvm released v12. So, you could also try v12.0.9999, but using live ebuilds comes with its own set of gotchas. |
|
see tapilite dir in https://github.com/grobian/darwin-xtools Catalina isn't Big Sur, and x86_64 isn't quite arm64 either. It looks as if 12 is out now, but indeed Apple did the thing they always do: release beta software, so I'm affraid for the arm64 part, it's just a matter of waiting before I can make this piece of silicon useful. Sam seems to have hit the same problem as I did on x86_64 though, so perhaps I did miss something from your work. |
|
Thanks. I think this branch is pretty much obsolete now. So, I'll close this. I have rebased my changes, reordering commits and rewording a few commit messages to make the intent of some other commits a bit clearer. If you want to check out that work, it's in my wip_darwin_rebase branch. Sorry, I do not have time to re-test those changes (yet). Everything before the |
This adds the bootstrap-prefix.sh patches attached to these bugs (to simplify reviewing the changes):