Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 758167 - Fix bootstrapping linker/compiler packages for clang-based darwin prefix
Summary: Fix bootstrapping linker/compiler packages for clang-based darwin prefix
Status: UNCONFIRMED
Alias: None
Product: Gentoo/Alt
Classification: Unclassified
Component: Prefix Support (show other bugs)
Hardware: AMD64 OS X
: Normal enhancement with 1 vote (vote)
Assignee: Gentoo Prefix
URL:
Whiteboard:
Keywords: PATCH, PullRequest
Depends on: 757513
Blocks: 755644
  Show dependency tree
 
Reported: 2020-12-03 04:01 UTC by Jacob Floyd
Modified: 2021-01-03 14:37 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
sys-devel/clang/files/11.0.0/prefix-dirs.patch (prefix-dirs.patch,3.17 KB, patch)
2020-12-03 04:01 UTC, Jacob Floyd
Details | Diff
patch for sys-devel/clang/clang-11.0.0.ebuild (clang-11.0.0.ebuild.patch,1.10 KB, patch)
2020-12-03 04:03 UTC, Jacob Floyd
Details | Diff
patch for sys-libs/libcxxabi/libcxxabi-11.0.0.ebuild (libcxxabi-11.0.0.ebuild.patch,1.16 KB, patch)
2020-12-03 04:04 UTC, Jacob Floyd
Details | Diff
patch for sys-libs/libcxx/libcxx-11.0.0.ebuild (libcxx-11.0.0.ebuild.patch,1.99 KB, patch)
2020-12-03 04:05 UTC, Jacob Floyd
Details | Diff
bootstrap-prefix.sh modifications for linker/compiler in stage2 (bootstrap-prefix.sh.patch2,4.87 KB, patch)
2020-12-03 04:11 UTC, Jacob Floyd
Details | Diff
bootstrap-prefix.sh modifications for linker/compiler in stage2 (bootstrap-prefix.sh.patch2,4.87 KB, patch)
2020-12-03 15:10 UTC, Jacob Floyd
Details | Diff
bootstrap-prefix.sh modifications for stage3 (bootstrap-prefix.sh.patch3,2.00 KB, patch)
2020-12-03 15:26 UTC, Jacob Floyd
Details | Diff
sys-devel/binutils-apple/binutils-apple-11.3.1 patch for stage3 (file_758167.txt,783 bytes, patch)
2020-12-03 17:35 UTC, Jacob Floyd
Details | Diff
error in config.log (with clang -v -H output) (file_758167.txt,7.21 KB, text/plain)
2020-12-07 18:26 UTC, Sam James
Details
For testing: my reconstructed conftest.c (file_758167.txt,462 bytes, text/plain)
2020-12-08 16:34 UTC, Jacob Floyd
Details
test clang run showing AvailabilityInternalPrivate.h issue (file_758167.txt,3.90 KB, text/plain)
2020-12-08 16:36 UTC, Jacob Floyd
Details
patch for sys-libs/libcxxabi/libcxxabi-11.0.0.ebuild (libcxxabi-11.0.0.ebuild.patch,584 bytes, patch)
2020-12-10 01:05 UTC, Jacob Floyd
Details | Diff
patch for sys-libs/libcxx/libcxx-11.0.0.ebuild (libcxx-11.0.0.ebuild.patch,1.63 KB, patch)
2020-12-10 01:06 UTC, Jacob Floyd
Details | Diff
sys-devel/clang/files/11.0.0/prefix-dirs.patch (prefix-dirs.patch,3.18 KB, patch)
2020-12-10 01:11 UTC, Jacob Floyd
Details | Diff
bootstrap-prefix.sh modifications for linker/compiler in stage2/3 (0002-Darwin-clang-Build-libcxx-before-llvm-clang.patch,5.28 KB, patch)
2020-12-10 04:12 UTC, Jacob Floyd
Details | Diff
bootstrap-prefix.sh modifications for stage3 (0003-Darwin-Clang-Bootstra-Fixes-for-stage3.patch,2.34 KB, patch)
2020-12-10 04:13 UTC, Jacob Floyd
Details | Diff
Bonus bootstrap-prefix.sh cleanups (0004-bootstrap-prefix-minor-cleanup.patch,2.32 KB, patch)
2020-12-10 04:13 UTC, Jacob Floyd
Details | Diff
patch for sys-devel/binutils-apple/binutils-apple-11.3.1.ebuild (0001-binutils-apple-fix-prefix-bootstrap-stage3.patch,1.62 KB, patch)
2020-12-18 21:36 UTC, Jacob Floyd
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jacob Floyd 2020-12-03 04:01:44 UTC
Created attachment 676360 [details, diff]
sys-devel/clang/files/11.0.0/prefix-dirs.patch

I have several changes to fix bootstrapping with clang on Darwin. I'm testing on MacOSX Catalina (10.15)

These chagnes build on top of the bootstrap-prefix.sh patch in bug#757513
(attachment 676357 [details, diff]).

The required fixes in bootstrap-prefix.sh are:

1- Bootstrap libtapi by making the host libtapi available in the prefix and
   downloading headers to enable building against it (building sys-libs/tapi
   is far too complex to handle during bootstrap). Do this in stage2 just
   before emerging the linker (sys-devel/binutils-apple).
2- Add sys-devel/gnuconfig to llvm_deps because the llvm ebuild copies
   config.guess into the work dir.
3- sys-libs/libcxxabi and sys-libs/libcxx must be installed after llvm
   in every stage, because the ebuilds use the llvm eclass which queries for
   the installed version of llvm.
4- sys-libs/libcxxabi and sys-libs/libcxx need to drop the libunwind useflag
   during stage2 and stage3 as we are not setup to build that dependency yet
   (old libcxx* ebuilds dropped the + from IUSE, but I didn't want to do that
   so that we can stay as close as possible to mainline gentoo)
5- Adjust CPPFFLAGS in stage2 so that llvm and clang are built with the
   path to the SDK Frameworks.

This is how I adjusted the tree:

>	cp -rf ~/p/gentoo/new/clang.files/prefix-dirs.patch "${PORTDIR}"/sys-devel/clang/files/
>	cp -f ~/p/gentoo/new/clang-11.0.0.ebuild "${PORTDIR}"/sys-devel/clang/
>	ebuild "${PORTDIR}"/sys-devel/clang/clang-11.0.0.ebuild manifest
> 
>	cp -f ~/p/gentoo/new/libcxx-portage/libcxx-11.0.0.ebuild "${PORTDIR}"/sys-libs/libcxx/
>	ebuild "${PORTDIR}"/sys-libs/libcxx/libcxx-11.0.0.ebuild manifest
>	cp -f ~/p/gentoo/new/libcxx-portage/libcxxabi-11.0.0.ebuild "${PORTDIR}"/sys-libs/libcxxabi/
>	ebuild "${PORTDIR}"/sys-libs/libcxxabi/libcxxabi-11.0.0.ebuild manifest

