With llvm profile, the swift package still tries to use gcc to compile parts of the code which presumably leads to libstdc++ and libc++ mixing. Portage 3.0.67 (python 3.12.8-final-0, default/linux/amd64/23.0/desktop/plasma/systemd, gcc-14, glibc-2.40-r8, 6.12.11-gentoo-dist x86_64) ================================================================= System Settings ================================================================= System uname: Linux-6.12.11-gentoo-dist-x86_64-13th_Gen_Intel-R-_Core-TM-_i7-13700F-with-glibc2.40 KiB Mem: 65679604 total, 3881004 free KiB Swap: 0 total, 0 free Timestamp of repository gentoo: Sat, 01 Feb 2025 01:00:00 +0000 Head commit of repository gentoo: 5fbf8f2ad18312079251191c4dbd30b71a789adc Head commit of repository 2xsaiko: ff4b7295eebfab1c669083295d6337237049d875 Timestamp of repository cg: Wed, 29 Jan 2025 23:33:21 +0000 Head commit of repository cg: 464e09a73cf3723393e77f103c489c5fd79b991f Timestamp of repository guru: Thu, 30 Jan 2025 23:48:24 +0000 Head commit of repository guru: 7d11626679a194d9283aeacae7a4c7ed2ba0b046 Head commit of repository nix-guix: 0e18b2e7d1ebb0da1088fc931d6a8f0ff6730db9 Timestamp of repository steam-overlay: Wed, 29 Jan 2025 23:33:21 +0000 Head commit of repository steam-overlay: 215a03000825d2d3b300d99915d5b4288ee879fb sh bash 5.2_p37 ld GNU ld (Gentoo 2.43 p3) 2.43.1 app-misc/pax-utils: 1.3.8::gentoo app-shells/bash: 5.2_p37::gentoo dev-build/autoconf: 2.71-r7::gentoo, 2.72-r1::gentoo dev-build/automake: 1.17-r1::gentoo dev-build/cmake: 3.31.5::gentoo dev-build/libtool: 2.5.4::gentoo dev-build/make: 4.4.1-r100::gentoo dev-build/meson: 1.7.0::gentoo dev-java/java-config: 2.3.4::gentoo dev-lang/perl: 5.40.0-r1::gentoo dev-lang/python: 3.11.11_p1::gentoo, 3.12.8_p1::gentoo, 3.13.1_p1::gentoo, 3.13.1_p1-r100::gentoo dev-lang/rust: 1.84.0::gentoo llvm-core/clang: 18.1.8-r6::gentoo, 19.1.7::gentoo llvm-core/lld: 18.1.8::gentoo, 19.1.7::gentoo llvm-core/llvm: 18.1.8-r6::gentoo, 19.1.7::gentoo sys-apps/baselayout: 2.17::gentoo sys-apps/sandbox: 2.43::gentoo sys-apps/systemd: 257.2::gentoo sys-devel/binutils: 2.43-r2::gentoo sys-devel/binutils-config: 5.5.2::gentoo sys-devel/gcc: 14.2.1_p20241221::gentoo sys-devel/gcc-config: 2.12.1::gentoo sys-kernel/linux-headers: 6.12::gentoo (virtual/os-headers) sys-libs/glibc: 2.40-r8::gentoo Repositories: gentoo location: /var/db/repos/gentoo sync-type: rsync sync-uri: rsync://rsync.gentoo.org/gentoo-portage priority: -1000 volatile: False sync-rsync-verify-jobs: 1 sync-rsync-verify-metamanifest: yes sync-rsync-verify-max-age: 3 sync-rsync-extra-opts: 2xsaiko location: /var/db/repos/2xsaiko sync-type: git sync-uri: https://git.sr.ht/~dblsaiko/ebuilds masters: steam-overlay gentoo volatile: False cg location: /var/db/repos/cg sync-type: git sync-uri: https://github.com/gentoo-mirror/cg.git masters: gentoo volatile: False guru location: /var/db/repos/guru sync-type: git sync-uri: https://github.com/gentoo-mirror/guru.git masters: gentoo volatile: False local location: /var/db/repos/local masters: gentoo volatile: False nix-guix location: /var/db/repos/nix-guix sync-type: git sync-uri: https://github.com/trofi/nix-guix-gentoo masters: gentoo volatile: False nix-system-config location: /nix/store/22v5wviivba0iddkj1sa14fwk33l3ip5-gentoo/overlay masters: gentoo volatile: True steam-overlay location: /var/db/repos/steam-overlay sync-type: git sync-uri: https://github.com/gentoo-mirror/steam-overlay.git masters: gentoo volatile: False Binary Repositories: gentoobinhost priority: 1 sync-uri: https://mirror.leaseweb.com/gentoo/releases/amd64/binpackages/23.0/x86-64_llvm Installed sets: @thesis ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="@FREE linux-fw-redistributable" ADDR2LINE="llvm-addr2line" AR="llvm-ar" AS="clang -c" CBUILD="x86_64-pc-linux-gnu" CC="clang" CFLAGS="-O2 -pipe -march=native" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/lib64/libreoffice/program/sofficerc /usr/share/config /usr/share/gnupg/qualified.txt /var/bind" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/sandbox.d" CPP="clang-cpp" CXX="clang++" CXXFLAGS="-O2 -pipe -march=native" DISTDIR="/var/cache/distfiles" ENV_UNSET="CARGO_HOME DBUS_SESSION_BUS_ADDRESS DISPLAY GDK_PIXBUF_MODULE_FILE GOBIN GOPATH PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR XDG_STATE_HOME" FCFLAGS="-O2 -pipe -march=native" FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs binpkg-multi-instance buildpkg-live config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync merge-wait multilib-strict network-sandbox news parallel-fetch pid-sandbox pkgdir-index-trusted preserve-libs protect-owned qa-unresolved-soname-deps sandbox strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -pipe -march=native" GENTOO_MIRRORS="https://mirror.netcologne.de/gentoo/ https://mirror.netzwerge.de/gentoo/ https://ftp.fau.de/gentoo" LANG="C.UTF-8" LD="ld.lld" LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs -Wl,--as-needed" LEX="flex" NM="llvm-nm" OBJCOPY="llvm-objcopy" OBJDUMP="llvm-objdump" PKGDIR="/var/cache/binpkgs" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git" PORTAGE_TMPDIR="/var/tmp" RANLIB="llvm-ranlib" READELF="llvm-readelf" SHELL="/bin/zsh" STRINGS="llvm-strings" STRIP="llvm-strip" USE="X a52 aac acl acpi activities alsa amd64 bluetooth branding bzip2 cairo cdda cdr cet clang crypt cups dbus declarative dri dts dvd dvdr encode exif flac gdbm gif gpm gtk gui iconv icu ipv6 jpeg jpegxl kde kf6compat kwallet lcms libnotify libtirpc llvm-libunwind mad mng mp3 mp4 mpeg multilib ncurses nls ogg opengl openmp pam pango pcre pdf pipewire plasma png policykit ppds pulseaudio qml qt5 qt6 readline screencast sdl seccomp semantic-desktop sound spell ssl startup-notification svg systemd test-rust tiff truetype udev udisks unicode upower usb vorbis vulkan wayland webp widgets wxwidgets x264 xattr xcb xft xml xv xvid zlib" ABI_X86="64" ADA_TARGET="gcc_13" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_anon authn_dbm authn_file authz_dbm authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir env expires ext_filter file_cache filter headers include info log_config logio mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="aes avx avx2 f16c fma3 mmx mmxext pclmul popcnt rdrand sha sse sse2 sse3 sse4_1 sse4_2 ssse3 vpclmulqdq" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock greis isync itrax navcom oceanserver oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 tsip tripmate tnt ublox" GUILE_SINGLE_TARGET="3-0" GUILE_TARGETS="3-0" INPUT_DEVICES="libinput" KERNEL="linux" L10N="en en-US de de-DE" LCD_DEVICES="bayrad cfontz glk hd44780 lb216 lcdm001 mtxorb text" LUA_SINGLE_TARGET="lua5-1" LUA_TARGETS="lua5-1" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php8-2" POSTGRES_TARGETS="postgres16" PYTHON_SINGLE_TARGET="python3_12" PYTHON_TARGETS="python3_12" RUBY_TARGETS="ruby32" VIDEO_CARDS="amdgpu fbdev intel nouveau radeon radeonsi vesa dummy" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipp2p iface geoip fuzzy condition tarpit sysrq proto logmark ipmark dhcpmac delude chaos account" Unset: ARFLAGS, ASFLAGS, CCLD, CONFIG_SHELL, CPPFLAGS, CTARGET, CXXFILT, ELFEDIT, EMERGE_DEFAULT_OPTS, EXTRA_ECONF, F77FLAGS, FC, GCOV, GPROF, INSTALL_MASK, LC_ALL, LFLAGS, LIBTOOL, LINGUAS, MAKE, MAKEFLAGS, MAKEOPTS, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PYTHONPATH, RUSTFLAGS, SIZE, YACC, YFLAGS
Created attachment 918136 [details] build.log
Correction: there is no gcc involved. But it does try to use GNU ld for some reason. Since this appears to build its own LLVM, maybe the same defaults to make it use libc++, LLVM ld and so on have to be applied as in llvm-core/clang-common?
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/proj/guru.git/commit/?id=e725aa5030c89bec2b8883784d725568250d19b8 commit e725aa5030c89bec2b8883784d725568250d19b8 Author: Marco Rebhan <me@dblsaiko.net> AuthorDate: 2025-02-10 19:54:17 +0000 Commit: Marco Rebhan <me@dblsaiko.net> CommitDate: 2025-02-10 23:46:30 +0000 dev-lang/swift: Always use libstdc++ when building Swift 5 Closes: https://bugs.gentoo.org/949266 Signed-off-by: Marco Rebhan <me@dblsaiko.net> dev-lang/swift/swift-5.10.1-r3.ebuild | 9 +++++++++ 1 file changed, 9 insertions(+)
(In reply to Larry the Git Cow from comment #3) > The bug has been closed via the following commit(s): > > https://gitweb.gentoo.org/repo/proj/guru.git/commit/ > ?id=e725aa5030c89bec2b8883784d725568250d19b8 > Doesn't this mean no other CXXFLAGS are respected as CMAKE_CXX_FLAGS is now clobbered? (In reply to Marco Rebhan from comment #2) > Correction: there is no gcc involved. But it does try to use GNU ld for some > reason. > > Since this appears to build its own LLVM, maybe the same defaults to make it > use libc++, LLVM ld and so on have to be applied as in > llvm-core/clang-common? I think you're looking for toolchain-funcs.eclass' tc-get-cxx-stdlib.
(In reply to Sam James from comment #4) > Doesn't this mean no other CXXFLAGS are respected as CMAKE_CXX_FLAGS is now > clobbered? I'm pretty sure it didn't in the first place, but I was trying a lot of different stuff to get this to work. I'll try with just flag-o-matic's append-cxxflags again. > (In reply to Marco Rebhan from comment #2) > I think you're looking for toolchain-funcs.eclass' tc-get-cxx-stdlib. Oh nice, didn't know about that. Should I use that instead of having a use flag here? https://cgit.gentoo.org/repo/proj/guru.git/commit/?id=fbbd4a1e1131b02b02826edbac4932e1c83174ff
Marco, apologies for not getting a chance to resolve this when you first opened the issue; you got a fix out before I got a chance to respond. I'm currently looking to fix some other issues with the Swift build system — namely that CFLAGS and CXXFLAGS are not respected by the build system (https://bugs.gentoo.org/951202). As part of that, I'm looking to replace the USE flag you added here with properly setting CXXFLAGS (using flag-o-matic and toolchain-funcs, as Sam suggested), since they'll now get picked up. I'd like to confirm that my changes don't regress anything for the LLVM profile, to ensure you won't be affected, but in a clean Gentoo Docker image set to `default/linux/amd64/23.0/llvm`, I actually can't compile Swift 6.0.3 (with no changes) at all. I wanted to verify your setup to see if I can replicate it, since what I'm doing clearly isn't it. The title and your description mention the LLVM profile, but the `emerge --info` output below appears to list your profile as `default/linux/amd64/23.0/desktop/plasma/systemd`, which doesn't default to using LLVM. Can you share how your system is configured, so I can attempt to replicate it? (Alternatively, if you have the time to spare, I can send you a patch to test out; I just know that compiling Swift is time-consuming.)
(In reply to Itai Ferber from comment #6) > Marco, apologies for not getting a chance to resolve this when you first > opened the issue; you got a fix out before I got a chance to respond. > > I'm currently looking to fix some other issues with the Swift build system — > namely that CFLAGS and CXXFLAGS are not respected by the build system > (https://bugs.gentoo.org/951202). As part of that, I'm looking to replace > the USE flag you added here with properly setting CXXFLAGS (using > flag-o-matic and toolchain-funcs, as Sam suggested), since they'll now get > picked up. This would be great! > I'd like to confirm that my changes don't regress anything for the LLVM > profile, to ensure you won't be affected, but in a clean Gentoo Docker image > set to `default/linux/amd64/23.0/llvm`, I actually can't compile Swift 6.0.3 > (with no changes) at all. I wanted to verify your setup to see if I can > replicate it, since what I'm doing clearly isn't it. > > The title and your description mention the LLVM profile, but the `emerge > --info` output below appears to list your profile as > `default/linux/amd64/23.0/desktop/plasma/systemd`, which doesn't default to > using LLVM. Can you share how your system is configured, so I can attempt to > replicate it? > > (Alternatively, if you have the time to spare, I can send you a patch to > test out; I just know that compiling Swift is time-consuming.) Sure! It is a local profile combining the Plasma profile with LLVM's (see https://wiki.gentoo.org/wiki/Clang/Desktop_profile): > gentoo:default/linux/amd64/23.0/desktop/plasma/systemd > gentoo:features/llvm Additionally, I have LLVM 20 masked since libc++ 20 drops support for clang 17 which comes with Swift 6.0.2. That might be the problem you're hitting here. Alternatively I have encountered another crash while compiling swiftpm which didn't always happen (see /etc/portage/patches/dev-lang/swift:6/fix-build-crash.patch) Something else I've noticed is that compiling Swift 6.0.2 with itself fails (at least with my setup), I have not found a fix for that yet. It only builds using the swift-bootstrap package. I'll attach my /etc/portage and the local overlay I use for the profile, which is hopefully enough so you can test and hopefully reproduce. If you also want to send me a patch, I can test it. PS: it would be great to split the Swift package into its components (llvm, clang, swiftc etc.) so parts can be rebuilt without having to redo the whole thing every time, specifically to shorten the build time. I don't know nearly enough about this to do it myself though.
Created attachment 920820 [details] Portage configuration
> Sure! It is a local profile combining the Plasma profile with LLVM's (see > https://wiki.gentoo.org/wiki/Clang/Desktop_profile): > > > gentoo:default/linux/amd64/23.0/desktop/plasma/systemd > > gentoo:features/llvm Fantastic, thanks for the info! > Additionally, I have LLVM 20 masked since libc++ 20 drops support for clang > 17 which comes with Swift 6.0.2. That might be the problem you're hitting > here. Alternatively I have encountered another crash while compiling swiftpm > which didn't always happen (see > /etc/portage/patches/dev-lang/swift:6/fix-build-crash.patch) Ah, that indeed sounds like what I was hitting. I'll look into this too — I would expect `LLVM_COMPAT=( {15..19} )` to be respected and not require LLVM 20 to be masked, but this might be enough to get me set up for the time being. > I'll attach my /etc/portage and the local overlay I use for the profile, > which is hopefully enough so you can test and hopefully reproduce. If you > also want to send me a patch, I can test it. Thanks! That's extremely helpful. I'll try to repro with this setup. > PS: it would be great to split the Swift package into its components (llvm, > clang, swiftc etc.) so parts can be rebuilt without having to redo the whole > thing every time, specifically to shorten the build time. I don't know > nearly enough about this to do it myself though. I would love this too, but sadly, the Swift build system isn't componentized at all. :sad: The only really supported way to build is via the monolithic build script, and compile an entire toolchain at a time. (Definitely not an intractable problem, but I don't personally have the time at the moment to investigate and support an alternative build system.)
Okay, I got a chance to test this out in a clean Docker image with the LLVM profile set up as described — looks like I'm hitting the same compilation issue building Swift 6.0.3 as I was before. Tracked it down to building IndexStoreDB: > In file included from /var/tmp/portage/dev-lang/swift-6.0.3/work/indexstore-db/lib/CIndexStoreDB/CIndexStoreDB.cpp:13: > /var/tmp/portage/dev-lang/swift-6.0.3/work/indexstore-db/lib/CIndexStoreDB/include/CIndexStoreDB/CIndexStoreDB.h:85:40: error: expression is not an integral constant expression > 85 | INDEXSTOREDB_SYMBOL_ROLE_CANONICAL = 1 << 63, > | ^~~~~~~ > /var/tmp/portage/dev-lang/swift-6.0.3/work/indexstore-db/lib/CIndexStoreDB/include/CIndexStoreDB/CIndexStoreDB.h:85:42: note: shift count 63 >= width of type 'int' (32 bits) > 85 | INDEXSTOREDB_SYMBOL_ROLE_CANONICAL = 1 << 63, > | ^ This is with > env USE=libcxx emerge dev-lang/swift:6 and LLVM + clang 19.1.7. Might be able to patch around it; let me see where I get after that.
Created attachment 921590 [details] swift-6.0.3-r1.ebuild and associated files Okay, I've gotten further, but not by much — now hitting linking issues: > ld.lld: error: undefined symbol: swift::LifetimeDependenceInfo::getString[abi:cxx11]() const > >>> referenced by SIL.o > >>> SIL.o:($s3SIL18FunctionConventionV18ResultDependenciesV11descriptionSSvg) in archive lib/libswiftCompilerModules.a > > ld.lld: error: undefined symbol: BridgedOwnedString::BridgedOwnedString(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>> const&) > >>> referenced by SIL.o > >>> SIL.o:($s3SIL18FunctionConventionV18ResultDependenciesV11descriptionSSvg) in archive lib/libswiftCompilerModules.a > >>> referenced by SIL.o > >>> SIL.o:($s3SIL4TypeV11descriptionSSvg) in archive lib/libswiftCompilerModules.a > >>> referenced by SIL.o > >>> SIL.o:(BridgedASTType::getDebugDescription() const) in archive lib/libswiftCompilerModules.a > >>> referenced 1 more times > > ld.lld: error: undefined symbol: swift::SILType::getDebugDescription[abi:cxx11]() const > >>> referenced by SIL.o > >>> SIL.o:($s3SIL4TypeV11descriptionSSvg) in archive lib/libswiftCompilerModules.a > >>> referenced by SIL.o > >>> SIL.o:(BridgedType::getDebugDescription() const) in archive lib/libswiftCompilerModules.a > > ld.lld: error: undefined symbol: swift::Type::getString[abi:cxx11](swift::PrintOptions const&) const > >>> referenced by SIL.o > >>> SIL.o:(BridgedASTType::getDebugDescription() const) in archive lib/libswiftCompilerModules.a > > ld.lld: error: undefined symbol: swift::KeyPathPatternComponent::visitReferencedFunctionsAndMethods(std::function<void (swift::SILFunction*)>, std::function<void (swift::SILDeclRef)>) const > >>> referenced by SIL.o > >>> SIL.o:(BridgedInstruction::KeyPathInst_getReferencedFunctions(long, BridgedInstruction::KeyPathFunctionResults*) const) in archive lib/libswiftCompilerModules.a > > ld.lld: error: undefined symbol: swift::TryApplyInst::create(swift::SILDebugLocation, swift::SILValue, swift::SubstitutionMap, llvm::ArrayRef<swift::SILValue>, swift::SILBasicBlock*, swift::SILBasicBlock*, swift::optionset::OptionSet<swift::ApplyFlags, unsigned char>, swift::SILFunction&, > swift::GenericSpecializationInformation const*, std::optional<swift::ApplyIsolationCrossing>) > >>> referenced by SIL.o > >>> SIL.o:(BridgedBuilder::createTryApply(BridgedValue, BridgedSubstitutionMap, BridgedValueArray, BridgedBasicBlock, BridgedBasicBlock, bool, BridgedGenericSpecializationInformation) const) in archive lib/libswiftCompilerModules.a > > ld.lld: error: undefined symbol: swift::ApplyInst::create(swift::SILDebugLocation, swift::SILValue, swift::SubstitutionMap, llvm::ArrayRef<swift::SILValue>, swift::optionset::OptionSet<swift::ApplyFlags, unsigned char>, std::optional<swift::SILModuleConventions>, swift::SILFunction&, swift::GenericSpecializationInformation > const*, std::optional<swift::ApplyIsolationCrossing>) > >>> referenced by SIL.o > >>> SIL.o:(BridgedBuilder::createApply(BridgedValue, BridgedSubstitutionMap, BridgedValueArray, bool, bool, BridgedGenericSpecializationInformation) const) in archive lib/libswiftCompilerModules.a > > ld.lld: error: undefined symbol: std::__throw_length_error(char const*) > >>> referenced by SIL.o > >>> SIL.o:(void std::vector<swift::AnyAttrKind, std::allocator<swift::AnyAttrKind>>::_M_range_initialize<swift::AnyAttrKind const*>(swift::AnyAttrKind const*, swift::AnyAttrKind const*, std::forward_iterator_tag)) in archive lib/libswiftCompilerModules.a > > ld.lld: error: undefined symbol: std::__throw_bad_array_new_length() > >>> referenced by SIL.o > >>> SIL.o:(std::__new_allocator<swift::AnyAttrKind>::allocate(unsigned long, void const*)) in archive lib/libswiftCompilerModules.a > >>> referenced by Optimizer.o > >>> Optimizer.o:(std::__new_allocator<swift::SILBasicBlock const*>::allocate(unsigned long, void const*)) in archive lib/libswiftCompilerModules.a > > ld.lld: error: undefined symbol: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>::replace(unsigned long, unsigned long, char const*, unsigned long) > >>> referenced by SIL.o > >>> SIL.o:(swift::SILBuilder::appendOperandTypeName(swift::SILType, llvm::SmallString<16u>&)) in archive lib/libswiftCompilerModules.a > > ld.lld: error: undefined symbol: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>::_M_create(unsigned long&, unsigned long) > >>> referenced by SIL.o > >>> SIL.o:(void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>::_M_construct<char*>(char*, char*, std::forward_iterator_tag)) in archive lib/libswiftCompilerModules.a > > ld.lld: error: undefined symbol: swift::SILBuilder::substituteAnonymousArgs(llvm::SmallString<4u>, std::optional<swift::SILDebugVariable>, swift::SILLocation) > >>> referenced by SIL.o > >>> SIL.o:(swift::SILBuilder::createAllocStack(swift::SILLocation, swift::SILType, std::optional<swift::SILDebugVariable>, swift::HasDynamicLifetime_t, swift::IsLexical_t, swift::IsFromVarDecl_t, swift::UsesMoveableValueDebugInfo_t, bool)) in archive lib/libswiftCompilerModules.a > > ld.lld: error: undefined symbol: swift::AllocStackInst::create(swift::SILDebugLocation, swift::SILType, swift::SILFunction&, std::optional<swift::SILDebugVariable>, swift::HasDynamicLifetime_t, swift::IsLexical_t, swift::IsFromVarDecl_t, swift::UsesMoveableValueDebugInfo_t) > >>> referenced by SIL.o > >>> SIL.o:(swift::SILBuilder::createAllocStack(swift::SILLocation, swift::SILType, std::optional<swift::SILDebugVariable>, swift::HasDynamicLifetime_t, swift::IsLexical_t, swift::IsFromVarDecl_t, swift::UsesMoveableValueDebugInfo_t, bool)) in archive lib/libswiftCompilerModules.a > > ld.lld: error: undefined symbol: swift::MetatypeType::get(swift::Type, std::optional<swift::MetatypeRepresentation>, swift::ASTContext const&) > >>> referenced by SIL.o > >>> SIL.o:(swift::MetatypeType::get(swift::Type, std::optional<swift::MetatypeRepresentation>)) in archive lib/libswiftCompilerModules.a > clang-15: error: linker command failed with exit code 1 (use -v to see invocation) Marco, it might be quicker and easier if you have the time to try my proposed swift-6.0.3-r1 ebuild. Attached are the ebuild and files/ contents with associated patches. If this compiles successfully for you, then I'll push out the proposed changes.
I had to patch the IndexStoreDB as well as of recently. No idea why, this is another compile error that appeared out of nowhere where I have no idea how it ever compiled in the first place. Should have attached a patch after it started happening, my bad. Trying to build yours right now -- by the way, is there a better way to pass -DLIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION=2 to llvm-cmake-options? I'll have to fix up my patch (libcxx-typeinfo.patch) for this but it would be better if it was possible to do this just via /etc/portage/env.
Created attachment 921637 [details, diff] indexstoredb.patch
I am hitting the same linker error as you now. Pretty sure it's because the new gentoo-build-preset.patch is missing the the llvm-cmake-options=-DCLANG_DEFAULT_CXX_STDLIB=libc++. Also I would suggest not unconditionally compiling libcxx like it looks like you're doing in the new ebuild, that probably blows up compile times significantly just for it to never get used on non-libcxx systems.
Ah, I had assumed that passing `-stdlib=libc++` would override that value anyway, but perhaps not. I'm going to restore the `libcxx` build preset and try an alternative way.
Right, so adding that doesn't fix it (though it does need to be there for the final built package to compile stuff properly after installing IIRC). The main problem is that part of the build process stuff is compiled against libstdcxx and part is compiled against libc++, because the swift 5.10 clang is never built to use libc++ because I couldn't get that to work. I spent a while figuring this out initially before I got it to work and tbh I'm not sure why it no longer works with the -r1 ebuild. It looks like you should be passing that through now via CXXFLAGS. Does the current swift-6.0.3 compile for you with the new patch I linked?
(In reply to Itai Ferber from comment #15) > Ah, I had assumed that passing `-stdlib=libc++` would override that value > anyway, but perhaps not. I'm going to restore the `libcxx` build preset and > try an alternative way. It probably should, at least for build time. There's probably one small part missing somewhere. The offending object file is SIL.o, is the flag there for it? Going to check myself in a bit.
Created attachment 921647 [details] Updated patches for swift-5.10.1 and swift-6.0.3 Huh, okay, I actually managed to build by restoring and using the `gentoo,libcxx` build preset — maybe because I'd built with a version of swift-5.10.1 (r4) that I'd been in the process of updating to also respect CFLAGS and CXXFLAGS? I've attached the swift-5.10.1-r4 and swift-6.0.3-r1 ebuilds and patches that worked for me — maybe this'll do the trick in your environment too?
