Created attachment 667643 [details] failing build log Linux5.9_x86_64_x86_64-pc-linux-gnu-gcc_glibc_PTH_64_OPT.OBJ/tls13hkdf.o:tls13hkdf.c:function tls13_HkdfExtract: error: undefined reference to 'PK11_ImportDataKey' collect2: error: ld returned 1 exit status make[4]: *** [../../coreconf/rules.mk:204: Linux5.9_x86_64_x86_64-pc-linux-gnu-gcc_glibc_PTH_64_OPT.OBJ/libssl3.so] Error 1 make[4]: Leaving directory '/tmp/portage/dev-libs/nss-3.58/work/nss-3.58/nss-abi_x86_64.amd64/lib/ssl' make[3]: *** [../coreconf/rules.mk:44: ssl] Error 2 This is with USE="cacert -utils", gold linker by default. Failing build log attached, emerge info nss to be attached.
Blocking the security stabilization bug (amd64).
Created attachment 667646 [details] emerge --info nss
USE="cacert utils" doesn't solve it. Turning off gold in MAKEOPTS and LDFLAGS doesn't solve it. Neither does MAKEOPTS with -j1. nss-3.57 still emerges fine (previous date on it Sep 30, FWIW), so system changes here aren't at fault, it's what's new in 3.58.
Unblocking, not a general problem. Try, - Building without CCACHE - MAKEOPTS=-j1
(In reply to Thomas Deutschmann from comment #4) > Try, > > - Building without CCACHE > - MAKEOPTS=-j1 I'd already tried MAKEOPTS=-j1, and just tried with ccache disabled (verified by watching the ccache -s stats not change while building), doesn't change the problem.
So the mozilla homepage from the ebuild apparently hadn't been updated with the nss-3.58 release notes yet, nor could I find anything with a nice list of changes in the links I browsed from there. However, duckduck pointed me at the freebsd ports nss page, which had the release and a link to the release notes. =:^) https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.58_release_notes From there, this bug looks related as PK11_ImportDataKey is the undefined reference in my error: Bug 1667153 - Add PK11_ImportDataKey for data object import. https://bugzilla.mozilla.org/show_bug.cgi?id=1667153 And here's the implementing patch attached to that bug, which is thus likely to be the triggering patch for this bug. https://hg.mozilla.org/projects/nss/rev/8fdbec414ce239ab243b929df9c0c9724b7daa20 At least it touches the tls13hkdf.c file mentioned in the error. Hmm... I wonder if it's LDFLAGS related? I haven't had enough errors there to worry about it normally, and haven't tested them yet for this bug. YES, LDFLAGS related! This fails: LDFLAGS="-Wl,-z,now,-z,relro,--as-needed,-O1,--hash-style=gnu,--sort-common,--enable-new-dtags -L/usr/lib64" This works: LDFLAGS="-Wl,-O1,--hash-style=gnu,--sort-common,--enable-new-dtags" So it's one of: -z,now -z,relro --as-needed -L/usr/lib64 (The last was added to work around some other bug.) Going to try the various combinations now, but at least it's pinned down to one of those in LDFLAGS, now. That's major progress so posting it as-is.
(In reply to Duncan from comment #6) > YES, LDFLAGS related! > So it's one of: > -z,now > -z,relro > --as-needed > -L/usr/lib64 Added them all back one at a time and now can't reproduce. =:^( I suspect it was circular dependency issues due to -z,now. Probably nearing a decade ago now, I had a similar problem with xorg (maybe even xfree86 it's been so long, certainly before KMS so X's video drivers were more complicated back then), and the xf86-video-radeon driver. I didn't understand what the gentoo/X folks did to fix it, but I noted it as a circular dependency issue with -z,now back then, and looking at that new code in multiple files for this bug rubbed my nose in the circular dependency element and tickled my memory of it. If so, hardened users, along with "semi-hardened" users like me, are likely to trigger it. Frustrating that I can't reproduce any longer. I'd close this myself as WORKSFORME or INVALID, but I suspect that'd just leave it for hardened to trip over, so I'll leave it up to the devs. Regardless, there's some info here to help the next person that trips over it. From my end feel free to close. PEBKAC/INVALID's fine if you wish.