So, I am attaching
- sys-devel/clang/files/11.0.0/prefix-dirs.patch (a patch that fixes clang's internal search paths)
- sys-devel/clang/clang-11.0.0.ebuild modified from mainline ebuild with:
    - keyword for ~x64-macos
    - add prefix-dirs.patch to PATCHES
    - add a sed line to src_prepare to inject EPREFIX into the patched files
- sys-libs/libcxxabi/libcxxabi-11.0.0.ebuild
    - keyword for ~x64-macos
    - none of the changes from old prefix ebuilds seemed necessary,
      but I have included them, commented out.
- sys-libs/libcxx/libcxx-11.0.0.ebuild modified from mainline ebuild with:
    - keyword for ~x64-macos
    - add elibc_Darwin useflag (similar to old prefix ebuilds)
    - a few other changes based on the old prefix ebuilds
    - plus a few changes that are left commented out.

Note that I'm having issues, seemingly with the header search paths in clang, after stage3.
So the prefix-dirs.patch may need to be adjusted. I will file another issue for post-stage2 fixes.
Comment 1 Jacob Floyd 2020-12-03 04:03:29 UTC
Created attachment 676363 [details, diff]
patch for sys-devel/clang/clang-11.0.0.ebuild
Comment 2 Jacob Floyd 2020-12-03 04:04:59 UTC
Created attachment 676366 [details, diff]
patch for sys-libs/libcxxabi/libcxxabi-11.0.0.ebuild
Comment 3 Jacob Floyd 2020-12-03 04:05:16 UTC
Created attachment 676369 [details, diff]
patch for sys-libs/libcxx/libcxx-11.0.0.ebuild
Comment 4 Jacob Floyd 2020-12-03 04:11:55 UTC
Created attachment 676375 [details, diff]
bootstrap-prefix.sh modifications for linker/compiler in stage2
Comment 5 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2020-12-03 10:16:23 UTC
We talked about this a bit last night and things ended up dying like:

>/Users/jafloyd/Gentoo/usr/lib/llvm/11/bin/../../../../lib/clang/11.0.0/include/stdlib.h
>"No such file or directory"

despite

>#include <...> search starts here:
>/Users/jafloyd/Gentoo/usr/lib/llvm/11/bin/../../../../lib/clang/11.0.0/include
>/Users/jafloyd/Gentoo/usr/include
>/Users/jafloyd/Gentoo/MacOSX.sdk/usr/include
>/Users/jafloyd/Gentoo/MacOSX.sdk/System/Library/Frameworks (framework directory)
>/System/Library/Frameworks (framework directory)
>/Library/Frameworks (framework directory)

I ran out of ideas eventually. We tried playing with -isystem for the SDK's include dir but this led to trying to include a private Apple header (AvailabilityInternalPrivate.h). Not sure if this is related: https://github.com/macports/macports-ports/blob/master/lang/llvm-10/files/5005-MacPorts-only-patch-libcxx-includes-disable-availability-tests.diff.
Comment 6 Jacob Floyd 2020-12-03 15:10:13 UTC
Created attachment 676531 [details, diff]
bootstrap-prefix.sh modifications for linker/compiler in stage2

fixed the patch so git can apply it
Comment 7 Jacob Floyd 2020-12-03 15:26:36 UTC
Created attachment 676534 [details, diff]
bootstrap-prefix.sh modifications for stage3

Instead of filing a separate bug, I'm posting the stage3 patch here so that we can keep all of the clang debugging conversation in one place.

This patch changes the following in bootstrap-prefix.sh:

1- Add llvm 11/12 paths in stage3 PATHs (using 11 right now)
2- Python needs a fix that is in the ebuild before python gets rebuilt
   in emerge -e system. Without this, portage is dying with _scproxy
   errors. This is actually in stage1, because that's when we bootstrap
   python.
3- Comment out an old hack with nm to see if that fixes the build (it doesn't
   but hopefully we still don't need an llvm-3 hack anymore).
Comment 8 Jacob Floyd 2020-12-03 16:35:20 UTC
So, the clang path issues:

I had to change the order in $compiler so that libcxx* were built after llvm.
This is required because of the llvm eclass which checks for an installed llvm.

So, I tried several different things before ending up with the order in attachment 676531 [details, diff]. Here's the original order:

> compiler="
>   sys-libs/csu
>   dev-libs/libffi
>   ${llvm_deps}
>   sys-libs/libcxxabi
>   sys-libs/libcxx
>   sys-devel/llvm
>   sys-devel/clang"

I tried the building clang after libcxxabi+libcxx like this.

> compiler="
>   sys-libs/csu
>   dev-libs/libffi
>   ${llvm_deps}
>   sys-devel/llvm
>   sys-libs/libcxxabi
>   sys-libs/libcxx
>   sys-devel/clang"

This does allow libcxx* and clang compile, but then sys-apps/gawk fails to compile due to:

>/Users/jafloyd/Gentoo/usr/lib/llvm/11/bin/../../../../lib/clang/11.0.0/include/stdio.h
>No such file or directory

But building clang before libcxx* allows gawk and many other packages
to compile. So, this is the order I ended up with:

> compiler="
>   sys-libs/csu
>   dev-libs/libffi
>   ${llvm_deps}
>   sys-devel/llvm
>   sys-devel/clang
>   sys-libs/libcxxabi
>   sys-libs/libcxx"

So, the next time we build clang is during emerge -e system after stage3.
sys-libs/csu, the package that gets built immediately after clang fails
with the error that Sam mentioned (we were chatting in #gentoo-prefix
about it).

>/Users/jafloyd/Gentoo/usr/lib/llvm/11/bin/../../../../lib/clang/11.0.0/include/stdlib.h
>No such file or directory

Oddly enough, clang does not list libcxx* or llvm in BDEPEND. llvm is in RDEPEND, and libcxx is in PDEPEND but only with the default-libcxx useflag,
which is disabled by default.

And, as Sam mentioned, the search paths (shown by adding -v to CC in make.conf)
appear reasonable.

stage1) clang links against the host's libc++ or libstdc++.
stage2) we have not built libcxx in EPREFIX/tmp yet,
        so clang still uses the host's libc++ or libstdc++.
stage3) libcxx has not been built in EPREFIX yet, so clang must be using
        either the libcxx in EPREFIX/tmp, or the host's libc++ or libstdc++.
emerge -e system) libcxx has clearly been built in EPREFIX (in stage3),
        so clang must be linked with it and should not be using the host's.

To top it off, I added "bash -i" in bootstrap-prefix.sh, just before
"emerge -e system" so that I could try building clang again to see what happens.
This time, clang fails during src_configure:

> -- Linker detection: ld64
> -- Performing Test LLVM_LIBSTDCXX_MIN
> -- Performing Test LLVM_LIBSTDCXX_MIN - Failed
> CMake Error at /Users/jafloyd/Gentoo/usr/lib/llvm/11/lib/cmake/llvm/CheckCompilerVersion.cmake:97 (message):
>   libstdc++ version must be at least 5.1.
> Call Stack (most recent call first):
>   /Users/jafloyd/Gentoo/usr/lib/llvm/11/lib/cmake/llvm/HandleLLVMOptions.cmake:9 (include)
>   CMakeLists.txt:119 (include)

So, how are clang and libcxx* interacting?
Is clang broken, or is libcxx* broken, or both?
Did I miss something important when I bumped to libcxx*-11?
Why would a broken libcxx* break building pure C applications like gawk and csu?
Why can't clang's src_configure phase find libstdc++?
Comment 9 Jacob Floyd 2020-12-03 16:56:11 UTC
Here are is some trimmed ls output to show that both libc++ and libstdc++ are available on the host
and only libc++ is in EPREFIX/tmp and EPREFIX.

% ls -l /usr/lib/lib*c++*
/usr/lib/libc++.1.dylib
/usr/lib/libc++.dylib -> libc++.1.dylib
/usr/lib/libc++abi.dylib
/usr/lib/libstdc++.6.0.9.dylib
/usr/lib/libstdc++.6.dylib -> libstdc++.6.0.9.dylib
/usr/lib/libstdc++.dylib -> libstdc++.6.dylib

% ls -l ~/Gentoo/tmp/usr/lib/lib*c++*
/Users/jafloyd/Gentoo/tmp/usr/lib/libc++.1.0.dylib
/Users/jafloyd/Gentoo/tmp/usr/lib/libc++.1.dylib -> libc++.1.0.dylib
/Users/jafloyd/Gentoo/tmp/usr/lib/libc++.a
/Users/jafloyd/Gentoo/tmp/usr/lib/libc++.dylib -> libc++.1.dylib
/Users/jafloyd/Gentoo/tmp/usr/lib/libc++abi.1.0.dylib
/Users/jafloyd/Gentoo/tmp/usr/lib/libc++abi.1.dylib -> libc++abi.1.0.dylib
/Users/jafloyd/Gentoo/tmp/usr/lib/libc++abi.a
/Users/jafloyd/Gentoo/tmp/usr/lib/libc++abi.dylib -> libc++abi.1.dylib
/Users/jafloyd/Gentoo/tmp/usr/lib/libc++experimental.a

