Created attachment 207933 [details]
Apply base r352030 to help Firefox-based ports with the following:
mozglue/misc/TimeStamp.o: In function `mozilla::TimeStamp::NowFuzzy(mozilla::TimeStamp63Bit)':
TimeStamp.cpp:(.text._ZN7mozilla9TimeStamp8NowFuzzyENS_14TimeStamp63BitE+0x22): undefined reference to `__atomic_load_8'
mozglue/misc/TimeStamp.o: In function `mozilla::TimeStamp::UpdateFuzzyTimeStamp(mozilla::TimeStamp)':
TimeStamp.cpp:(.text._ZN7mozilla9TimeStamp20UpdateFuzzyTimeStampES0_+0x28): undefined reference to `__atomic_store_8'
mozglue/misc/TimeStamp.o: In function `mozilla::TimeStamp::NowFuzzyTime()':
TimeStamp.cpp:(.text._ZN7mozilla9TimeStamp12NowFuzzyTimeEv+0x1a): undefined reference to `__atomic_load_8'
mozglue/misc/TimeStamp.o: In function `mozilla::TimeStamp::UpdateFuzzyTime(long long)':
TimeStamp.cpp:(.text._ZN7mozilla9TimeStamp15UpdateFuzzyTimeEx+0x20): undefined reference to `__atomic_store_8'
clang-9: error: linker command failed with exit code 1 (use -v to see invocation)
- llvm90 on 11.2/11.3/12.0/13.0 amd64/i386
- thunderbird, firefox, firefox-esr, cliqz on 11.2 i386
(In reply to Jan Beich from comment #0)
> - thunderbird, firefox, firefox-esr, cliqz on 11.2 i386
Upstream of these doesn't support anything below -march=pentium4 but downstream lowered to -march=i686, see lang/rust/files/patch-src_librustc__target_spec_i686__unknown__freebsd.rs and https://bugzilla.mozilla.org/show_bug.cgi?id=1300843
Ignoring Gecko only 9 ports override CC/CXX to use devel/llvm90:
- comms/gnuradio (skipped due to BROKEN in comms/uhd)
- graphics/pcl-pointclouds (BROKEN, related to libatomic)
- science/erkale (BROKEN, related to libatomic)
I do intend to land this at the end of the week per maintainer timeout. Other than LLVM_DEFAULT some users also build everything with a compiler from ports (usually, on old releases).
Let the best not be the enemy of the good.
Please let me land this. I'll aim to do it by the end of the week. I'd like to roll it up with other changes to reduce the number of times people have to rebuild llvm.
Would "roll it up with other changes" prevent MFH to 2019Q4? Other than the future 9.0.1 almost everything will have low risk to go under ports-secteam blanket (reliability/regression fixes).
(In reply to Jan Beich from comment #4)
This would be merging fixes to crashes so the sort of thing that should be MFH.
A commit references this bug:
Date: Wed Oct 9 20:36:06 UTC 2019
New revision: 514194
Rollup of fixes since the 9.0.0 release.
- Change the default -march for i386 from i486 to i586. This avoids
the need for libatomics and had been the defacto default for some
- Add -m(no)-spe to clang. (powerpc)
- Deduce MIPS specific ELF header flags from `emulation`. (mips)
- Fix a variety of assertions and compile/link errors including crashes
with CPUTYPE=haswell. 
- Switch back to https for downloads. 
The new patches were initially committed to FreeBSD src by dim@.
PR: 240918 , 240759 , 240870 
Reported by: jbeich [0,1], Miyashita Touka <email@example.com> 
A commit references this bug:
Date: Thu Oct 10 00:44:58 UTC 2019
New revision: 514199
gecko: drop LLVM_DEFAULT workaround for i386 after r514194