Skip to content

scripts/bootstrap-prefix: make darwin bootstrap with clang - #45

Open
plxty wants to merge 2 commits into
gentoo:masterfrom
plxty:fix-macos-clang
Open

scripts/bootstrap-prefix: make darwin bootstrap with clang#45
plxty wants to merge 2 commits into
gentoo:masterfrom
plxty:fix-macos-clang

Conversation

@plxty

@plxty plxty commented Aug 28, 2026

Copy link
Copy Markdown

In Darwin there's plenty of tools that now use macOS infra such as nodejs, many rust libraries... For GCC lacks of macOS builtins and the blocks extension, building many tools require a lot of hack, switching to clang will reduce some pain.

This is still a proof-of-concept style, it works on my macOS 26, but may not be a clean way, and may not work for other macOS version.

Changes explaination:

  1. Darwin ships with builtin libc++, for Gentoo clang with isolated libc++ to work, changes required: compiler flag -stdlib++-isystem to use Gentoo headers, and building libcxx requires -DLIBCXX_ABI_NAMESPACE= to avoid conflicting the system one.
  2. So in stage 2 we still use macOS libcxx, then in stage3 we shall emerge the libcxx and switching toolchain like ninja and rest to use the Gentoo lib.
  3. Uniform STAGE and BOOTSTRAP_STAGE, but I'm not sure if that's the correct way :/
  4. Adding bash requirement check for array stuff like ( xxx ) to work

Still this is a proof-of-concept, managed to get bootstrap but may encounter other issues.

@thesamesam thesamesam left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

It looks good to me.

@plxty
plxty marked this pull request as ready for review August 31, 2026 10:57
@plxty plxty changed the title WIP: scripts/bootstrap-prefix: make darwin bootstrap with clang scripts/bootstrap-prefix: make darwin bootstrap with clang Aug 31, 2026
vdb=${vdb%-*}
evdb=${evdb%-r*}
evdb=${evdb%_p*}
evdb=${evdb%-r[[:digit:]]*}

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

what in particular does this fix? does it accidentially match a wrong package?

@plxty plxty Sep 6, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

It's a little fix for re-stage, for example when first attempt of stage 2 is failed for some package, when I retry it will ignore some already merged packages and then re-emerge again.

The particular example is llvm-runtimes/clang-runtime, which in here -runtime will get stripped and leaving final evdb as llvm-runtimes/clang which is a non-existance package.

Safe to revert, as it just cost a little more re-bootstrap time for debugging :)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

ack

Comment thread scripts/bootstrap-prefix.sh Outdated
Comment thread scripts/bootstrap-prefix.sh
Comment thread scripts/bootstrap-prefix.sh Outdated
@plxty
plxty force-pushed the fix-macos-clang branch 3 times, most recently from de0e8ec to 121d221 Compare September 7, 2026 13:45
Comment thread scripts/bootstrap-prefix.sh Outdated
: # this is Clang, recent enough to compile recent clang
;;
stage3:)
: # for Clang in stage 3, we should already have a good compiler

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

We should, but this is the same for GCC. Are you trying to avoid a rebuild or something? If the package didn't update, and it's good, it should stay where it is, or is there another reason?

Comment thread scripts/bootstrap-prefix.sh Outdated
"default-lld"
)
if [[ "${BOOTSTRAP_STAGE}" == stage2 ]] ; then
if [[ "${STAGE}" == stage2 ]] ; then

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

so I now understand where this mess comes from, I just cleaned it up in da92e6e and we can use BOOTSTRAP_STAGE always/everywhere now

@plxty
plxty force-pushed the fix-macos-clang branch 2 times, most recently from 4fc4545 to a5da4a7 Compare September 8, 2026 03:31
Signed-off-by: Zigit Zo <byte@kei.network>
Signed-off-by: Zigit Zo <byte@kei.network>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants