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.
Created attachment 676363 [details, diff] patch for sys-devel/clang/clang-11.0.0.ebuild
Created attachment 676366 [details, diff] patch for sys-libs/libcxxabi/libcxxabi-11.0.0.ebuild
Created attachment 676369 [details, diff] patch for sys-libs/libcxx/libcxx-11.0.0.ebuild
Created attachment 676375 [details, diff] bootstrap-prefix.sh modifications for linker/compiler in stage2
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.
Created attachment 676531 [details, diff] bootstrap-prefix.sh modifications for linker/compiler in stage2 fixed the patch so git can apply it
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).
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++?
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
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)
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)
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.
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
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.
perhaps stupid question, but does /Users/jafloyd/Gentoo/usr/lib/llvm/11/bin/../../../../lib/clang/11.0.0/include/stdio.h exist?
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'.
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?
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?
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.
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).
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
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?
Created attachment 677509 [details, diff] patch for sys-libs/libcxxabi/libcxxabi-11.0.0.ebuild
Created attachment 677512 [details, diff] patch for sys-libs/libcxx/libcxx-11.0.0.ebuild
Created attachment 677515 [details, diff] sys-devel/clang/files/11.0.0/prefix-dirs.patch
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
Created attachment 677527 [details, diff] bootstrap-prefix.sh modifications for stage3 commit #3 from https://github.com/gentoo/prefix/pull/1
Created attachment 677530 [details, diff] Bonus bootstrap-prefix.sh cleanups Commit #4 from https://github.com/gentoo/prefix/pull/1
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 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 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.
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.
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.
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.
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 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 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 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 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 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
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(+)
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(-)
let me know where we are with this bug now, please, I lost track
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(-)
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::
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.
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.
(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.
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(-)
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(-)
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.
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
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(+)
(In reply to Jacob Floyd from comment #12) > 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? The same was done on GNU/Linux hosts and resulted in a Gentoo Prefix closer to a vanilla Gentoo. That has less Prefix-specific hacks, and therefore became more robust and up-to-date. I have been think of it for macOS. The #gentoo-prefix IRC channel had a lot of discussions on this possibility when the Prefix standalone for Linux came out. But at that time I don't have a macOS in my workflow and did not pursue the path. > Those are the headers that are provided in the SDK that we keep having > issues locating. I believe by managing the libc of macOS[1] with portage, similar benefits could be embraced. 1. I find https://opensource.apple.com/source/Libc/
I understand Jacob is working on bootstrapping with clang/llvm. Maybe we could use what we have achieved (thanks Jacob!) to make a mixed clang and GCC system. As for now, GCC cannot process the Apple-specific obj-C extensions[1]. Unless clang/llvm is used as a complementary compiler on Prefix macOS, we cannot build GUI applications with Cocoa "native feel" (as opposed to resorting to X11) on macOS. For Gentoo in general, it is safe to mix GCC and clang. They produce compatible binaries[2]. Is it feasible to call clang instead of GCC for some GUI ebuilds on macOS, while still bootstrap and build the base system on top of GCC? 1. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90709 2. https://wiki.gentoo.org/wiki/Clang/Bootstrapping
Created attachment 868834 [details, diff] possibility to build clang with gcc (In reply to Benda Xu from comment #55) > I understand Jacob is working on bootstrapping with clang/llvm. Maybe we > could use what we have achieved (thanks Jacob!) to make a mixed clang and > GCC system. (Maybe off-topic) AFAIK, currently we build `clang` on MacOS against `libc++`, while prefix's g++ is built against `libstdc++`. It results in ABI differences, and will break libraries and packages. So we do not mix `clang` and `gcc` on Darwin prefixes. Is it the only problem? If so, probably we can build `sys-devel/clang` on Darwin prefixes against `libstdc++`, mix the compilers and make use of MacOS's frameworks, for example `veclib` on `numpy` inside of Prefix. I have test it on my M2 MacBook Air: - `sys-devel/llvm:16` builds well - `sys-devel/clang:16` can be built by `gcc` with the attached patch - IMO `sys-devel/clang:16`'s DirectoryWatcher could be enabled if I recompile it by itself - '${EPREFIX}/etc/clang/*' needs update (I will send my version below) some inconsistency I have noticed: - `clang` produces error: __float128 is not supported on this target and with the clang-in-prefix, I have re-compiled `ffmpeg`, `numpy`, `cmake` and some other pkgs, so far everything seems to work well :-) ``` # my cmake is now linked against stdc++ and CoreFoundation voyager@Triton /tmp $ otool -L /opt/gentoo/usr/bin/cmake /opt/gentoo/usr/bin/cmake: /opt/gentoo/usr/lib/libcurl.4.dylib (compatibility version 13.0.0, current version 13.0.0) /opt/gentoo/usr/lib/libjsoncpp.25.dylib (compatibility version 25.0.0, current version 25.0.0) /opt/gentoo/usr/lib/libarchive.13.dylib (compatibility version 21.0.0, current version 21.1.0) /opt/gentoo/usr/lib/librhash.1.dylib (compatibility version 0.0.0, current version 0.0.0) /opt/gentoo/usr/lib/libuv.1.dylib (compatibility version 2.0.0, current version 2.0.0) /opt/gentoo/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.13) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1971.0.0) @rpath/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.30.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.100.3) ``` I am willing to help if this approach is worth considering. Please inform me if any details are required :-)
Created attachment 868835 [details] contents of my clang-common files
We should probably go the other way and try to use libcxx for everything - ideally the system's one. GCC can, with sekrit options, be encouraged to do this. But let's see what comes of DarthGandalf's work (CC'd), he's been doing some stuff in the last few weeks wrt bootstrap and it's looking promising. Your idea seems reasonable though and we should definitely be having gcc/clang doing the same thing.
My current approach is to use libc++ and libc++abi and compiler-rt, but system's libc. I got stage3 working, via many hacks in the process, and hand-editing stuff which broke. Currently I'm trying to streamline/cleanup this a bit, but there are random issues appearing which might suggest that I'm doing something wrong. I hope try to get *something* useful this week, we'll see.
Created attachment 869498 [details, diff] bootstap-prefix.patch draft
Created attachment 869500 [details, diff] draft of combined patch to portage tree
I attached 2 patches. This makes it work from the beginning till almost end of the 'emerge -e system' after stage3. stage3's perl (or perhaps one of perl libraries) is miscompiled somehow, causing "dyld: missing symbol called" error while running a perl script while building curl.
sorry but your patches are dirty containing local paths and assumptions that clang toolchain is in use, you'll have to clean that up, and possibly break it down in pieces so it can be reviewed and accepted
The intention was just to show it rather than present it for merging at this point, I think. But yeah, agreed of course
Yes, obviously. I even put "draft" to their descriptions. Until this perl issue is solved, it's not ready to merge anyway. And some of the packages shown in the tree patch needs to be revbumped, etc. This is totally not ready to merge as is.
(In reply to Alexey from comment #62) > I attached 2 patches. This makes it work from the beginning till almost end > of the 'emerge -e system' after stage3. stage3's perl (or perhaps one of > perl libraries) is miscompiled somehow, causing "dyld: missing symbol > called" error while running a perl script while building curl. Hi, I have tried your patch, have went through stage1 and stage2, and encountered the same `dyld[19065]: missing symbol called` problem. but after I re-emerged: 1. sys-libs/libcxxabi: because stage3’s libcxxabi is linked to `/usr/lib/libc++abi.dylib` 2. dev-lang/perl `curl` was emerged normally. Unfortunately, I forgot to preserve the fail-to-emerge log… (but I saved my prefix’s stage2, so I can re-do my stage3 if needed) Anyways, now I have went through the `emerge -e world` process and got a probably working darwin-clang prefix!!
Created attachment 869577 [details, diff] my additional patch to the portage tree FYI, I also attached my additional patch to portage tree. I also find that: - sys-libs/zlib: will not compile shared lib. This is because `-Wl,--undefined-version` will cause clang return non-zero. I patched out the corresponding line in zlib’s ebuild to workaround. But maybe we also need to find out what exactly happens. - sys-devel/llvm: 1. still links to some libs in ${EPREFIX}/tmp/usr/lib/ even after re-emerge the world 2. loves `/opt/lumiere/MacOSX.sdk/usr/lib/libcurses.tbd` so I have to patch it out. Maybe I have mess up something, but I think we are reaching the goal ;)
> sys-libs/libcxxabi: because stage3’s libcxxabi is linked to `/usr/lib/libc++abi.dylib` You're right, thanks. That must be because I put -lc++abi to /etc/clang, and it's used even when building sys-libs/libcxxabi itself. > This is because `-Wl,--undefined-version` Yes, I added such workaround to several ebuilds (seen in my draft patch), but for some reason sys-libs/zlib didn't fail for me. Just darwin's linker doesn't support such flag. > sys-devel/llvm still links to some libs in ${EPREFIX}/tmp/usr/lib/ even after re-emerge the world Any details? My guess is that need to rebuild llvm and friends in stage3 itself, but... re-emergeing the world should take care of that. > loves `/opt/lumiere/MacOSX.sdk/usr/lib/libcurses.tbd` so I have to patch it out You haven't attached the 16-no-system-curses.patch mentioned in your patch
> You haven't attached the 16-no-system-curses.patch mentioned in your patch nvm, bugzilla was showing wrong diff in its fancy diff UI, I see it in the raw version of the patch
(In reply to Alexey from comment #68) > Any details? > > My guess is that need to rebuild llvm and friends in stage3 itself, but... > re-emergeing the world should take care of that. I have checked my ${EPREFIX}/var/log/emerge.log. It turns out during the `emerge -v -e system`, `sys-devel/llvm` was not re-emerged. I suppose the reason should be: `sys-devel/binutils-apple` is `llvm`'s dependency, but it is masked. IMO we do not really need it. `llvm` provides equivalents of it.
Created attachment 870074 [details, diff] draft of combined patch to portage tree
Created attachment 870075 [details, diff] draft of patch to bootstrap-prefix.sh
The new patches should work end to end. Next steps are to clean them up: * split to reasonable patches, e.g. by package / by feature * redo some hacks in a nicer way * add/fix checks which toolchain is in use * better commit messages * remove things which I added while trying to make it work, but which not actually needed * etc
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=71b917e9f7a969a319d49ae34be09550f2530139 commit 71b917e9f7a969a319d49ae34be09550f2530139 Author: Alexey Sokolov <alexey+gentoo@asokolov.org> AuthorDate: 2023-09-11 22:56:18 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-09-11 23:33:12 +0000 eclass/toolchain-funcs.eclass: add missing functions Copied straight from ::gentoo's version of this file Bug: https://bugs.gentoo.org/758167 Signed-off-by: Alexey Sokolov <alexey+gentoo@asokolov.org> Closes: https://github.com/gentoo/prefix/pull/32 Signed-off-by: Sam James <sam@gentoo.org> eclass/toolchain-funcs.eclass | 64 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 64 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1c0c43c0df861757022829fe368b757bfda9cdf4 commit 1c0c43c0df861757022829fe368b757bfda9cdf4 Author: Alexey Sokolov <alexey+gentoo@asokolov.org> AuthorDate: 2023-09-10 22:19:01 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2023-09-12 06:18:26 +0000 sys-apps/darwin-miscutils: fix build with clang Bug: https://bugs.gentoo.org/758167 Signed-off-by: Alexey Sokolov <alexey+gentoo@asokolov.org> Signed-off-by: Fabian Groffen <grobian@gentoo.org> sys-apps/darwin-miscutils/darwin-miscutils-12.ebuild | 1 + .../files/darwin-miscutils-12-md-register.patch | 14 ++++++++++++++ 2 files changed, 15 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8e62f993267124f495956bffb2dcdc00c9f8ece5 commit 8e62f993267124f495956bffb2dcdc00c9f8ece5 Author: Alexey Sokolov <alexey+gentoo@asokolov.org> AuthorDate: 2023-09-23 09:00:52 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2023-09-27 09:12:32 +0000 sys-devel/llvm: fix build in Darwin Prefix Bug: https://bugs.gentoo.org/758167 Signed-off-by: Alexey Sokolov <alexey+gentoo@asokolov.org> Closes: https://github.com/gentoo/gentoo/pull/32730 Signed-off-by: Michał Górny <mgorny@gentoo.org> sys-devel/llvm/llvm-16.0.6.ebuild | 7 +++++++ sys-devel/llvm/llvm-17.0.0_rc4.ebuild | 7 +++++++ sys-devel/llvm/llvm-17.0.1.9999.ebuild | 7 +++++++ sys-devel/llvm/llvm-17.0.1.ebuild | 7 +++++++ sys-devel/llvm/llvm-18.0.0.9999.ebuild | 7 +++++++ sys-devel/llvm/llvm-18.0.0_pre20230906.ebuild | 7 +++++++ 6 files changed, 42 insertions(+) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=59d389e33aef580b4d5ae2aa9acde86dc0081042 commit 59d389e33aef580b4d5ae2aa9acde86dc0081042 Author: Alexey Sokolov <alexey+gentoo@asokolov.org> AuthorDate: 2023-09-15 07:29:55 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2023-09-27 09:12:32 +0000 llvm.eclass: add option to skip llvm_pkg_setup To be used during prefix bootstrap using LLVM toolchain. Without this, several LLVM packages don't build. Bug: https://bugs.gentoo.org/758167 Signed-off-by: Alexey Sokolov <alexey+gentoo@asokolov.org> Signed-off-by: Michał Górny <mgorny@gentoo.org> eclass/llvm.eclass | 11 +++++++++++ 1 file changed, 11 insertions(+)
Created attachment 874610 [details, diff] draft of combined patch to portage tree
Created attachment 881438 [details, diff] draft of combined patch to portage tree
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=12dbee9e68afd185da7cea260722d70710d14315 commit 12dbee9e68afd185da7cea260722d70710d14315 Author: Alexey Sokolov <alexey+gentoo@asokolov.org> AuthorDate: 2024-01-27 00:09:22 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-01-28 08:55:38 +0000 sys-libs/llvm-libunwind: keyword ~arm64-macos Bug: https://bugs.gentoo.org/758167 Signed-off-by: Alexey Sokolov <alexey+gentoo@asokolov.org> Closes: https://github.com/gentoo/gentoo/pull/35031 Signed-off-by: Sam James <sam@gentoo.org> sys-libs/llvm-libunwind/llvm-libunwind-16.0.6-r1.ebuild | 4 ++-- sys-libs/llvm-libunwind/llvm-libunwind-17.0.6.ebuild | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8493d856a4537767bce88402b71bae2e89740837 commit 8493d856a4537767bce88402b71bae2e89740837 Author: Alexey Sokolov <alexey+gentoo@asokolov.org> AuthorDate: 2024-01-27 00:06:08 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-01-28 08:55:38 +0000 sys-libs/binutils-libs: keyword 2.41-r5 for ~arm64-macos Bug: https://bugs.gentoo.org/758167 Signed-off-by: Alexey Sokolov <alexey+gentoo@asokolov.org> Signed-off-by: Sam James <sam@gentoo.org> sys-libs/binutils-libs/binutils-libs-2.41-r5.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ef579f90f75b3404ea6f371cc7cb7dbc8a364142 commit ef579f90f75b3404ea6f371cc7cb7dbc8a364142 Author: Alexey Sokolov <alexey+gentoo@asokolov.org> AuthorDate: 2024-01-27 00:05:46 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-01-28 08:55:38 +0000 sys-libs/compiler-rt: keyword ~arm64-macos Bug: https://bugs.gentoo.org/758167 Signed-off-by: Alexey Sokolov <alexey+gentoo@asokolov.org> Signed-off-by: Sam James <sam@gentoo.org> sys-libs/compiler-rt/compiler-rt-16.0.6-r4.ebuild | 2 +- sys-libs/compiler-rt/compiler-rt-16.0.6.ebuild | 2 +- sys-libs/compiler-rt/compiler-rt-17.0.6.ebuild | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6ecad4bb214700c473eb0446e647e969aa121d45 commit 6ecad4bb214700c473eb0446e647e969aa121d45 Author: Alexey Sokolov <alexey+gentoo@asokolov.org> AuthorDate: 2024-01-27 00:05:24 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-01-28 08:55:38 +0000 sys-libs/libcxxabi: keyword ~arm64-macos Bug: https://bugs.gentoo.org/758167 Signed-off-by: Alexey Sokolov <alexey+gentoo@asokolov.org> Signed-off-by: Sam James <sam@gentoo.org> sys-libs/libcxxabi/libcxxabi-16.0.6.ebuild | 4 ++-- sys-libs/libcxxabi/libcxxabi-17.0.6.ebuild | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e4f745bd5c2062ebd83fc39050b5c5b6a9636197 commit e4f745bd5c2062ebd83fc39050b5c5b6a9636197 Author: Alexey Sokolov <alexey+gentoo@asokolov.org> AuthorDate: 2024-01-27 00:04:54 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-01-28 08:55:37 +0000 sys-devel/llvm-toolchain-symlinks: keyword ~arm64-macos Bug: https://bugs.gentoo.org/758167 Signed-off-by: Alexey Sokolov <alexey+gentoo@asokolov.org> Signed-off-by: Sam James <sam@gentoo.org> .../llvm-toolchain-symlinks/llvm-toolchain-symlinks-16-r1.ebuild | 4 ++-- sys-devel/llvm-toolchain-symlinks/llvm-toolchain-symlinks-17.ebuild | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d2a7921ce75cd832f21d3a5301a185470b8d3948 commit d2a7921ce75cd832f21d3a5301a185470b8d3948 Author: Alexey Sokolov <alexey+gentoo@asokolov.org> AuthorDate: 2024-01-27 00:04:40 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-01-28 08:55:37 +0000 sys-devel/lld-toolchain-symlinks: keyword ~arm64-macos Bug: https://bugs.gentoo.org/758167 Signed-off-by: Alexey Sokolov <alexey+gentoo@asokolov.org> Signed-off-by: Sam James <sam@gentoo.org> sys-devel/lld-toolchain-symlinks/lld-toolchain-symlinks-16-r2.ebuild | 4 ++-- sys-devel/lld-toolchain-symlinks/lld-toolchain-symlinks-17.ebuild | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b64e6494b6060533896d10c58784abe9c59417c3 commit b64e6494b6060533896d10c58784abe9c59417c3 Author: Alexey Sokolov <alexey+gentoo@asokolov.org> AuthorDate: 2024-01-27 00:04:27 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-01-28 08:55:37 +0000 sys-devel/clang-toolchain-symlinks: keyword ~arm64-macos Bug: https://bugs.gentoo.org/758167 Signed-off-by: Alexey Sokolov <alexey+gentoo@asokolov.org> Signed-off-by: Sam James <sam@gentoo.org> .../clang-toolchain-symlinks/clang-toolchain-symlinks-16-r2.ebuild | 4 ++-- sys-devel/clang-toolchain-symlinks/clang-toolchain-symlinks-17.ebuild | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=007965a908d3181efef3862cb561d526a1967307 commit 007965a908d3181efef3862cb561d526a1967307 Author: Alexey Sokolov <alexey+gentoo@asokolov.org> AuthorDate: 2024-01-27 00:04:13 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-01-28 08:55:37 +0000 sys-devel/lld: keyword ~arm64-macos Bug: https://bugs.gentoo.org/758167 Signed-off-by: Alexey Sokolov <alexey+gentoo@asokolov.org> Signed-off-by: Sam James <sam@gentoo.org> sys-devel/lld/lld-16.0.6.ebuild | 2 +- sys-devel/lld/lld-17.0.6.ebuild | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=527df027c6924ab1fc1fb6709f38d144cb999b34 commit 527df027c6924ab1fc1fb6709f38d144cb999b34 Author: Alexey Sokolov <alexey+gentoo@asokolov.org> AuthorDate: 2024-01-27 00:03:53 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-01-28 08:55:36 +0000 sys-devel/clang: keyword ~arm64-macos Bug: https://bugs.gentoo.org/758167 Signed-off-by: Alexey Sokolov <alexey+gentoo@asokolov.org> Signed-off-by: Sam James <sam@gentoo.org> sys-devel/clang/clang-16.0.6.ebuild | 2 +- sys-devel/clang/clang-17.0.6.ebuild | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a93a35fe74394712bb4c592b5a01dca828edabd0 commit a93a35fe74394712bb4c592b5a01dca828edabd0 Author: Alexey Sokolov <alexey+gentoo@asokolov.org> AuthorDate: 2024-01-27 00:03:20 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-01-28 08:55:36 +0000 sys-devel/llvm-common: keyword ~arm64-macos Bug: https://bugs.gentoo.org/758167 Signed-off-by: Alexey Sokolov <alexey+gentoo@asokolov.org> Signed-off-by: Sam James <sam@gentoo.org> sys-devel/llvm-common/llvm-common-16.0.6.ebuild | 4 ++-- sys-devel/llvm-common/llvm-common-17.0.6.ebuild | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6a3903d271f12f46c3bafcef4021fa1bfb16c7a6 commit 6a3903d271f12f46c3bafcef4021fa1bfb16c7a6 Author: Alexey Sokolov <alexey+gentoo@asokolov.org> AuthorDate: 2024-01-27 00:02:07 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-01-28 08:55:36 +0000 sys-devel/llvm: support llvm prefix on mac Stop depending on sys-devel/binutils-apple which is required only when building with gcc, but conflicts when using clang Bug: https://bugs.gentoo.org/758167 Signed-off-by: Alexey Sokolov <alexey+gentoo@asokolov.org> Signed-off-by: Sam James <sam@gentoo.org> sys-devel/llvm/llvm-16.0.6.ebuild | 3 +-- sys-devel/llvm/llvm-17.0.6.ebuild | 3 +-- sys-devel/llvm/llvm-18.0.0.9999.ebuild | 1 - sys-devel/llvm/llvm-18.0.0_pre20240106.ebuild | 1 - sys-devel/llvm/llvm-18.0.0_pre20240113.ebuild | 1 - sys-devel/llvm/llvm-18.0.0_pre20240120.ebuild | 1 - sys-devel/llvm/llvm-19.0.0.9999.ebuild | 1 - 7 files changed, 2 insertions(+), 9 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=334aa419406fda2da409e35acba326cc325f2f2a commit 334aa419406fda2da409e35acba326cc325f2f2a Author: Alexey Sokolov <alexey+gentoo@asokolov.org> AuthorDate: 2024-01-26 23:59:37 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-01-28 08:55:36 +0000 sys-devel/clang-runtime: keyword ~arm64-macos Bug: https://bugs.gentoo.org/758167 Signed-off-by: Alexey Sokolov <alexey+gentoo@asokolov.org> Signed-off-by: Sam James <sam@gentoo.org> sys-devel/clang-runtime/clang-runtime-16.0.6.ebuild | 4 ++-- sys-devel/clang-runtime/clang-runtime-17.0.6.ebuild | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6d506cce2ed2543b881451f75ce3b898e2c996d8 commit 6d506cce2ed2543b881451f75ce3b898e2c996d8 Author: Alexey Sokolov <alexey+gentoo@asokolov.org> AuthorDate: 2024-01-26 23:55:43 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-01-28 08:55:35 +0000 sys-devel/clang-common: support llvm prefix on mac Bug: https://bugs.gentoo.org/758167 Signed-off-by: Alexey Sokolov <alexey+gentoo@asokolov.org> Signed-off-by: Sam James <sam@gentoo.org> .../clang-common/clang-common-16.0.6-r2.ebuild | 29 ++++++++++++++++++--- .../clang-common/clang-common-17.0.6-r1.ebuild | 30 ++++++++++++++++++++-- .../clang-common/clang-common-18.0.0.9999.ebuild | 30 ++++++++++++++++++++-- .../clang-common-18.0.0_pre20240106.ebuild | 30 ++++++++++++++++++++-- .../clang-common-18.0.0_pre20240113.ebuild | 30 ++++++++++++++++++++-- .../clang-common-18.0.0_pre20240120.ebuild | 30 ++++++++++++++++++++-- .../clang-common/clang-common-19.0.0.9999.ebuild | 30 ++++++++++++++++++++-- sys-devel/clang-common/metadata.xml | 1 + 8 files changed, 195 insertions(+), 15 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=abdf1346a5652dc0b57e2ed786425c3daa0b6707 commit abdf1346a5652dc0b57e2ed786425c3daa0b6707 Author: Alexey Sokolov <alexey+gentoo@asokolov.org> AuthorDate: 2024-01-27 09:46:01 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-02-02 21:32:32 +0000 profiles: add prefix llvm profile for macos Bug: https://bugs.gentoo.org/758167 Signed-off-by: Alexey Sokolov <alexey+gentoo@asokolov.org> Closes: https://github.com/gentoo/gentoo/pull/35042 Signed-off-by: Sam James <sam@gentoo.org> profiles/prefix/darwin/macos/14.0/arm64/clang/eapi | 1 + profiles/prefix/darwin/macos/14.0/arm64/clang/parent | 2 ++ profiles/prefix/darwin/macos/features/clang-lld/eapi | 1 + profiles/prefix/darwin/macos/features/clang-lld/make.defaults | 7 +++++++ profiles/prefix/darwin/macos/features/clang-lld/package.mask | 5 +++++ profiles/prefix/darwin/macos/features/clang-lld/packages | 4 ++++ profiles/prefix/darwin/macos/features/clang-lld/parent | 1 + 7 files changed, 21 insertions(+)
Created attachment 884642 [details, diff] draft of patch to bootstrap-prefix.sh
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2e71e53b88d541466774f1c3c35fb3c6bcb2d7ff commit 2e71e53b88d541466774f1c3c35fb3c6bcb2d7ff Author: Alexey Sokolov <alexey+gentoo@asokolov.org> AuthorDate: 2024-02-07 00:19:40 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-02-11 13:35:35 +0000 sys-libs/libcxx: add ~arm64-macos keyword Bug: https://bugs.gentoo.org/758167 Signed-off-by: Alexey Sokolov <alexey+gentoo@asokolov.org> Closes: https://github.com/gentoo/gentoo/pull/35249 Signed-off-by: Sam James <sam@gentoo.org> sys-libs/libcxx/libcxx-16.0.6.ebuild | 2 +- sys-libs/libcxx/libcxx-17.0.6.ebuild | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=dd927e4ede05c4b468fa778b8ddf83ae7e8ce297 commit dd927e4ede05c4b468fa778b8ddf83ae7e8ce297 Author: Alexey Sokolov <alexey+gentoo@asokolov.org> AuthorDate: 2024-02-07 00:17:37 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-02-11 13:35:35 +0000 sys-devel/clang-common: fixes for darwin Add keywords, remove unsupported linker option Bug: https://bugs.gentoo.org/758167 Signed-off-by: Alexey Sokolov <alexey+gentoo@asokolov.org> Signed-off-by: Sam James <sam@gentoo.org> sys-devel/clang-common/clang-common-16.0.6-r2.ebuild | 2 +- sys-devel/clang-common/clang-common-17.0.6-r1.ebuild | 19 +++++++++++++------ sys-devel/clang-common/clang-common-18.1.0_rc2.ebuild | 17 ++++++++++++----- .../clang-common/clang-common-19.0.0.9999.ebuild | 17 ++++++++++++----- .../clang-common-19.0.0_pre20240203.ebuild | 17 ++++++++++++----- .../clang-common-19.0.0_pre20240210.ebuild | 17 ++++++++++++----- 6 files changed, 62 insertions(+), 27 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d11dab92c84109dc9e7fed186e6ccd7dfcdde222 commit d11dab92c84109dc9e7fed186e6ccd7dfcdde222 Author: Alexey Sokolov <alexey+gentoo@asokolov.org> AuthorDate: 2024-02-10 14:31:00 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2024-02-17 10:28:14 +0000 profiles/prefix: reorder macos clang parents and override LDFLAGS This is alternative to https://github.com/gentoo/gentoo/pull/35250 Bug: https://bugs.gentoo.org/758167 Closes: https://github.com/gentoo/gentoo/pull/35260 Signed-off-by: Alexey Sokolov <alexey+gentoo@asokolov.org> Signed-off-by: Fabian Groffen <grobian@gentoo.org> profiles/prefix/darwin/macos/14.0/arm64/clang/parent | 2 +- profiles/prefix/darwin/macos/features/clang-lld/make.defaults | 5 +++++ 2 files changed, 6 insertions(+), 1 deletion(-)