% ls -l ~/Gentoo/usr/lib/lib*c++*
/Users/jafloyd/Gentoo/usr/lib/libc++.1.0.dylib
/Users/jafloyd/Gentoo/usr/lib/libc++.1.dylib -> libc++.1.0.dylib
/Users/jafloyd/Gentoo/usr/lib/libc++.a
/Users/jafloyd/Gentoo/usr/lib/libc++.dylib -> libc++.1.dylib
/Users/jafloyd/Gentoo/usr/lib/libc++abi.1.0.dylib
/Users/jafloyd/Gentoo/usr/lib/libc++abi.1.dylib -> libc++abi.1.0.dylib
/Users/jafloyd/Gentoo/usr/lib/libc++abi.a
/Users/jafloyd/Gentoo/usr/lib/libc++abi.dylib -> libc++abi.1.dylib
/Users/jafloyd/Gentoo/usr/lib/libc++experimental.a
Comment 10 Jacob Floyd 2020-12-03 17:04:32 UTC
Here are internal versions for the lib*c++.dylib (with adjusted spacing
to make it easier to read in this comment)

================================================================

% otool -L /usr/lib/lib*c++*.dylib

/usr/lib/libc++.1.dylib:
  /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 902.1.0)
  /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)
  /usr/lib/libc++abi.dylib (compatibility version 1.0.0, current version 902.0.0)

/usr/lib/libc++abi.dylib:
  /usr/lib/libc++abi.dylib (compatibility version 1.0.0, current version 902.0.0)
  /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)

/usr/lib/libstdc++.6.0.9.dylib:
  /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 104.1.0)
  /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)
  /usr/lib/libc++abi.dylib (compatibility version 1.0.0, current version 902.0.0)

================================================================

% otool -L ~/Gentoo/tmp/usr/lib/libc++{,abi}.1.0.dylib

/Users/jafloyd/Gentoo/tmp/usr/lib/libc++.1.0.dylib:
  @rpath/libc++.1.dylib (compatibility version 1.0.0, current version 1.0.0)
  /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)
  @rpath/libc++abi.1.dylib (compatibility version 1.0.0, current version 1.0.0)

/Users/jafloyd/Gentoo/tmp/usr/lib/libc++abi.1.0.dylib:
  @rpath/libc++abi.1.dylib (compatibility version 1.0.0, current version 1.0.0)
  /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)

================================================================

jafloyd@MB-JAFLOYD prefix.git % otool -L ~/Gentoo/usr/lib/libc++{,abi}.1.0.dylib   
/Users/jafloyd/Gentoo/usr/lib/libc++.1.0.dylib:
  @rpath/libc++.1.dylib (compatibility version 1.0.0, current version 1.0.0)
  /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)
  @rpath/libc++abi.1.dylib (compatibility version 1.0.0, current version 1.0.0)

/Users/jafloyd/Gentoo/usr/lib/libc++abi.1.0.dylib:
  @rpath/libc++abi.1.dylib (compatibility version 1.0.0, current version 1.0.0)
  /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)
Comment 11 Jacob Floyd 2020-12-03 17:08:11 UTC
And similarly for clang:

================================================================

% otool -L /Library/Developer/CommandLineTools/usr/bin/clang

/Library/Developer/CommandLineTools/usr/bin/clang:
  /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
  /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)
  /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.0.0)
  /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 904.4.0)

================================================================

% otool -L ~/Gentoo/tmp/usr/lib/llvm/11/bin/clang-11

/Users/jafloyd/Gentoo/tmp/usr/lib/llvm/11/bin/clang-11:
  @rpath/libclang-cpp.dylib (compatibility version 0.0.0, current version 0.0.0)
  @rpath/libLLVM.dylib (compatibility version 1.0.0, current version 11.0.0)
  /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 902.1.0)
  /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)

================================================================

% otool -L ~/Gentoo/usr/lib/llvm/11/bin/clang-11

/Users/jafloyd/Gentoo/usr/lib/llvm/11/bin/clang-11:
  @rpath/libclang-cpp.dylib (compatibility version 0.0.0, current version 0.0.0)
  @rpath/libLLVM.dylib (compatibility version 1.0.0, current version 11.0.0)
  @rpath/libc++.1.dylib (compatibility version 1.0.0, current version 1.0.0)
  /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)
Comment 12 Jacob Floyd 2020-12-03 17:24:55 UTC
interesting. libSystem.B.dylib includes libc
https://www.oreilly.com/library/view/mac-os-x/0596003560/ch05s02.html

Is it possible (desirable?) to build our own libc for the prefix?
Those are the headers that are provided in the SDK that we keep having issues locating.
Comment 13 Jacob Floyd 2020-12-03 17:35:01 UTC
Created attachment 676591 [details, diff]
sys-devel/binutils-apple/binutils-apple-11.3.1 patch for stage3

Oh, and I forgot to post the required tree update to get through stage3:

>	cp -f ~/p/gentoo/new/binutils-apple-11.3.1.ebuild "${PORTDIR}"/sys-devel/binutils-apple/
>	ebuild "${PORTDIR}"/sys-devel/binutils-apple/binutils-apple-11.3.1.ebuild manifest

and to allow portage to resolve everything in emerge -e system, I had to
keyword llvm-libunwind-11:

>	sed -i -e '/^KEYWORDS=/s/x86"/x86 ~x64-macos"/' "${PORTDIR}"/sys-libs/llvm-libunwind/llvm-libunwind-11.0.0.ebuild
>	ebuild "${PORTDIR}"/sys-libs/llvm-libunwind/llvm-libunwind-11.0.0.ebuild manifest

In binutils-apple-11.3.1.ebuild, I had to add this to src_prepare because I was
I was getting errors building it:
>+	# TARGET_OS_BRIDGE is undefined in TargetConditionals.h of newer MacOSX.sdk.
>+	# We don't target BridgeOS. Disable it to avoid errors when clang adds:
>+	# -Werror,-Wundef-prefix=TARGET_OS_
>+	sed -i -e 's/#if TARGET_OS_BRIDGE/#if 0/' include/mach-o/dyld_priv.h
Comment 14 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2020-12-07 18:26:43 UTC
Created attachment 677179 [details]
error in config.log (with clang -v -H output)

Any ideas, grobian?

Jacob's tried asking around the LLVM folks but none of them seem to have any ideas. It actually picks up the stdio.h from the SDK but it doesn't like it.
Comment 15 Fabian Groffen gentoo-dev 2020-12-07 18:40:33 UTC
perhaps stupid question, but does /Users/jafloyd/Gentoo/usr/lib/llvm/11/bin/../../../../lib/clang/11.0.0/include/stdio.h exist?
Comment 16 Jacob Floyd 2020-12-07 19:32:33 UTC
No it doesn't exist. It should get that (libc) header from the MacOSX.sdk

And it does! Using -v -H in CFLAGS, I get this output (only showing the error section of config.log). So, it's finding stdio.h in the SDK as it should, but then it's dying with the error saying it's not found in resource dir. Interestingly, NOTHING in MacOS.sdk uses #include_next, so that's not the issue. Any ideas?

