8:49.95 warning: `webrender_bindings` (lib) generated 4 warnings 11:08.84 warning: `webrender` (lib) generated 1 warning 11:08.84 Compiling gkrust v0.1.0 (/var/tmp/portage/www-client/firefox-105.0.2/work/firefox-105.0.2/toolkit/library/rust) Skipping large text of compile that goes here 11:09.29 Finished release [optimized] target(s) in 10m 50s 11:09.43 gmake[4]: Leaving directory '/var/tmp/portage/www-client/firefox-105.0.2/work/firefox_build/toolkit/library/rust' 11:09.43 gmake[3]: Leaving directory '/var/tmp/portage/www-client/firefox-105.0.2/work/firefox_build' 11:09.43 gmake[2]: *** [/var/tmp/portage/www-client/firefox-105.0.2/work/firefox-105.0.2/config/recurse.mk:34: compile] Error 2 11:09.43 gmake[2]: Leaving directory '/var/tmp/portage/www-client/firefox-105.0.2/work/firefox_build' 11:09.43 gmake[1]: *** [/var/tmp/portage/www-client/firefox-105.0.2/work/firefox-105.0.2/config/rules.mk:361: default] Error 2 11:09.43 gmake[1]: Leaving directory '/var/tmp/portage/www-client/firefox-105.0.2/work/firefox_build' 11:09.43 gmake: *** [client.mk:63: build] Error 2 11:09.45 189 compiler warnings present. Fails at same spot for both I have tried it with a fresh install on both the musl hardened and musl llvm stage 3 images both fail. I have tried compiling with clang on the hardened profile as well and it fails. I have no more time to troubleshoot this and will be moving back to glibc. Hopefully someone can reproduce. I am using basically stock CFlags just O3 instead of O2 so an emerge --info I assume is not needed here.
Please include: 1. emerge --info 2. the full build.log (may need to ansifilter it first, then xz -9 to compress)
(also, I'm able to build it fine on musl + clang amd64, but it needs dev-lang/rust, not dev-lang/rust-bin for now.)
(In reply to Sam James from comment #2) > (also, I'm able to build it fine on musl + clang amd64, but it needs > dev-lang/rust, not dev-lang/rust-bin for now.) is that using a fresh stage 3? I had rust installed not rust-bin.
(In reply to Dante Robinson from comment #3) > (In reply to Sam James from comment #2) > > (also, I'm able to build it fine on musl + clang amd64, but it needs > > dev-lang/rust, not dev-lang/rust-bin for now.) > > is that using a fresh stage 3? I had rust installed not rust-bin. Yes.
(In reply to Sam James from comment #4) > (In reply to Dante Robinson from comment #3) > > (In reply to Sam James from comment #2) > > > (also, I'm able to build it fine on musl + clang amd64, but it needs > > > dev-lang/rust, not dev-lang/rust-bin for now.) > > > > is that using a fresh stage 3? I had rust installed not rust-bin. > > Yes. ... but with ~arch, not stable.
(In reply to Sam James from comment #5) > (In reply to Sam James from comment #4) > > (In reply to Dante Robinson from comment #3) > > > (In reply to Sam James from comment #2) > > > > (also, I'm able to build it fine on musl + clang amd64, but it needs > > > > dev-lang/rust, not dev-lang/rust-bin for now.) > > > > > > is that using a fresh stage 3? I had rust installed not rust-bin. > > > > Yes. > > ... but with ~arch, not stable. For me I can't even build firefox with the clang flag when using the llvm musl stage 3 as its in brackets and can't be changed for some reason. I had to switch to a custom clang-musl profile to enable it from github here - github.com/clang-musl-overlay/clang-musl-overlay I wasn't able to compile GCC before for some reason and was forced to pull in the binary from the gcc musl stage 3 but it compiles now using clang however I am still unable to compile firefox using GCC and can't use clang as its profile disabled even on the clang musl profile for some reason. Here is my emerge --info I have tried compiling with -fno-pie as well and have tried without using mold as a linker of course. I had to remove the repos sections because it says new accounts can't post links for 24 hours. Portage 3.0.38.1 (python 3.10.8-final-0, default/linux/amd64/17.0/musl/clang, gcc-12.2.0, musl-1.2.3, 5.19.0-76051900-generic x86_64) ================================================================= System uname: Linux-5.19.0-76051900-generic-x86_64-AMD_Ryzen_9_5950X_16-Core_Processor-with-libc KiB Mem: 32775020 total, 21782248 free KiB Swap: 0 total, 0 free Timestamp of repository gentoo: Thu, 13 Oct 2022 22:00:01 +0000 Head commit of repository gentoo: e7e9ae7e21cc990c248b6a393471423123200057 Head commit of repository 12101111-overlay: 0762076f27492b3aebad28471896a20b6df51bdc Head commit of repository clang-musl: 637d57fd1890dc3489010749b0087f8c854e3d1f Timestamp of repository gentoo-zh: Thu, 13 Oct 2022 20:04:00 +0000 Head commit of repository gentoo-zh: c1735f59555f4ccbe5b84645ca1cfca25979b694 Timestamp of repository gentoobr: Thu, 13 Oct 2022 20:04:11 +0000 Head commit of repository gentoobr: a0656ed4f941f6d0fed3bbf9fd689c473ff1863d Timestamp of repository guru: Thu, 13 Oct 2022 20:04:08 +0000 Head commit of repository guru: bfae54c6544441bbbe71695f506a89916fbeddef Head commit of repository lto-overlay: 9e7b681b98b77e1e7f6ceff24a0d05f5798ec3e7 Timestamp of repository mv: Thu, 13 Oct 2022 20:04:00 +0000 Head commit of repository mv: 23999ee42d6c2b56541cc654af31bbdbc958f686 Timestamp of repository src_prepare-overlay: Thu, 13 Oct 2022 20:04:09 +0000 Head commit of repository src_prepare-overlay: 117fc50a116860f673a008184bfbea5b0436891e Timestamp of repository tatsh-overlay: Thu, 13 Oct 2022 20:04:10 +0000 Head commit of repository tatsh-overlay: e0fab495374372614201178601ac465273b6039c Head commit of repository toolchain-clang: e2ddd0cf73d9d34d3ae77052c241d53c28ac4e20 Timestamp of repository wayland-desktop: Thu, 13 Oct 2022 20:04:10 +0000 Head commit of repository wayland-desktop: a73693653573eccda0765b73abc0a42e316713b2 Timestamp of repository musl: Mon, 10 Oct 2022 21:05:06 +0000 Head commit of repository musl: 3a8d21c3b4367ade1dfc4e366e97e903f279f9af sh bash 5.1_p16-r1 ld GNU ld (Gentoo 2.39 p4) 2.39.0 app-misc/pax-utils: 1.3.5::gentoo app-shells/bash: 5.1_p16-r1::gentoo dev-lang/perl: 5.34.1-r3::gentoo dev-lang/python: 3.10.8::gentoo dev-lang/rust: 1.64.0-r1::gentoo dev-util/cmake: 3.23.3::gentoo dev-util/meson: 0.62.2::gentoo sys-apps/baselayout: 2.8::gentoo sys-apps/openrc: 0.45.2::gentoo sys-apps/sandbox: 2.29::gentoo sys-devel/autoconf: 2.13-r2::gentoo, 2.71-r1::gentoo sys-devel/automake: 1.16.5::gentoo sys-devel/binutils: 2.39-r2::12101111-overlay sys-devel/binutils-config: 5.4.1::gentoo sys-devel/clang: 14.0.6-r1::gentoo sys-devel/gcc: 12.2.0::gentoo sys-devel/gcc-config: 2.5-r1::gentoo sys-devel/libtool: 2.4.7::gentoo sys-devel/lld: 14.0.6::gentoo sys-devel/llvm: 14.0.6-r2::gentoo sys-devel/make: 4.3::gentoo sys-kernel/linux-headers: 5.15-r3::gentoo (virtual/os-headers) sys-libs/musl: 1.2.3::gentoo ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="*" ADDR2LINE="llvm-addr2line" AR="llvm-ar" AS="llvm-mc" CBUILD="x86_64-gentoo-linux-musl" CC="clang" CFLAGS="-march=native -mtune=native -O3 -pipe -fomit-frame-pointer -fno-plt -fPIE -fPIC -O2 -pipe " CHOST="x86_64-gentoo-linux-musl" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/sandbox.d /etc/terminfo" CPP="clang-cpp" CXX="clang++" CXXFLAGS="-march=native -mtune=native -O3 -pipe -fomit-frame-pointer -fno-plt -fPIE -fPIC -march=native -mtune=native -O3 -pipe -fomit-frame-pointer -fno-plt -fPIE -fPIC -O2 -pipe " DISTDIR="/var/cache/distfiles" ENV_UNSET="CARGO_HOME DBUS_SESSION_BUS_ADDRESS DISPLAY 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="-march=native -mtune=native -O3 -pipe -fomit-frame-pointer -fno-plt -fPIE -fPIC -march=native -mtune=native -O3 -pipe -fomit-frame-pointer -fno-plt -fPIE -fPIC -O2 -pipe " FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs binpkg-multi-instance buildpkg-live config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-march=native -mtune=native -O3 -pipe -fomit-frame-pointer -fno-plt -fPIE -fPIC -march=native -mtune=native -O3 -pipe -fomit-frame-pointer -fno-plt -fPIE -fPIC -O2 -pipe " INSTALL_MASK="charset.alias /usr/share/locale/locale.alias" LANG="C.UTF-8" LD="ld.lld" LDFLAGS="-march=native -mtune=native -fuse-ld=mold -Wl,-O3,-zrelro,-znow" MAKEOPTS="-j32 -l32" 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" RUSTFLAGS="-Ctarget-cpu=native -Copt-level=3 -Clinker=clang -Clink-arg=-fuse-ld=/usr/bin/mold -Ctarget-feature=-crt-static" SHELL="/bin/bash" STRINGS="llvm-strings" STRIP="llvm-strip" USE="alsa amd64 bzip2 clang cli crypt custom-cflags dri ffmpeg fortran gif hardened iconv ipv6 jpeg libglvnd libnotify libtirpc llvm-libunwind minimal ncurses nptl opengl openmp opus pam pdf pic pie pipewire png readline screencast sdl seccomp split-usr ssl test-rust truetype udev unicode usb v4l vaapi vulkan wayland xattr" ABI_X86="64" ADA_TARGET="gnat_2020" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache 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 sse4a ssse3" ELIBC="musl" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock greis isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="efi-64" INPUT_DEVICES="libinput" KERNEL="linux" L10N="en-US" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LLVM_TARGETS="X86 AMDGPU" LUA_SINGLE_TARGET="lua5-1" LUA_TARGETS="luajit lua5-4" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php7-4 php8-0" POSTGRES_TARGETS="postgres12 postgres13" PYTHON_SINGLE_TARGET="python3_10" PYTHON_TARGETS="python3_10" RUBY_TARGETS="ruby27" USERLAND="GNU" VIDEO_CARDS="amdgpu radeonsi" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq proto steal rawnat 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, LC_ALL, LEX, LFLAGS, LIBTOOL, LINGUAS, MAKE, MAKEFLAGS, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, SIZE, YACC, YFLAGS
Can you share the build.log of it failing to build? Also, please remove fPIE and fPIC from flags. We already default to it for many years now but forcing it in flags means things try to use it which shouldn't.
(In reply to Sam James from comment #7) > Can you share the build.log of it failing to build? > > Also, please remove fPIE and fPIC from flags. We already default to it for > many years now but forcing it in flags means things try to use it which > shouldn't. They are not defaulted fPIE is disabled by default on many packages without being forced it's not even listed in the profiles it works as a cflag on most packages except around 10 or so on my system. Even without fPIE and fPIC Compilation still fails at a slightly earlier time with the same error it seems. Where is the build.log all I can seem to find is the emerge.log which seems like useless information and the summary.log which shows the no error message lines located in /var/log/portage/elog
(In reply to Dante Robinson from comment #8) > (In reply to Sam James from comment #7) > > Can you share the build.log of it failing to build? > > > > Also, please remove fPIE and fPIC from flags. We already default to it for > > many years now but forcing it in flags means things try to use it which > > shouldn't. > > They are not defaulted fPIE is disabled by default on many packages without > being forced it's not even listed in the profiles it works as a cflag on > most packages except around 10 or so on my system. Even without fPIE and > fPIC Compilation still fails at a slightly earlier time with the same error > it seems. It's not listed in the profiles because we patch it in to the compiler. Please see https://wiki.gentoo.org/wiki/Hardened/Toolchain#Changes. You don't see various other things, like -fstack-protector-string, but that's on too. ... and -D_FORTIFY_SOURCE=2. And a bunch of other things. And more I will be adding soon. > > Where is the build.log all I can seem to find is the emerge.log which seems > like useless information and the summary.log which shows the no error > message lines located in /var/log/portage/elog When it fails to build, it should give you a message saying where, but it'll be in /var/tmp/portage/www-client/firefox*/temp/build.log.
(In reply to Sam James from comment #9) > (In reply to Dante Robinson from comment #8) > > (In reply to Sam James from comment #7) > > > Can you share the build.log of it failing to build? > > > > > > Also, please remove fPIE and fPIC from flags. We already default to it for > > > many years now but forcing it in flags means things try to use it which > > > shouldn't. > > > > They are not defaulted fPIE is disabled by default on many packages without > > being forced it's not even listed in the profiles it works as a cflag on > > most packages except around 10 or so on my system. Even without fPIE and > > fPIC Compilation still fails at a slightly earlier time with the same error > > it seems. > > > ... and -D_FORTIFY_SOURCE=2. And a bunch of other things. And more I will be > adding soon. -D_FORTIFY_SOURCE=2 is shown in the profile as well as fPIC I am pretty sure. but I don't mean it in that way I mean packages like GCC will show up and say fPIE is no enabled if they are looking for it this was the sole reason of me adding the flag in the first place. > > > > Where is the build.log all I can seem to find is the emerge.log which seems > > like useless information and the summary.log which shows the no error > > message lines located in /var/log/portage/elog > > When it fails to build, it should give you a message saying where, but it'll > be in /var/tmp/portage/www-client/firefox*/temp/build.log. This makes sense don't know why I didn't think to check there, I will add it as an attachment.
(In reply to Dante Robinson from comment #10) > -D_FORTIFY_SOURCE=2 is shown in the profile as well as fPIC I am pretty > sure. but I don't mean it in that way I mean packages like GCC will show up > and say fPIE is no enabled if they are looking for it this was the sole > reason of me adding the flag in the first place. I don't know what you mean. We patch the compiler to add these in, have done for years, and we were the reason that GCC gained an option for it at configure-time. You can pass options to GCC to see what it's effectively using if you wish, but you can't just go off what you see in the build log.
(In reply to Sam James from comment #11) > (In reply to Dante Robinson from comment #10) > > -D_FORTIFY_SOURCE=2 is shown in the profile as well as fPIC I am pretty > > sure. but I don't mean it in that way I mean packages like GCC will show up > > and say fPIE is no enabled if they are looking for it this was the sole > > reason of me adding the flag in the first place. > > I don't know what you mean. We patch the compiler to add these in, have done > for years, and we were the reason that GCC gained an option for it at > configure-time. > > You can pass options to GCC to see what it's effectively using if you wish, > but you can't just go off what you see in the build log. I see anyway to verify that without taking your word? As for the build.log I can't upload it as its 400KB to large should I delete around half of it?
(In reply to Dante Robinson from comment #12) > (In reply to Sam James from comment #11) > > (In reply to Dante Robinson from comment #10) > > > -D_FORTIFY_SOURCE=2 is shown in the profile as well as fPIC I am pretty > > > sure. but I don't mean it in that way I mean packages like GCC will show up > > > and say fPIE is no enabled if they are looking for it this was the sole > > > reason of me adding the flag in the first place. > > > > I don't know what you mean. We patch the compiler to add these in, have done > > for years, and we were the reason that GCC gained an option for it at > > configure-time. > > > > You can pass options to GCC to see what it's effectively using if you wish, > > but you can't just go off what you see in the build log. > > I see anyway to verify that without taking your word? $ gcc -dM -E - < /dev/null | grep PIE #define __PIE__ 2 $ gcc -dM -E - < /dev/null | grep PIC #define __PIC__ 2 $ gcc -dM -E - < /dev/null | grep SSP #define __SSP_STRONG__ 3 $ gcc -O2 -dM -E - < /dev/null | grep FORT #define _FORTIFY_SOURCE 2 etc. It would honestly be insane for us to ship a distro in 2022 without defaulting PIE on. Again, we were one of the first to do it at all. :) > As for the build.log I can't upload it as its 400KB to large should I delete around half of it? 1. run ansifilter on it 2. xz -9 How big is it then?
Created attachment 824005 [details] build
(In reply to Sam James from comment #13) > (In reply to Dante Robinson from comment #12) > > (In reply to Sam James from comment #11) > > > (In reply to Dante Robinson from comment #10) > > > > -D_FORTIFY_SOURCE=2 is shown in the profile as well as fPIC I am pretty > > > > sure. but I don't mean it in that way I mean packages like GCC will show up > > > > and say fPIE is no enabled if they are looking for it this was the sole > > > > reason of me adding the flag in the first place. > > > > > > I don't know what you mean. We patch the compiler to add these in, have done > > > for years, and we were the reason that GCC gained an option for it at > > > configure-time. > > > > > > You can pass options to GCC to see what it's effectively using if you wish, > > > but you can't just go off what you see in the build log. > > > > I see anyway to verify that without taking your word? > > $ gcc -dM -E - < /dev/null | grep PIE > #define __PIE__ 2 > > $ gcc -dM -E - < /dev/null | grep PIC > #define __PIC__ 2 > > $ gcc -dM -E - < /dev/null | grep SSP > #define __SSP_STRONG__ 3 > > $ gcc -O2 -dM -E - < /dev/null | grep FORT > #define _FORTIFY_SOURCE 2 > > etc. It would honestly be insane for us to ship a distro in 2022 without > defaulting PIE on. Again, we were one of the first to do it at all. :) Thanks! > > As for the build.log I can't upload it as its 400KB to large should I delete around half of it? > > 1. run ansifilter on it > 2. xz -9 > > How big is it then? just running xz -v 9 makes it around 700 and fits. Should be able to see it now.
Error seems to be: 8:34.90 /usr/lib/llvm/14/bin/llvm-mc -o breakpad_getcontext.o -DNDEBUG=1 -DTRIMMED=1 -DMOZ_REPLACE_MALLOC_PREFIX=profiler -DOS_POSIX=1 -DOS_LINUX=1 -DMOZ_HAS_MOZGLUE -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL -DSTATIC_EXPORTABLE_JS_API -fPIC -Wa,--noexecstack -include /var/tmp/portage/www-client/firefox-105.0.2/work/firefox_build/mozilla-config.h -DMOZILLA_CLIENT -I/var/tmp/portage/www-client/firefox-105.0.2/work/firefox-105.0.2/caps -I/var/tmp/portage/www-client/firefox-105.0.2/work/firefox-105.0.2/docshell/base -I/var/tmp/portage/www-client/firefox-105.0.2/work/firefox-105.0.2/ipc/chromium/src -I/var/tmp/portage/www-client/firefox-105.0.2/work/firefox-105.0.2/mozglue/linker -I/var/tmp/portage/www-client/firefox-105.0.2/work/firefox-105.0.2/netwerk/base -I/var/tmp/portage/www-client/firefox-105.0.2/work/firefox-105.0.2/netwerk/protocol/http -I/var/tmp/portage/www-client/firefox-105.0.2/work/firefox-105.0.2/toolkit/components/jsoncpp/include -I/var/tmp/portage/www-client/firefox-105.0.2/work/firefox-105.0.2/toolkit/crashreporter/google-breakpad/src -I/var/tmp/portage/www-client/firefox-105.0.2/work/firefox-105.0.2/tools/profiler/core -I/var/tmp/portage/www-client/firefox-105.0.2/work/firefox-105.0.2/tools/profiler/gecko -I/var/tmp/portage/www-client/firefox-105.0.2/work/firefox-105.0.2/xpcom/base -I/var/tmp/portage/www-client/firefox-105.0.2/work/firefox_build/ipc/ipdl/_ipdlheaders -I/var/tmp/portage/www-client/firefox-105.0.2/work/firefox-105.0.2/ipc/chromium/src -c /var/tmp/portage/www-client/firefox-105.0.2/work/firefox-105.0.2/toolkit/crashreporter/google-breakpad/src/common/linux/breakpad_getcontext.S 8:34.90 tools/profiler/elfutils.o 8:34.91 llvm-mc: Unknown command line argument '-DNDEBUG=1'. Try: '/usr/lib/llvm/14/bin/llvm-mc --help' 8:34.91 llvm-mc: Did you mean '--I=1'? 8:34.91 llvm-mc: Unknown command line argument '-DTRIMMED=1'. Try: '/usr/lib/llvm/14/bin/llvm-mc --help' 8:34.91 llvm-mc: Did you mean '--I=1'? 8:34.91 llvm-mc: Unknown command line argument '-DMOZ_REPLACE_MALLOC_PREFIX=profiler'. Try: '/usr/lib/llvm/14/bin/llvm-mc --help' 8:34.91 llvm-mc: Did you mean '--I=profiler'? 8:34.91 llvm-mc: Unknown command line argument '-DOS_POSIX=1'. Try: '/usr/lib/llvm/14/bin/llvm-mc --help' 8:34.91 llvm-mc: Did you mean '--I=1'? 8:34.91 llvm-mc: Unknown command line argument '-DOS_LINUX=1'. Try: '/usr/lib/llvm/14/bin/llvm-mc --help' 8:34.91 llvm-mc: Did you mean '--I=1'? 8:34.91 llvm-mc: Unknown command line argument '-DMOZ_HAS_MOZGLUE'. Try: '/usr/lib/llvm/14/bin/llvm-mc --help' 8:34.91 llvm-mc: Did you mean '-M'? 8:34.92 llvm-mc: Unknown command line argument '-DMOZILLA_INTERNAL_API'. Try: '/usr/lib/llvm/14/bin/llvm-mc --help' 8:34.92 llvm-mc: Did you mean '-I'? 8:34.92 llvm-mc: Unknown command line argument '-DIMPL_LIBXUL'. Try: '/usr/lib/llvm/14/bin/llvm-mc --help' 8:34.92 llvm-mc: Did you mean '-I'? 8:34.92 llvm-mc: Unknown command line argument '-DSTATIC_EXPORTABLE_JS_API'. Try: '/usr/lib/llvm/14/bin/llvm-mc --help' 8:34.92 llvm-mc: Did you mean '-I'? 8:34.92 llvm-mc: Unknown command line argument '-fPIC'. Try: '/usr/lib/llvm/14/bin/llvm-mc --help' 8:34.92 llvm-mc: Did you mean '-I'? 8:34.92 llvm-mc: Unknown command line argument '-Wa,--noexecstack'. Try: '/usr/lib/llvm/14/bin/llvm-mc --help' 8:34.92 llvm-mc: Did you mean '--no-exec-stack'? 8:34.92 llvm-mc: Unknown command line argument '-include'. Try: '/usr/lib/llvm/14/bin/llvm-mc --help' 8:34.92 llvm-mc: Did you mean '--mcpu'? 8:34.92 llvm-mc: Unknown command line argument '-DMOZILLA_CLIENT'. Try: '/usr/lib/llvm/14/bin/llvm-mc --help' 8:34.92 llvm-mc: Did you mean '-I'? 8:34.92 llvm-mc: Unknown command line argument '-c'. Try: '/usr/lib/llvm/14/bin/llvm-mc --help' 8:34.92 llvm-mc: Did you mean '-I'? 8:34.92 llvm-mc: Too many positional arguments specified! 8:34.92 Can specify at most 1 positional arguments: See: /usr/lib/llvm/14/bin/llvm-mc --help 8:34.92 gmake[4]: *** [/var/tmp/portage/www-client/firefox-105.0.2/work/firefox-105.0.2/config/rules.mk:664: breakpad_getcontext.o] Error 1 8:34.92 gmake[4]: Leaving directory '/var/tmp/portage/www-client/firefox-105.0.2/work/firefox_build/tools/profiler' 8:34.92 gmake[3]: *** [/var/tmp/portage/www-client/firefox-105.0.2/work/firefox-105.0.2/config/recurse.mk:72: tools/profiler/target-objects] Error 2 Your emerge --info has: >AS="llvm-mc" ... which is definitely not in a "clean chroot" ;) That's not a valid choice for AS. FYI: $ grep -rsin "AS=" profiles/ profiles/features/llvm/make.defaults:32:AS="clang -c" [...]
(but better to just *not set these at all* and rely on the defaults, this is exactly what the llvm profiles exist for.)
(In reply to Sam James from comment #16) > Error seems to be: > > > 8:34.90 /usr/lib/llvm/14/bin/llvm-mc -o breakpad_getcontext.o -DNDEBUG=1 > -DTRIMMED=1 -DMOZ_REPLACE_MALLOC_PREFIX=profiler -DOS_POSIX=1 -DOS_LINUX=1 > -DMOZ_HAS_MOZGLUE -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL > -DSTATIC_EXPORTABLE_JS_API -fPIC -Wa,--noexecstack -include > /var/tmp/portage/www-client/firefox-105.0.2/work/firefox_build/mozilla- > config.h -DMOZILLA_CLIENT > -I/var/tmp/portage/www-client/firefox-105.0.2/work/firefox-105.0.2/caps > -I/var/tmp/portage/www-client/firefox-105.0.2/work/firefox-105.0.2/docshell/ > base > -I/var/tmp/portage/www-client/firefox-105.0.2/work/firefox-105.0.2/ipc/ > chromium/src > -I/var/tmp/portage/www-client/firefox-105.0.2/work/firefox-105.0.2/mozglue/ > linker > -I/var/tmp/portage/www-client/firefox-105.0.2/work/firefox-105.0.2/netwerk/ > base > -I/var/tmp/portage/www-client/firefox-105.0.2/work/firefox-105.0.2/netwerk/ > protocol/http > -I/var/tmp/portage/www-client/firefox-105.0.2/work/firefox-105.0.2/toolkit/ > components/jsoncpp/include > -I/var/tmp/portage/www-client/firefox-105.0.2/work/firefox-105.0.2/toolkit/ > crashreporter/google-breakpad/src > -I/var/tmp/portage/www-client/firefox-105.0.2/work/firefox-105.0.2/tools/ > profiler/core > -I/var/tmp/portage/www-client/firefox-105.0.2/work/firefox-105.0.2/tools/ > profiler/gecko > -I/var/tmp/portage/www-client/firefox-105.0.2/work/firefox-105.0.2/xpcom/ > base > -I/var/tmp/portage/www-client/firefox-105.0.2/work/firefox_build/ipc/ipdl/ > _ipdlheaders > -I/var/tmp/portage/www-client/firefox-105.0.2/work/firefox-105.0.2/ipc/ > chromium/src -c > /var/tmp/portage/www-client/firefox-105.0.2/work/firefox-105.0.2/toolkit/ > crashreporter/google-breakpad/src/common/linux/breakpad_getcontext.S > 8:34.90 tools/profiler/elfutils.o > 8:34.91 llvm-mc: Unknown command line argument '-DNDEBUG=1'. Try: > '/usr/lib/llvm/14/bin/llvm-mc --help' > 8:34.91 llvm-mc: Did you mean '--I=1'? > 8:34.91 llvm-mc: Unknown command line argument '-DTRIMMED=1'. Try: > '/usr/lib/llvm/14/bin/llvm-mc --help' > 8:34.91 llvm-mc: Did you mean '--I=1'? > 8:34.91 llvm-mc: Unknown command line argument > '-DMOZ_REPLACE_MALLOC_PREFIX=profiler'. Try: '/usr/lib/llvm/14/bin/llvm-mc > --help' > 8:34.91 llvm-mc: Did you mean '--I=profiler'? > 8:34.91 llvm-mc: Unknown command line argument '-DOS_POSIX=1'. Try: > '/usr/lib/llvm/14/bin/llvm-mc --help' > 8:34.91 llvm-mc: Did you mean '--I=1'? > 8:34.91 llvm-mc: Unknown command line argument '-DOS_LINUX=1'. Try: > '/usr/lib/llvm/14/bin/llvm-mc --help' > 8:34.91 llvm-mc: Did you mean '--I=1'? > 8:34.91 llvm-mc: Unknown command line argument '-DMOZ_HAS_MOZGLUE'. Try: > '/usr/lib/llvm/14/bin/llvm-mc --help' > 8:34.91 llvm-mc: Did you mean '-M'? > 8:34.92 llvm-mc: Unknown command line argument '-DMOZILLA_INTERNAL_API'. > Try: '/usr/lib/llvm/14/bin/llvm-mc --help' > 8:34.92 llvm-mc: Did you mean '-I'? > 8:34.92 llvm-mc: Unknown command line argument '-DIMPL_LIBXUL'. Try: > '/usr/lib/llvm/14/bin/llvm-mc --help' > 8:34.92 llvm-mc: Did you mean '-I'? > 8:34.92 llvm-mc: Unknown command line argument > '-DSTATIC_EXPORTABLE_JS_API'. Try: '/usr/lib/llvm/14/bin/llvm-mc --help' > 8:34.92 llvm-mc: Did you mean '-I'? > 8:34.92 llvm-mc: Unknown command line argument '-fPIC'. Try: > '/usr/lib/llvm/14/bin/llvm-mc --help' > 8:34.92 llvm-mc: Did you mean '-I'? > 8:34.92 llvm-mc: Unknown command line argument '-Wa,--noexecstack'. Try: > '/usr/lib/llvm/14/bin/llvm-mc --help' > 8:34.92 llvm-mc: Did you mean '--no-exec-stack'? > 8:34.92 llvm-mc: Unknown command line argument '-include'. Try: > '/usr/lib/llvm/14/bin/llvm-mc --help' > 8:34.92 llvm-mc: Did you mean '--mcpu'? > 8:34.92 llvm-mc: Unknown command line argument '-DMOZILLA_CLIENT'. Try: > '/usr/lib/llvm/14/bin/llvm-mc --help' > 8:34.92 llvm-mc: Did you mean '-I'? > 8:34.92 llvm-mc: Unknown command line argument '-c'. Try: > '/usr/lib/llvm/14/bin/llvm-mc --help' > 8:34.92 llvm-mc: Did you mean '-I'? > 8:34.92 llvm-mc: Too many positional arguments specified! > 8:34.92 Can specify at most 1 positional arguments: See: > /usr/lib/llvm/14/bin/llvm-mc --help > 8:34.92 gmake[4]: *** > [/var/tmp/portage/www-client/firefox-105.0.2/work/firefox-105.0.2/config/ > rules.mk:664: breakpad_getcontext.o] Error 1 > 8:34.92 gmake[4]: Leaving directory > '/var/tmp/portage/www-client/firefox-105.0.2/work/firefox_build/tools/ > profiler' > 8:34.92 gmake[3]: *** > [/var/tmp/portage/www-client/firefox-105.0.2/work/firefox-105.0.2/config/ > recurse.mk:72: tools/profiler/target-objects] Error 2 > > Your emerge --info has: > >AS="llvm-mc" > > ... which is definitely not in a "clean chroot" ;) > > That's not a valid choice for AS. I thought it was... fair enough > FYI: > $ grep -rsin "AS=" profiles/ > profiles/features/llvm/make.defaults:32:AS="clang -c" > [...] (In reply to Sam James from comment #17) > (but better to just *not set these at all* and rely on the defaults, this is > exactly what the llvm profiles exist for.) I guess I just have a tendency to set this manually to make sure they are running... I have commented out all those lines and it still fails. I will attach the build.log
Created attachment 824007 [details] build2
9:12.40 /usr/bin/x86_64-gentoo-linux-musl-gcc -std=gnu99 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -march=native -mtune=native -pipe -fomit-frame-pointer -fno-plt -pipe -fPIC -ffunction-sections -fdata-sections -fno-math-errno -pthread -pipe -O3 -fomit-frame-pointer -funwind-tables -Wall -Wempty-body -Wignored-qualifiers -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wduplicated-cond -Wlogical-op -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=coverage-mismatch -Wno-error=free-nonheap-object -Wno-multistatement-macros -Wno-error=class-memaccess -Wno-error=deprecated-copy -Wformat -Wformat-security -Wformat-overflow=2 -Wno-psabi -shared -Wl,-z,defs -Wl,--gc-sections -Wl,-h,libmozgtk.so -o libmozgtk.so mozgtk.o -lpthread -march=native -mtune=native -fuse-ld=mold -Wl,-O3,-zrelro,-znow -Wl,-z,relro -Wl,-z,now -Wl,--compress-debug-sections=zlib -Wl,-rpath=/usr/lib/firefox,--enable-new-dtags -fuse-ld=bfd -Wl,-z,noexecstack -Wl,-z,text -Wl,-z,relro -Wl,-z,nocopyreloc -Wl,-Bsymbolic-functions -fstack-protector-strong -Wl,-rpath-link,/var/tmp/portage/www-client/firefox-105.0.2/work/firefox_build/dist/bin -Wl,-rpath-link,/usr/lib -Wl,--no-as-needed -lgtk-3 -lgdk-3 -Wl,--as-needed 9:12.49 /usr/lib/gcc/x86_64-gentoo-linux-musl/12.2.0/../../../../x86_64-gentoo-linux-musl/bin/ld.bfd: /usr/lib/gcc/x86_64-gentoo-linux-musl/12.2.0/crtbeginS.o:(.text+0x9c): undefined reference to `__cxa_finalize' 9:12.49 /usr/lib/gcc/x86_64-gentoo-linux-musl/12.2.0/../../../../x86_64-gentoo-linux-musl/bin/ld.bfd: /usr/lib/gcc/x86_64-gentoo-linux-musl/12.2.0/crtbeginS.o:(.text+0xaf): undefined reference to `__cxa_finalize' 9:12.49 collect2: error: ld returned 1 exit status 9:12.49 gmake[4]: *** [/var/tmp/portage/www-client/firefox-105.0.2/work/firefox-105.0.2/config/rules.mk:540: libmozgtk.so] Error 1 9:12.49 gmake[4]: Leaving directory '/var/tmp/portage/www-client/firefox-105.0.2/work/firefox_build/widget/gtk/mozgtk' 9:12.49 gmake[3]: *** [/var/tmp/portage/www-client/firefox-105.0.2/work/firefox-105.0.2/config/recurse.mk:72: widget/gtk/mozgtk/target] Error 2 Different error at least! 1. Please try without mold. 2. You can't use GCC here because the musl LLVM stages are *pure* LLVM, which means they use libcxx, which isn't ABI compatible with libstdc++. And you can't tell GCC to use libcxx either.
(I also strongly recommend narrowing down "what makes your system weird", and not going all-in on the customisation if you're not sure what's going wrong. The RUSTFLAGS trying to.. force Clang? while using GCC seems scary. I don't know if that's you setting it or not.)
(In reply to Sam James from comment #21) > (I also strongly recommend narrowing down "what makes your system weird", > and not going all-in on the customisation if you're not sure what's going > wrong. > > The RUSTFLAGS trying to.. force Clang? while using GCC seems scary. > > I don't know if that's you setting it or not.) forgot about this one mold hasn't been an issue using GCC in the past for me I will try this first and report back.
(In reply to Sam James from comment #21) > (I also strongly recommend narrowing down "what makes your system weird", > and not going all-in on the customisation if you're not sure what's going > wrong. This is the same make.conf I was using on musl/clang previously and then edited to work on glibc and now back to musl so it may have some changes everything seems to work but this I have spent most of the week going through testing compiling without this and that this package is large and seems to want to fail near the end takes up alot of time... What do you define as weird? force setting things manually? > 1. Please try without mold. > 2. You can't use GCC here because the musl LLVM stages are *pure* LLVM, > which means they use libcxx, which isn't ABI compatible with libstdc++. And > you can't tell GCC to use libcxx either. Yes this is why last time I was on clang/musl I switched to a different profile over the stock one. I don't why clang is force disabled for me on this package. I can try switching to that profile and using clang as well but it failed earlier for me when I tried.
Created attachment 824009 [details] build3-rust-no-clang
(In reply to Dante Robinson from comment #22) > (In reply to Sam James from comment #21) > > (I also strongly recommend narrowing down "what makes your system weird", > > and not going all-in on the customisation if you're not sure what's going > > wrong. > > > > The RUSTFLAGS trying to.. force Clang? while using GCC seems scary. > > > > I don't know if that's you setting it or not.) > > forgot about this one mold hasn't been an issue using GCC in the past for me > I will try this first and report back. This has come back with an error even earlier on in the build I have attached the log as build3. Will try with Clang using the other profile next.
(In reply to Dante Robinson from comment #24) > Created attachment 824009 [details] > build3-rust-no-clang You're still setting mold; 78[1G[K[34m 3:55.07(B[m [0m [0m[0m[1m[38;5;12m= [0m[0m[1mnote[0m[0m: x86_64-gentoo-linux-musl-gcc: error: unrecognized command-line option '-fuse-ld=/usr/bin/mold'[0m(B[m(B[m 78[1G[K[34m 3:55.07(B[m [0m [0m(B[m(B[m (please ansifilter in future if you can)
(In reply to Sam James from comment #26) > (In reply to Dante Robinson from comment #24) > > Created attachment 824009 [details] > > build3-rust-no-clang > > You're still setting mold; > > 78[1G[K[34m 3:55.07(B[m [0m [0m[0m[1m[38;5;12m= [0m[0m[1mnote[0m[0m: > x86_64-gentoo-linux-musl-gcc: error: unrecognized command-line option > '-fuse-ld=/usr/bin/mold'[0m(B[m(B[m > 78[1G[K[34m 3:55.07(B[m [0m [0m(B[m(B[m Yes my bad I am compiling right now without mold. I do remember this issue I think only with GCC when mold is set on rust. > (please ansifilter in future if you can) My apologies.
The issue there I think (when using mold in that specific case) is that you need to make sure it's GCC 12.
(In reply to Dante Robinson from comment #23) > (In reply to Sam James from comment #21) > > (I also strongly recommend narrowing down "what makes your system weird", > > and not going all-in on the customisation if you're not sure what's going > > wrong. > This is the same make.conf I was using on musl/clang previously and then > edited to work on glibc and now back to musl so it may have some changes > everything seems to work but this I have spent most of the week going > through testing compiling without this and that this package is large and > seems to want to fail near the end takes up alot of time... What do you > define as weird? force setting things manually? > Anything between the base stage3 make.conf and what you've set that's likely to be "interesting", e.g. - mold - trying to force fPIE and fPIC and other hardening we already do (because it has a different effect if you try jam it in *FLAGS always, it'll break some builds) - setting RUSTFLAGS to anything other than just your CPU - setting AS and other toolchain variables - using the clang-musl overlay (and similar). I have no idea what they change (and I wish they'd submit more to us), so it also means I have no idea if it's something they've done that's breaking something. It's fine to do these things (that's part of the fun of Gentoo), but: 1. you need to know you're doing them and do it incrementally so you know what to blame if something breaks; 2. tell us what you've done when seeking support/filing a bug. The problem is, you've said "fresh install" but not indicated what you've actually changed, so it's hard for me to point to something and say "ok, it's probably that". > > 1. Please try without mold. > > 2. You can't use GCC here because the musl LLVM stages are *pure* LLVM, > > which means they use libcxx, which isn't ABI compatible with libstdc++. And > > you can't tell GCC to use libcxx either. > > Yes this is why last time I was on clang/musl I switched to a different > profile over the stock one. I don't why clang is force disabled for me on > this package. I can try switching to that profile and using clang as well > but it failed earlier for me when I tried. Me too: [ebuild N ] www-client/firefox-105.0.2:rapid::gentoo USE="X gmp-autoupdate openh264 system-av1 system-harfbuzz system-icu system-jpeg (system-libevent) system-libvpx system-webp (-clang) -dbus -debug -eme-free -geckodriver -hardened -hwaccel -jack -libproxy -lto (-pgo) -pulseaudio -screencast (-selinux) -sndio -system-png (-system-python-libs) -wayland -wifi" L10N="-ach -af -an -ar -ast -az -be -bg -bn -br -bs -ca -ca-valencia -cak -cs -cy -da -de -dsb -el -en-CA -en-GB -eo -es-AR -es-CL -es-ES -es-MX -et -eu -fa -ff -fi -fr -fy -ga -gd -gl -gn -gu -he -hi -hr -hsb -hu -hy -ia -id -is -it -ja -ka -kab -kk -km -kn -ko -lij -lt -lv -mk -mr -ms -my -nb -ne -nl -nn -oc -pa -pl -pt-BR -pt-PT -rm -ro -ru -sco -si -sk -sl -son -sq -sr -sv -szl -ta -te -th -tl -tr -trs -uk -ur -uz -vi -xh -zh-CN -zh-TW" 0 KiB It's because of this in profiles/features/musl/package.mask: ># Alfred Persson Forsberg <cat@catcream.org> (2022-07-27) ># Firefox does not build with these flags enabled on musl libc. ># See bug #829033 >www-client/firefox clang pgo I suspect we can unmask this on musl llvm profiles, as we're always using libcxx, but I'd need to check. So, it tries to build using GCC for me (and I need to go to bed now), but I'm wondering if I last built it with GCC or Clang now. I'll try building with GCC and then Clang. If Clang works, I'll unmask it for the LLVM profiles.
(In reply to Sam James from comment #29) > Anything between the base stage3 make.conf and what you've set that's likely > to be "interesting", e.g. just to add: i'm not annoyed or anything, but I need the full picture, and there's an infinite number of things one can do to break stuff, so I can't guess them all -- there's all sorts of env vars which one can set that might do something odd, so I always need hints from people doing "interesting things".
(In reply to Sam James from comment #28) > The issue there I think (when using mold in that specific case) is that you > need to make sure it's GCC 12. Yes its GCC 12 it's just that command for some reason I have seen that error before with rust specifically. It still fails with mold disabled I messed up the ansifilter and it cleared the build.log so I have to rerun the emerge to get a new build.log > Anything between the base stage3 make.conf and what you've set that's likely > to be "interesting", e.g. > - mold > - trying to force fPIE and fPIC and other hardening we already do (because > it has a different effect if you try jam it in *FLAGS always, it'll break > some builds) > - setting RUSTFLAGS to anything other than just your CPU > - setting AS and other toolchain variables > - using the clang-musl overlay (and similar). I have no idea what they > change (and I wish they'd submit more to us), so it also means I have no > idea if it's something they've done that's breaking something. I am not using the overlay currently hence why I retested with both a GCC musl stage 3 and the llvm one using the default profiles > It's fine to do these things (that's part of the fun of Gentoo), but: > 1. you need to know you're doing them and do it incrementally so you know > what to blame if something breaks; Exactly I have tested without many of these things already I have lots track like I said I have been at this all week. > 2. tell us what you've done when seeking support/filing a bug. > > The problem is, you've said "fresh install" but not indicated what you've > actually changed, so it's hard for me to point to something and say "ok, > it's probably that". It is a fresh install as fresh as can be really the only difference is the make.conf which should be shown in the emerge --info I understand my config is a little weird to others as I am constantly playing with it which is why I usually don't make bugs to have to go over everything I have checked. But at the same time I don't want to not recheck it in the case it does work. > Me too: > [ebuild N ] www-client/firefox-105.0.2:rapid::gentoo USE="X > gmp-autoupdate openh264 system-av1 system-harfbuzz system-icu system-jpeg > (system-libevent) system-libvpx system-webp (-clang) -dbus -debug -eme-free > -geckodriver -hardened -hwaccel -jack -libproxy -lto (-pgo) -pulseaudio > -screencast (-selinux) -sndio -system-png (-system-python-libs) -wayland > -wifi" L10N="-ach -af -an -ar -ast -az -be -bg -bn -br -bs -ca -ca-valencia > -cak -cs -cy -da -de -dsb -el -en-CA -en-GB -eo -es-AR -es-CL -es-ES -es-MX > -et -eu -fa -ff -fi -fr -fy -ga -gd -gl -gn -gu -he -hi -hr -hsb -hu -hy -ia > -id -is -it -ja -ka -kab -kk -km -kn -ko -lij -lt -lv -mk -mr -ms -my -nb > -ne -nl -nn -oc -pa -pl -pt-BR -pt-PT -rm -ro -ru -sco -si -sk -sl -son -sq > -sr -sv -szl -ta -te -th -tl -tr -trs -uk -ur -uz -vi -xh -zh-CN -zh-TW" 0 > KiB > > It's because of this in profiles/features/musl/package.mask: > ># Alfred Persson Forsberg <cat@catcream.org> (2022-07-27) > ># Firefox does not build with these flags enabled on musl libc. > ># See bug #829033 > >www-client/firefox clang pgo > > I suspect we can unmask this on musl llvm profiles, as we're always using > libcxx, but I'd need to check. > > So, it tries to build using GCC for me (and I need to go to bed now), but > I'm wondering if I last built it with GCC or Clang now. I'll try building > with GCC and then Clang. If Clang works, I'll unmask it for the LLVM > profiles. Yes I am aware it doesn't compile I filed an issue on 12101111 overlay about it a few weeks back but I was able to compile it with GCC then. > > 2. You can't use GCC here because the musl LLVM stages are *pure* LLVM, > > which means they use libcxx, which isn't ABI compatible with libstdc++. And > > you can't tell GCC to use libcxx either. I am lost on what you mean here then isn't GCC defaulted to since clang is disabled for this package? I thought that was the case. > just to add: i'm not annoyed or anything, but I need the full picture, and > there's an infinite number of things one can do to break stuff, so I can't > guess them all -- there's all sorts of env vars which one can set that might > do something odd, so I always need hints from people doing "interesting > things". I understand I appreciate your help as I am getting quite frustrated with it... The only thing changed here again is the make.conf haven't even attempted to boot the system though I'm sure that will all be fine that's how close to a fresh install I am if that helps.
Created attachment 824011 [details] build4-no-mold
I think I did the ansifilter correctly that time I output it to .txt instead of overwriting the original file. I work weekends and probably won't have time to check back till sunday evening or monday.
No worries, I'm off to bed, but I'm going to play with it a bit too and see how I get on.
Created attachment 824035 [details] /etc/portage
I have uploaded my entire portage config so you can see everything I use package.env to block things like mold... It's a mess right now I am in the process of many things including trying to remove xorg (last dep is keepassxc I think) everything should work with it out the gate though and let you get to compiling firefox you can also just edit the make.conf directly of course to remove things like mold.
(In reply to Sam James from comment #34) > No worries, I'm off to bed, but I'm going to play with it a bit too and see > how I get on. Did you figure anything out?
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e66a4f8582fc9c34e41b428a6f6a1270493f00fe commit e66a4f8582fc9c34e41b428a6f6a1270493f00fe Author: Sam James <sam@gentoo.org> AuthorDate: 2022-10-15 23:21:20 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-10-15 23:26:19 +0000 profiles/default/linux: unmask www-client/firefox[clang] on LLVM profiles We end up crashing when building gecko-profiler otherwise but the mask doesn't make sense on these profiles anyway, as the issue that led to them being masked was wrt libcxx - and on these profiles, we always have libcxx. Bug: https://bugs.gentoo.org/829033 Bug: https://bugs.gentoo.org/877021 Signed-off-by: Sam James <sam@gentoo.org> profiles/default/linux/amd64/17.0/musl/clang/package.use.mask | 6 ++++++ profiles/default/linux/arm64/17.0/musl/llvm/package.use.mask | 6 ++++++ 2 files changed, 12 insertions(+)
Actually, it still SIGSEGVs for me with Clang, but I've worked around that before somehow.
(In reply to Sam James from comment #39) > Actually, it still SIGSEGVs for me with Clang, but I've worked around that > before somehow. I ran emerge --sync sync to get the profile update clang shows up for me now. Firefox installed first try for me with this new profile Thanks!
(In reply to Dante Robinson from comment #40) > (In reply to Sam James from comment #39) > > Actually, it still SIGSEGVs for me with Clang, but I've worked around that > > before somehow. > > I ran emerge --sync sync to get the profile update clang shows up for me > now. Firefox installed first try for me with this new profile Thanks! Fantastic! :)
(In reply to Sam James from comment #41) > (In reply to Dante Robinson from comment #40) > > (In reply to Sam James from comment #39) > > > Actually, it still SIGSEGVs for me with Clang, but I've worked around that > > > before somehow. > > > > I ran emerge --sync sync to get the profile update clang shows up for me > > now. Firefox installed first try for me with this new profile Thanks! > > Fantastic! :) Unrelated to this bug I do have a question about other issues. I tend to not file bug reports unless I know whats at fault for it so I know where best to report them. With LLVM if you look in my make.conf you can see LLVM_TARGETS variable now these aren't allowed in gentoo profiles I assume for the reason I am about to mention on the clang musl profile from github it lets me disable these however if I am rebuilding Clang and LLVM to remove the other targets it will no longer work and complain instantly about missing targets every compile and crash. I did however notice when building to a new version of Clang and LLVM such as 15 its not an issue but if I build those with all targets and later remove the targets by switching profiles same issue... I assume its a Gentoo issue but again I don't know. It would be a huge pro to be able to remove uneeded targets as it lowers compile times and Clang uses less ram to compile as it is so it's ideal for lower end systems as it is so this would be a good benefit. I can open a bug for it with full detail if that's something you think is a Gentoo issue.I haven't tested it on glibc as I've never bothered to make my own profile to remove the targets.
(In reply to Dante Robinson from comment #42) > (In reply to Sam James from comment #41) > > (In reply to Dante Robinson from comment #40) > > > (In reply to Sam James from comment #39) > > > > Actually, it still SIGSEGVs for me with Clang, but I've worked around that > > > > before somehow. > > > > > > I ran emerge --sync sync to get the profile update clang shows up for me > > > now. Firefox installed first try for me with this new profile Thanks! > > > > Fantastic! :) > > Unrelated to this bug I do have a question about other issues. I tend to not > file bug reports unless I know whats at fault for it so I know where best to > report them. With LLVM if you look in my make.conf you can see LLVM_TARGETS > variable now these aren't allowed in gentoo profiles I assume for the reason > I am about to mention on the clang musl profile from github it lets me > disable these however if I am rebuilding Clang and LLVM to remove the other > targets it will no longer work and complain instantly about missing targets > every compile and crash. That issue is precisely why they're forced on. It's fine if you want to unforce it, but you have to make sure your system is consistent as a result (and therefore I think it's easiest if you only do it for new major versions). I did however notice when building to a new version > of Clang and LLVM such as 15 its not an issue but if I build those with all > targets and later remove the targets by switching profiles same issue... I > assume its a Gentoo issue but again I don't know. It would be a huge pro to > be able to remove uneeded targets as it lowers compile times and Clang uses > less ram to compile as it is so it's ideal for lower end systems as it is so > this would be a good benefit. I wish too, but it requires fixing packages to properly handle LLVM in their build systems to not automagically use symbols for all targets even if they don't need them. This is why they started being forced on. i.e. It's not done by accident or something, it used to be unforced, but we forced them all on because of precisely the issue you're describing. I can open a bug for it with full detail if > that's something you think is a Gentoo issue.I haven't tested it on glibc as > I've never bothered to make my own profile to remove the targets. For some things, I'd like bugs to know about UX problems, but unfortunately, in this case, it's a known issue and unfixable (see the package.use.force message for these). The issue is bug 767700 anyway if you want to read up on it.
(In reply to Sam James from comment #43) > (In reply to Dante Robinson from comment #42) > > (In reply to Sam James from comment #41) > > > (In reply to Dante Robinson from comment #40) > > > > (In reply to Sam James from comment #39) > > > > > Actually, it still SIGSEGVs for me with Clang, but I've worked around that > > > > > before somehow. > > > > > > > > I ran emerge --sync sync to get the profile update clang shows up for me > > > > now. Firefox installed first try for me with this new profile Thanks! > > > > > > Fantastic! :) > > > > Unrelated to this bug I do have a question about other issues. I tend to not > > file bug reports unless I know whats at fault for it so I know where best to > > report them. With LLVM if you look in my make.conf you can see LLVM_TARGETS > > variable now these aren't allowed in gentoo profiles I assume for the reason > > I am about to mention on the clang musl profile from github it lets me > > disable these however if I am rebuilding Clang and LLVM to remove the other > > targets it will no longer work and complain instantly about missing targets > > every compile and crash. > > That issue is precisely why they're forced on. It's fine if you want to > unforce it, but you have to make sure your system is consistent as a result > (and therefore I think it's easiest if you only do it for new major > versions). > > I did however notice when building to a new version > > of Clang and LLVM such as 15 its not an issue but if I build those with all > > targets and later remove the targets by switching profiles same issue... I > > assume its a Gentoo issue but again I don't know. It would be a huge pro to > > be able to remove uneeded targets as it lowers compile times and Clang uses > > less ram to compile as it is so it's ideal for lower end systems as it is so > > this would be a good benefit. > > I wish too, but it requires fixing packages to properly handle LLVM in their > build systems to not automagically use symbols for all targets even if they > don't need them. This is why they started being forced on. > > i.e. It's not done by accident or something, it used to be unforced, but we > forced them all on because of precisely the issue you're describing. > > I can open a bug for it with full detail if > > that's something you think is a Gentoo issue.I haven't tested it on glibc as > > I've never bothered to make my own profile to remove the targets. > > For some things, I'd like bugs to know about UX problems, but unfortunately, > in this case, it's a known issue and unfixable (see the package.use.force > message for these). > > The issue is bug 767700 anyway if you want to read up on it. Gotcha Thanks for the follow up. I guess I figured there was some patch that could be made to avoid checking for the symbols/targets or if they are missing to skip using them instead of erroring.
It's definitely technically possible, but it's a lot of work in all LLVM consumers. So if someone had a lot of free time + CMake experience, it should be fixable.