configure:3718: checking whether we are cross compiling
configure:3726: x86_64-apple-darwin19-clang -o conftest -march=native -O2 -pipe -v -H  -Wl,-dead_strip_dylibs conftest.c  >&5
clang version 11.0.0
Target: x86_64-apple-darwin19
Thread model: posix
InstalledDir: /Users/jafloyd/Gentoo/usr/lib/llvm/11/bin
 "/Users/jafloyd/Gentoo/usr/lib/llvm/11/bin/clang-11" -cc1 -triple x86_64-apple-macosx10.15.0 -Wundef-prefix=TARGET_OS_ -Werror=undef-prefix -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -emit-obj -disable-free -disable-llvm-verifier -discard-value-names -main-file-name conftest.c -mrelocation-model pic -pic-level 2 -mframe-pointer=all -fno-rounding-math -munwind-tables -target-sdk-version=11.0 -fcompatibility-qualified-id-block-type-checking -target-cpu skylake -target-feature +sse2 -target-feature -tsxldtrk -target-feature +cx16 -target-feature +sahf -target-feature -tbm -target-feature -avx512ifma -target-feature -sha -target-feature -gfni -target-feature -fma4 -target-feature -vpclmulqdq -target-feature +prfchw -target-feature +bmi2 -target-feature -cldemote -target-feature +fsgsbase -target-feature -ptwrite -target-feature -amx-tile -target-feature -avx512bf16 -target-feature +popcnt -target-feature +aes -target-feature -avx512bitalg -target-feature -movdiri -target-feature +xsaves -target-feature -avx512er -target-feature +xsavec -target-feature -avx512vnni -target-feature -amx-bf16 -target-feature -avx512vpopcntdq -target-feature -pconfig -target-feature -clwb -target-feature -avx512f -target-feature -clzero -target-feature -pku -target-feature +mmx -target-feature -lwp -target-feature -rdpid -target-feature -xop -target-feature +rdseed -target-feature -waitpkg -target-feature -movdir64b -target-feature -sse4a -target-feature -avx512bw -target-feature +clflushopt -target-feature +xsave -target-feature -avx512vbmi2 -target-feature +64bit -target-feature -avx512vl -target-feature -serialize -target-feature +invpcid -target-feature -avx512cd -target-feature +avx -target-feature -vaes -target-feature +cx8 -target-feature +fma -target-feature -rtm -target-feature +bmi -target-feature -enqcmd -target-feature +rdrnd -target-feature -mwaitx -target-feature +sse4.1 -target-feature +sse4.2 -target-feature +avx2 -target-feature +fxsr -target-feature -wbnoinvd -target-feature +sse -target-feature +lzcnt -target-feature +pclmul -target-feature -prefetchwt1 -target-feature +f16c -target-feature +ssse3 -target-feature +sgx -target-feature -shstk -target-feature +cmov -target-feature -avx512vbmi -target-feature -amx-int8 -target-feature +movbe -target-feature -avx512vp2intersect -target-feature +xsaveopt -target-feature -avx512dq -target-feature +adx -target-feature -avx512pf -target-feature +sse3 -debugger-tuning=lldb -v -H -sys-header-deps -resource-dir /Users/jafloyd/Gentoo/usr/lib/llvm/11/bin/../../../../lib/clang/11.0.0 -internal-isystem /Users/jafloyd/Gentoo/usr/local/include -internal-isystem /Users/jafloyd/Gentoo/usr/lib/llvm/11/bin/../../../../lib/clang/11.0.0/include -internal-isystem /Users/jafloyd/Gentoo/usr/include -internal-isystem /Users/jafloyd/Gentoo/MacOSX.sdk/usr/include -O2 -fdebug-compilation-dir /Users/jafloyd/Gentoo/var/tmp/portage/sys-libs/readline-8.1_rc3/work/host-libtool-0.1.0-amd64 -ferror-limit 19 -stack-protector 1 -fblocks -fencode-extended-block-signature -fregister-global-dtors-with-atexit -fgnuc-version=4.2.1 -fmax-type-align=16 -vectorize-loops -vectorize-slp -o /Users/jafloyd/Gentoo/var/tmp/portage/sys-libs/readline-8.1_rc3/temp/conftest-d30528.o -x c conftest.c
clang -cc1 version 11.0.0 based upon LLVM 11.0.0libcxx default target x86_64-apple-darwin19.6.0
ignoring nonexistent directory "/Users/jafloyd/Gentoo/usr/local/include"
ignoring nonexistent directory "/Users/jafloyd/Gentoo/MacOSX.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
 /Users/jafloyd/Gentoo/usr/lib/llvm/11/bin/../../../../lib/clang/11.0.0/include
 /Users/jafloyd/Gentoo/usr/include
 /Users/jafloyd/Gentoo/MacOSX.sdk/usr/include
 /Users/jafloyd/Gentoo/MacOSX.sdk/System/Library/Frameworks (framework directory)
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
End of search list.
conftest.c:11:10: fatal error: cannot open file '/Users/jafloyd/Gentoo/usr/lib/llvm/11/bin/../../../../lib/clang/11.0.0/include/stdio.h': No such file or directory
#include <stdio.h>
         ^
. /Users/jafloyd/Gentoo/MacOSX.sdk/usr/include/stdio.h
.. /Users/jafloyd/Gentoo/MacOSX.sdk/usr/include/_stdio.h
... /Users/jafloyd/Gentoo/MacOSX.sdk/usr/include/sys/cdefs.h
.... /Users/jafloyd/Gentoo/MacOSX.sdk/usr/include/sys/_symbol_aliasing.h
.... /Users/jafloyd/Gentoo/MacOSX.sdk/usr/include/sys/_posix_availability.h
... /Users/jafloyd/Gentoo/MacOSX.sdk/usr/include/Availability.h
.... /Users/jafloyd/Gentoo/MacOSX.sdk/usr/include/AvailabilityVersions.h
.... /Users/jafloyd/Gentoo/MacOSX.sdk/usr/include/AvailabilityInternal.h
... /Users/jafloyd/Gentoo/MacOSX.sdk/usr/include/_types.h
.... /Users/jafloyd/Gentoo/MacOSX.sdk/usr/include/sys/_types.h
..... /Users/jafloyd/Gentoo/MacOSX.sdk/usr/include/machine/_types.h
...... /Users/jafloyd/Gentoo/MacOSX.sdk/usr/include/i386/_types.h
..... /Users/jafloyd/Gentoo/MacOSX.sdk/usr/include/sys/_pthread/_pthread_types.h
... /Users/jafloyd/Gentoo/MacOSX.sdk/usr/include/sys/_types/_va_list.h
.... /Users/jafloyd/Gentoo/MacOSX.sdk/usr/include/machine/types.h
..... /Users/jafloyd/Gentoo/MacOSX.sdk/usr/include/i386/types.h
...... /Users/jafloyd/Gentoo/MacOSX.sdk/usr/include/sys/_types/_int8_t.h
...... /Users/jafloyd/Gentoo/MacOSX.sdk/usr/include/sys/_types/_int16_t.h
...... /Users/jafloyd/Gentoo/MacOSX.sdk/usr/include/sys/_types/_int32_t.h
...... /Users/jafloyd/Gentoo/MacOSX.sdk/usr/include/sys/_types/_int64_t.h
...... /Users/jafloyd/Gentoo/MacOSX.sdk/usr/include/sys/_types/_u_int8_t.h
...... /Users/jafloyd/Gentoo/MacOSX.sdk/usr/include/sys/_types/_u_int16_t.h
...... /Users/jafloyd/Gentoo/MacOSX.sdk/usr/include/sys/_types/_u_int32_t.h
...... /Users/jafloyd/Gentoo/MacOSX.sdk/usr/include/sys/_types/_u_int64_t.h
...... /Users/jafloyd/Gentoo/MacOSX.sdk/usr/include/sys/_types/_intptr_t.h
....... /Users/jafloyd/Gentoo/MacOSX.sdk/usr/include/machine/types.h
...... /Users/jafloyd/Gentoo/MacOSX.sdk/usr/include/sys/_types/_uintptr_t.h
... /Users/jafloyd/Gentoo/MacOSX.sdk/usr/include/sys/_types/_size_t.h
... /Users/jafloyd/Gentoo/MacOSX.sdk/usr/include/sys/_types/_null.h
... /Users/jafloyd/Gentoo/MacOSX.sdk/usr/include/sys/stdio.h
.. /Users/jafloyd/Gentoo/MacOSX.sdk/usr/include/_ctermid.h
.. /Users/jafloyd/Gentoo/MacOSX.sdk/usr/include/sys/_types/_off_t.h
.. /Users/jafloyd/Gentoo/MacOSX.sdk/usr/include/sys/_types/_ssize_t.h
.. /Users/jafloyd/Gentoo/MacOSX.sdk/usr/include/secure/_stdio.h
... /Users/jafloyd/Gentoo/MacOSX.sdk/usr/include/secure/_common.h
1 error generated.
configure:3730: $? = 1
configure:3737: ./conftest
/Users/jafloyd/Gentoo/var/tmp/portage/sys-libs/readline-8.1_rc3/work/host-libtool-0.1.0/configure: line 3739: ./conftest: No such file or directory
configure:3741: $? = 127
configure:3748: error: in `/Users/jafloyd/Gentoo/var/tmp/portage/sys-libs/readline-8.1_rc3/work/host-libtool-0.1.0-amd64':
configure:3750: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
Comment 17 Fabian Groffen gentoo-dev 2020-12-07 19:39:05 UTC
could it be that clang insists on a sysroot, and that it lives itself inside that sysroot?

The path that it constructs very much suggests that it wants to find its own "fix-included" headers?
Comment 18 Jacob Floyd 2020-12-08 16:24:47 UTC
I re-ordered things so that libcxx & libcxxabi gets installed before clang is compiled in both stage2 and stage3. To make that work, I had to add some logic to drop the CommandLineTools libc++ headers from CPLUS_INCLUDE_DIRS when compiling them.

So, now my error moves into stage 3. Right after clang, readline + gawk is supposed to compile, so that is where the error is occurring.

Looking in config.log, I reconstructed conftest.c and copied the command so I can test it directly. In playing with the command, I removed most of the args and then added some back in so until it didn't have any additional warnings.

Then, I dropped all search paths except for the SDK, and I got this error:

> In file included from /tmp/conftest.c:11:
> In file included from /Users/jafloyd/Gentoo/MacOSX.sdk/usr/include/stdio.h:64:
> In file included from /Users/jafloyd/Gentoo/MacOSX.sdk/usr/include/_stdio.h:69:
> In file included from /Users/jafloyd/Gentoo/MacOSX.sdk/usr/include/Availability.h:136:
> /Users/jafloyd/Gentoo/MacOSX.sdk/usr/include/AvailabilityInternal.h:33:19: fatal error: cannot open file '/Users/jafloyd/Gentoo/MacOSX.sdk/usr/include/AvailabilityInternalPrivate.h': No such file or directory
> #if __has_include(<AvailabilityInternalPrivate.h>)
>                   ^

Maybe, because it is hitting an error with "internal" system headers, the error message is getting swallowed somewhere to try and report to the user that their include is wrong. The assumption behind that behavior is probably that the system headers are already correct, so it must be a user error. So, it reported the "#include <stdio.h>" as having an error instead of the "internal" system headers.

In any case, it is clearly finding stdio.h, now matter how I reorder or cut down the search path (where that path includes the sdk, ofc). So, I think this Availability thing is the real error.

To try fixing that, I patched libcxx & libcxxabi with this patch (via the ebuild) and then continuing with stage2 & 3 compilation, but that did not fix the behavior:
https://github.com/macports/macports-ports/blob/master/lang/llvm-10/files/5005-MacPorts-only-patch-libcxx-includes-disable-availability-tests.diff

That, in turn, suggests that the __has_include macro (builtin for clang) is misbehaving. Why would it be raising a fatal error instead of just returning false when the header is not available?

Any ideas of what we can do to debug that? Perhaps inject some ugly prints in the clang __has_include code so that we can see where the error is happening?
Any other ideas?
Comment 19 Jacob Floyd 2020-12-08 16:34:00 UTC
Created attachment 677248 [details]
For testing: my reconstructed conftest.c

Here's the conftest.c that readline's configure is using. I'm using it to test manually.
Comment 20 Jacob Floyd 2020-12-08 16:36:02 UTC
Created attachment 677251 [details]
test clang run showing AvailabilityInternalPrivate.h issue

Here's my clang test run. It shows the AvailabilityInternalPrivate.h fatal error (where __has_include should just be returning false because the file doesn't exist and continuing).
Comment 21 Jacob Floyd 2020-12-09 17:05:15 UTC
I added ~100 print statements to clang, rebuilding it over and over to test compiling and find out what's going on.

I've traced the error to: https://github.com/llvm/llvm-project/blob/release/11.x/clang/lib/Lex/HeaderSearch.cpp#L327-L337


The compiler is built in the order [llvm, libcxxabi, libcxx, clang] because the llvm eclass requires an installed llvm to build libcxx. So, llvm is linked to the system libc++ v12, and then clang gets linked to libc++ v11 and boom, clang isn't catching the error_codes it thinks it is.

So, clang is comparing with the errors defined in llvm, thus based on the system's libc++. But it's generating the std::error_code using the EPREFIX stdc++, and the objects come from two different stdc++ libs, and therefore they are always != even though the internal integers (2) are the same.

Thus, the right fix is to modify the llvm eclass so that we can bootstrap libcxx before llvm is installed to revert back to this install order:
libcxxabi, libcxx, llvm, clang
Comment 22 Jacob Floyd 2020-12-09 17:56:44 UTC
Actually, what we need to do is modify the libcxx* ebuilds so that when we're bootstrapping llvm, they skip running llvm_pkg_setup. All llvm_pkg_setup does is add the llvm bin dir to the PATH which we already take care of during bootstrap. So, perhaps a bootstrap useflag?
Comment 23 Jacob Floyd 2020-12-10 01:05:54 UTC
Created attachment 677509 [details, diff]
patch for sys-libs/libcxxabi/libcxxabi-11.0.0.ebuild
Comment 24 Jacob Floyd 2020-12-10 01:06:35 UTC
Created attachment 677512 [details, diff]
patch for sys-libs/libcxx/libcxx-11.0.0.ebuild
Comment 25 Jacob Floyd 2020-12-10 01:11:18 UTC
Created attachment 677515 [details, diff]
sys-devel/clang/files/11.0.0/prefix-dirs.patch
Comment 26 Jacob Floyd 2020-12-10 04:12:46 UTC
Created attachment 677524 [details, diff]
bootstrap-prefix.sh modifications for linker/compiler in stage2/3

commit #2 of https://github.com/gentoo/prefix/pull/1
Comment 27 Jacob Floyd 2020-12-10 04:13:16 UTC
Created attachment 677527 [details, diff]
bootstrap-prefix.sh modifications for stage3

commit #3 from https://github.com/gentoo/prefix/pull/1
Comment 28 Jacob Floyd 2020-12-10 04:13:49 UTC
Created attachment 677530 [details, diff]
Bonus bootstrap-prefix.sh cleanups

Commit #4 from https://github.com/gentoo/prefix/pull/1
Comment 29 Jacob Floyd 2020-12-10 05:38:16 UTC
Comment on attachment 677524 [details, diff]
bootstrap-prefix.sh modifications for linker/compiler in stage2/3

Please see the PR on github. I missed a few changes, so I rebased and force pushed there.
Comment 30 Jacob Floyd 2020-12-10 05:38:33 UTC
Comment on attachment 677527 [details, diff]
bootstrap-prefix.sh modifications for stage3

Please see the PR on github. I missed a few changes, so I rebased and force pushed there.
Comment 31 Jacob Floyd 2020-12-10 05:38:46 UTC
Comment on attachment 677530 [details, diff]
Bonus bootstrap-prefix.sh cleanups

Please see the PR on github. I missed a few changes, so I rebased and force pushed there.
Comment 32 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2020-12-10 12:08:17 UTC
I'll start a build off now, but last I heard from Jacob, this got to stage3, successfully builds Clang, and falls over on missing dsymutil (bug 631862).

I'll post here the result & try look at how to get dsymutil. Leaving grobian to review / merge the PR when he's ready because of how much it touches and I'm still early days with Prefix.
Comment 33 Jacob Floyd 2020-12-18 21:36:13 UTC
Created attachment 678760 [details, diff]
patch for sys-devel/binutils-apple/binutils-apple-11.3.1.ebuild

Updated binutils-apple patch to be formatted with git-format-patch.
Comment 34 Jacob Floyd 2020-12-19 02:08:28 UTC
This one covers libcxx* and clang changes: https://github.com/gentoo/gentoo/pull/18720

ie these attachments are covered by this PR:
- attachment 677509 [details, diff]
- attachment 677512 [details, diff]
- attachment 676363 [details, diff]
- attachment 677515 [details, diff]

I went ahead and adjusted all 11+ ebuilds there so that the fixes hopefully get carried forward without extra effort from prefix folks.
Comment 35 Jacob Floyd 2020-12-19 05:23:05 UTC
In https://github.com/gentoo/gentoo/pull/18720 I also:

Keyworded sys-libs/llvm-libunwind, and fixed sys-libs/compiler-rt and sys-libs/compiler-rt-sanitizers.

The compiler-rt* changes include adjusting the darwin-specific cmakeargs in the ebuild, and adding a prefix-paths patch.

The last package to fix for clang-based bootstrap is sys-libs/tapi. I plan to update the ebuild+patch for that either this weekend or sometime next week.
Comment 36 Jacob Floyd 2020-12-19 05:24:46 UTC
Comment on attachment 676363 [details, diff]
patch for sys-devel/clang/clang-11.0.0.ebuild

Patch obsoleted by https://github.com/gentoo/gentoo/pull/18720
Comment 37 Jacob Floyd 2020-12-19 05:25:01 UTC
Comment on attachment 677509 [details, diff]
patch for sys-libs/libcxxabi/libcxxabi-11.0.0.ebuild

Patch obsoleted by https://github.com/gentoo/gentoo/pull/18720
Comment 38 Jacob Floyd 2020-12-19 05:25:22 UTC
Comment on attachment 677512 [details, diff]
patch for sys-libs/libcxx/libcxx-11.0.0.ebuild

Patch obsoleted by https://github.com/gentoo/gentoo/pull/18720
Comment 39 Jacob Floyd 2020-12-19 05:25:33 UTC
Comment on attachment 677515 [details, diff]
sys-devel/clang/files/11.0.0/prefix-dirs.patch

Patch obsoleted by https://github.com/gentoo/gentoo/pull/18720
Comment 40 Jacob Floyd 2020-12-19 05:26:30 UTC
Comment on attachment 678760 [details, diff]
patch for sys-devel/binutils-apple/binutils-apple-11.3.1.ebuild

Patch is the same as: https://github.com/gentoo/gentoo/pull/18713
Comment 41 Larry the Git Cow gentoo-dev 2020-12-19 19:07:42 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=80f6d04c612d5bd82d6cb0aca530c6f68addf7b6

commit 80f6d04c612d5bd82d6cb0aca530c6f68addf7b6
Author:     Jacob Floyd <cognifloyd@gmail.com>
AuthorDate: 2020-12-18 21:06:17 +0000
Commit:     Fabian Groffen <grobian@gentoo.org>
CommitDate: 2020-12-19 19:07:39 +0000

    sys-devel/binutils-apple-11.3.1: fix compilation on newer macOS
    
    In the version of private header (dyld_priv.h) copied from DYLD sources,
    It uses TARGET_OS_BRIDGE which is not defined in the latest MacOSX.sdk.
    We don't care about BridgeOS, so we just disable that.
    
    This only hits during stage3 and later once we've compiled our own
    clang so that clang starts injecting -Werror,-Wundef-prefix=TARGET_OS_
    (Apple must have that disabled in their version of clang).
    
    Bug: https://bugs.gentoo.org/758167
    Signed-off-by: Jacob Floyd <cognifloyd@gmail.com>
    Signed-off-by: Fabian Groffen <grobian@gentoo.org>

 sys-devel/binutils-apple/binutils-apple-11.3.1.ebuild | 4 ++++
 1 file changed, 4 insertions(+)
Comment 42 Larry the Git Cow gentoo-dev 2020-12-27 09:50:51 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=597a22dec78d405170e09ec9f971d5146e0bfadf

commit 597a22dec78d405170e09ec9f971d5146e0bfadf
Author:     Jacob Floyd <cognifloyd@gmail.com>
AuthorDate: 2020-12-20 22:03:21 +0000
Commit:     Fabian Groffen <grobian@gentoo.org>
CommitDate: 2020-12-27 09:49:33 +0000

    sys-libs/compiler-rt-sanitizers: Fix Darwin prefix paths
    
    Gentoo Prefix does not follow standard Apple practice of using --sysroot
    or --isysroot on everything because we have to account for two "root"s.
    1) EPREFIX is "root"
    2) EPREFIX/MacOSX.sdk is also sysroot as it provides system headers.
    
    So, adjust sys-libs/compiler-rt-sanitizers to prevent them from adding
    the sysroot flags on Darwin.
    
    Also adjust some CMAKE args to ensure it is using EPREFIX/MacOSX.sdk
    instead of looking things up with xcrun.
    
    Bug: https://bugs.gentoo.org/758167
    Signed-off-by: Jacob Floyd <cognifloyd@gmail.com>
    Signed-off-by: Fabian Groffen <grobian@gentoo.org>

 .../compiler-rt-sanitizers-11.0.0.ebuild           | 15 +++-
 .../compiler-rt-sanitizers-11.0.1.9999.ebuild      | 15 +++-
 .../compiler-rt-sanitizers-11.0.1_rc1.ebuild       | 15 +++-
 .../compiler-rt-sanitizers-11.0.1_rc2.ebuild       | 15 +++-
 .../compiler-rt-sanitizers-12.0.0.9999.ebuild      | 15 +++-
 .../files/9999/compiler-rt-prefix-paths.patch      | 79 ++++++++++++++++++++++
 6 files changed, 144 insertions(+), 10 deletions(-)

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3abc427bfdc80cc1f640f70bf3ed18d07a57941a

commit 3abc427bfdc80cc1f640f70bf3ed18d07a57941a
Author:     Jacob Floyd <cognifloyd@gmail.com>
AuthorDate: 2020-12-20 22:01:50 +0000
Commit:     Fabian Groffen <grobian@gentoo.org>
CommitDate: 2020-12-27 09:49:32 +0000

    sys-libs/compiler-rt: Fix Darwin prefix paths
    
    Gentoo Prefix does not follow standard Apple practice of using --sysroot
    or --isysroot on everything because we have to account for two "root"s.
    1) EPREFIX is "root"
    2) EPREFIX/MacOSX.sdk is also sysroot as it provides system headers.
    
    So, adjust sys-libs/compiler-rt to prevent them from adding the sysroot
    flags on Darwin.
    
    Also adjust some CMAKE args to ensure it is using EPREFIX/MacOSX.sdk
    instead of looking things up with xcrun.
    
    Bug: https://bugs.gentoo.org/758167
    Signed-off-by: Jacob Floyd <cognifloyd@gmail.com>
    Signed-off-by: Fabian Groffen <grobian@gentoo.org>

 sys-libs/compiler-rt/compiler-rt-11.0.0.ebuild     | 14 +++-
 .../compiler-rt/compiler-rt-11.0.1.9999.ebuild     | 14 +++-
 sys-libs/compiler-rt/compiler-rt-11.0.1_rc1.ebuild | 14 +++-
 sys-libs/compiler-rt/compiler-rt-11.0.1_rc2.ebuild | 14 +++-
 .../compiler-rt/compiler-rt-12.0.0.9999.ebuild     | 14 +++-
 .../files/9999/compiler-rt-prefix-paths.patch      | 79 ++++++++++++++++++++++
 6 files changed, 139 insertions(+), 10 deletions(-)

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=802f4331e8171bf3d2521f40d855d23bd7dd0db8

commit 802f4331e8171bf3d2521f40d855d23bd7dd0db8
Author:     Jacob Floyd <cognifloyd@gmail.com>
AuthorDate: 2020-12-19 03:23:12 +0000
Commit:     Fabian Groffen <grobian@gentoo.org>
CommitDate: 2020-12-27 09:49:32 +0000

    sys-libs/llvm-libunwind: keyword for ~x64-macos
    
    Bug: https://bugs.gentoo.org/758167
    Signed-off-by: Jacob Floyd <cognifloyd@gmail.com>
    Signed-off-by: Fabian Groffen <grobian@gentoo.org>

 sys-libs/llvm-libunwind/llvm-libunwind-11.0.0.ebuild | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1b2b62e093d789f6b1a4609c866581991e287b88

commit 1b2b62e093d789f6b1a4609c866581991e287b88
Author:     Jacob Floyd <cognifloyd@gmail.com>
AuthorDate: 2020-12-19 00:53:24 +0000
Commit:     Fabian Groffen <grobian@gentoo.org>
CommitDate: 2020-12-27 09:49:32 +0000

    sys-devel/clang: fix bootstrap on darwin prefix
    
    Adjust the clang internal header/framework search paths when building on
    darwin prefix. We symlink the selected MacOSX.sdk to EPREFIX/MacOSX.sdk
    during bootstrap, so that is the correct place to get system headers,
    such as those for libc, or for system framework headers, that we do not
    replace in prefix.
    
    Bug: https://bugs.gentoo.org/758167
    Signed-off-by: Jacob Floyd <cognifloyd@gmail.com>
    Signed-off-by: Fabian Groffen <grobian@gentoo.org>

 sys-devel/clang/clang-11.0.0.ebuild          | 13 ++++-
 sys-devel/clang/clang-11.0.1.9999.ebuild     | 11 +++-
 sys-devel/clang/clang-11.0.1_rc1.ebuild      | 11 +++-
 sys-devel/clang/clang-11.0.1_rc2.ebuild      | 11 +++-
 sys-devel/clang/clang-12.0.0.9999.ebuild     | 11 +++-
 sys-devel/clang/files/9999/prefix-dirs.patch | 75 ++++++++++++++++++++++++++++
 6 files changed, 126 insertions(+), 6 deletions(-)

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=74c82761ee2b2145fc03019edb187869f6856a38

commit 74c82761ee2b2145fc03019edb187869f6856a38
Author:     Jacob Floyd <cognifloyd@gmail.com>
AuthorDate: 2020-12-20 21:46:30 +0000
Commit:     Fabian Groffen <grobian@gentoo.org>
CommitDate: 2020-12-27 09:49:32 +0000

    sys-libs/libcxx: fix prefix bootstrap
    
    When bootstrapping prefix on darwin, libcxx must be installed before
    llvm is built during stage2 (in EPREFIX/tmp) and during stage3 (in
    EPREFIX). llvm_pkg_setup, however, identifies the *installed* llvm to
    set environment variables with the correct path to llvm. Since llvm is
    not installed, we have to skip that step. But during bootstrap, we don't
    need those environment vars to be modified anyway because
    bootstrap-prefix.sh already sets them with the paths to the correct llvm
    (which is the host's llm during stage2 and the EPREFIX/tmp llvm during
    stage3).
    
    Once stage3 is complete, llvm is installed in EPREFIX, so the system
    rebuild (with `emerge -e system`) will successfully use llvm_pkg_setup.
    bootstrap-prefix.sh is no longer controlling the vars at that point, so
    it is important to allow llvm_pkg_setup to correctly modify the vars.
    
    Other required fixes include:
    - eprefrixify some dylib paths in CMakeLists.txt (dylib is only used
      on darwin, so this is not an issue when compiling on other platforms).
    - ensure want_gcc_s is OFF even if use=-libunwind on darwin
    - keyword with ~x64-macos
    
    Bug: https://bugs.gentoo.org/758167
    Signed-off-by: Jacob Floyd <cognifloyd@gmail.com>
    Signed-off-by: Fabian Groffen <grobian@gentoo.org>

 profiles/prefix/darwin/macos/package.use.force |  4 ++++
 sys-libs/libcxx/libcxx-11.0.0.ebuild           | 27 ++++++++++++++++++++++----
 sys-libs/libcxx/libcxx-11.0.1.9999.ebuild      | 25 +++++++++++++++++++++---
 sys-libs/libcxx/libcxx-11.0.1_rc1.ebuild       | 25 +++++++++++++++++++++---
 sys-libs/libcxx/libcxx-11.0.1_rc2.ebuild       | 25 +++++++++++++++++++++---
 sys-libs/libcxx/libcxx-12.0.0.9999.ebuild      | 25 +++++++++++++++++++++---
 6 files changed, 115 insertions(+), 16 deletions(-)

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a4b70b6b132e2c1f16abe441effa7da73382a94a

commit a4b70b6b132e2c1f16abe441effa7da73382a94a
Author:     Jacob Floyd <cognifloyd@gmail.com>
AuthorDate: 2020-12-20 21:24:14 +0000
Commit:     Fabian Groffen <grobian@gentoo.org>
CommitDate: 2020-12-27 09:49:31 +0000

    sys-libs/libcxxabi: fix prefix bootstrap
    
    When bootstrapping prefix on darwin, libcxxabi must be installed before
    llvm is built during stage2 (in EPREFIX/tmp) and during stage3 (in
    EPREFIX). llvm_pkg_setup, however, identifies the *installed* llvm to
    set environment variables with the correct path to llvm. Since llvm is
    not installed, we have to skip that step. But during bootstrap, we don't
    need those environment vars to be modified anyway because
    bootstrap-prefix.sh already sets them with the paths to the correct llvm
    (which is the host's llm during stage2 and the EPREFIX/tmp llvm during
    stage3).
    
    Once stage3 is complete, llvm is installed in EPREFIX, so the system
    rebuild (with `emerge -e system`) will successfully use llvm_pkg_setup.
    bootstrap-prefix.sh is no longer controlling the vars at that point, so
    it is important to allow llvm_pkg_setup to correctly modify the vars.
    
    This also keywords the ebuild with ~x64-macos.
    
    Bug: https://bugs.gentoo.org/758167
    Signed-off-by: Jacob Floyd <cognifloyd@gmail.com>
    Signed-off-by: Fabian Groffen <grobian@gentoo.org>

 sys-libs/libcxxabi/libcxxabi-11.0.0.ebuild      | 8 ++++++--
 sys-libs/libcxxabi/libcxxabi-11.0.1.9999.ebuild | 6 +++++-
 sys-libs/libcxxabi/libcxxabi-11.0.1_rc1.ebuild  | 6 +++++-
 sys-libs/libcxxabi/libcxxabi-11.0.1_rc2.ebuild  | 6 +++++-
 sys-libs/libcxxabi/libcxxabi-12.0.0.9999.ebuild | 6 +++++-
 5 files changed, 26 insertions(+), 6 deletions(-)
Comment 43 Fabian Groffen gentoo-dev 2020-12-27 09:54:34 UTC
let me know where we are with this bug now, please, I lost track
Comment 44 Larry the Git Cow gentoo-dev 2020-12-28 00:47:40 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=171fda3d7493b997af725b2cdbf968ab681dd123

commit 171fda3d7493b997af725b2cdbf968ab681dd123
Author:     Jacob Floyd <cognifloyd@gmail.com>
AuthorDate: 2020-12-28 00:42:55 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2020-12-28 00:47:37 +0000

    sys-devel/clang: fix EPREFIX usage for prefix-paths.patch
    
    prefix-paths.patch required a trailing / to ensure it was never an empty
    string, which followed how this cmake patch works:
    dev-util/cmake/files/cmake-3.14.0_rc3-prefix-dirs.patch
    
    When I switched from sed to eprefixify, I missed this expectation.
    This modifies the patch to use EPREFIX as is.
    
    Bug: https://bugs.gentoo.org/758167
    Signed-off-by: Jacob Floyd <cognifloyd@gmail.com>
    Closes: https://github.com/gentoo/gentoo/pull/18847
    Signed-off-by: Sam James <sam@gentoo.org>

 sys-devel/clang/files/9999/prefix-dirs.patch | 11 ++++-------
 1 file changed, 4 insertions(+), 7 deletions(-)
Comment 45 Jacob Floyd 2020-12-28 03:24:51 UTC
Most required ::gentoo changes are in-tree now (woohoo! thanks everyone).

The last required ::gentoo changes are:
- https://github.com/gentoo/gentoo/pull/18845 (part of bug 757513)
- update binutils-apple with the patches in bug 762095

Then, we need to update bootstrap-prefix.sh which is covered by:
https://github.com/gentoo/prefix/pull/1

In that PR, these are the commits:
- Fix bootstrapping cmake with clang on darwin
  => closes bug 757513
- Add bootstrap_libtapi to build binutils-apple
  => use host's libtapi untill after stage3
- Add gnuconfig to stage2 llvm deps
  => new minor dep for newer llvm ebuilds
- Bootstrap libcxx* without libunwind useflag
  => avoid having to build libunwind until after stage3
- Darwin clang: Build libcxx before llvm & clang
  => llvm & clang built w/ different libcxx causes crazy weird bugs
- Darwin Clang Bootstrap: Fixes for stage3
  => a few minor changes (python fix, llvm path, drop a hack)
- bootstrap-prefix: minor cleanup
  => For UX. Not strictly needed. Increases verbosity in a few places.
- Bootstrap with bash 5.1 instead of 5.1-rc3
  => Avoid using rc. Not strictly needed.
- Fix using newer gettext+bison
  => Fix gettext nls flag usage during bootstrap.
     without this, building bison after gettext fails.
- Move MacOSX.sdk setup to a function
  => We need the MacOSX.sdk as soon as possible in stage1.

(I dropped a few PR commits where I was adding ebuilds meant for ::gentoo)

This gets the bootstrap through the tail end of rebuilding @system
with emerge -e system. But, then it fails to build sys-libs/tapi.
So, I've been working on getting libtapi to build with llvm 11.
But, I ran into another issue with llvm-shim which I have finally
fixed in bug 762095 (after a partial fix with bug 631862).

I need to post my latest tapi ebuild and patches somewhere.
But, I don't have time to keep hacking on it, and I won't have time
for several months (at least). Hopefully someone else can get it
over the finish line.
Two alternatives to re-working that ebuild are:
- adjust the ebuild (or create an alternate package) that continues
  symlinking the host's libtapi into EPREFIX.
- Somehow use https://github.com/tpoechtrager/apple-libtapi - I have no idea
  if there will be any long term issues linking against this libtapi when
  building with a more vanilla (non-apple) llvm+clang.

My goal in updating libtapi was to stick as close as possible to upstream
llvm-project, and use unmodified apple sources (where necessary) retrieved
directly from opensource.apple.com. Sadly, the 2019 version of llvm used
to build apple's released libtapi seems to have a mix of changes from llvm
10 and 11, while excluding a few significant upstream llvm 10 and 11 changes.
So, I have been working on patches that migrate the apple sources to use
the modified llvm 10 and 11 APIs.

There are probably a variety of other places that need to explicitly
use either StringRef or std::string. That is probably the biggest change
required since llvm 11+ no longer implicitly converts from StringRef to
std::string.

There is also a change for llvm 10 where clang::InputKind::Language
moved to clang::Language. And another change that has the FileManager
methods return ErrorOr objects instead of null/error codes.

There are also a few other minor things using make_unique from std:: vs llvm::
Comment 46 Jacob Floyd 2020-12-28 03:47:43 UTC
I just uploaded my WIP libtapi changes:
https://github.com/cognifloyd/gentoo/tree/sys-libs-tapi-11

It's not a PR because it's incomplete. Hopefully someone else can pick this up and run with it.
Comment 47 Fabian Groffen gentoo-dev 2020-12-28 07:20:05 UTC
Just a quick update regarding tapi; I'm working on "tapilite".  I'm almost there to finish it, at least I got all the LLVM integration yanked -- the one and only purpose is to be sufficient for ld64's needs.  Perhaps this can be used during bootstrap at least.
Comment 48 Fabian Groffen gentoo-dev 2020-12-31 13:47:46 UTC
(In reply to Fabian Groffen from comment #47)
> Just a quick update regarding tapi; I'm working on "tapilite".  I'm almost
> there to finish it, at least I got all the LLVM integration yanked -- the
> one and only purpose is to be sufficient for ld64's needs.  Perhaps this can
> be used during bootstrap at least.

Update: tapilite is in use with 8.2.1-r101, and it seems to work fine on x86_64 Big Sur.
Comment 49 Larry the Git Cow gentoo-dev 2020-12-31 15:16:12 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=c4d7697f3e19dd3a788e212d1ca0cbc57f4b0693

commit c4d7697f3e19dd3a788e212d1ca0cbc57f4b0693
Author:     Jacob Floyd <cognifloyd@gmail.com>
AuthorDate: 2020-12-31 15:15:36 +0000
Commit:     Fabian Groffen <grobian@gentoo.org>
CommitDate: 2020-12-31 15:15:36 +0000

    scripts/bootstrap-prefix: add gnuconfig to stage2 llvm deps
    
    Newer llvm requires gnuconfig, so bootstrap it in stage2.
    
    Bug: https://bugs.gentoo.org/758167
    
    Signed-off-by: Jacob Floyd <cognifloyd@gmail.com>
    Signed-off-by: Fabian Groffen <grobian@gentoo.org>

 scripts/bootstrap-prefix.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Comment 50 Larry the Git Cow gentoo-dev 2020-12-31 17:50:56 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=f7735b2d87b2e510098235c1cadc00a62818ddf5

commit f7735b2d87b2e510098235c1cadc00a62818ddf5
Author:     Jacob Floyd <cognifloyd@gmail.com>
AuthorDate: 2020-12-31 17:49:04 +0000
Commit:     Fabian Groffen <grobian@gentoo.org>
CommitDate: 2020-12-31 17:49:04 +0000

    scripts/bootstrap-prefix: properly deal with libcxx with clang
    
    - libunwind is not available yet, and has more deps than we care to deal
      with, so just compile libcxx without libunwind in stage2 & stage3
    - 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.
    
    Bug: https://bugs.gentoo.org/758167
    Signed-off-by: Fabian Groffen <grobian@gentoo.org>

 scripts/bootstrap-prefix.sh | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)
Comment 51 Fabian Groffen gentoo-dev 2021-01-01 13:32:48 UTC
This gets stuck in stage3 (at least on arm64) with compiler_rt not providing what should be necessary (?) and/or llvm refusing to configure because it cannot find an atomics library.
Comment 52 Fabian Groffen gentoo-dev 2021-01-01 13:36:59 UTC
part of this perhaps is also because we try to install an older llvm (11) than the host uses (12), which may mean we're missing some things
Comment 53 Larry the Git Cow gentoo-dev 2021-01-03 14:37:55 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=26dca920b3f483627ddfff332aff7d4c5b47f6fd

commit 26dca920b3f483627ddfff332aff7d4c5b47f6fd
Author:     Jacob Floyd <cognifloyd@gmail.com>
AuthorDate: 2020-12-04 02:37:47 +0000
Commit:     Fabian Groffen <grobian@gentoo.org>
CommitDate: 2021-01-03 14:37:06 +0000

    scripts/bootstrap-prefix: Fix Python for stage3 on Darwin
    
    Patch stage1 bootstrapped python to disable _scproxy module (which is
    what the ebuild does), to avoid a backtrace when it tries to use the
    network.
    
    Bug: https://bugs.gentoo.org/758167
    
    Signed-off-by: Jacob Floyd <cognifloyd@gmail.com>
    Signed-off-by: Fabian Groffen <grobian@gentoo.org>

 scripts/bootstrap-prefix.sh | 8 ++++++++
 1 file changed, 8 insertions(+)