Bug 721626 – >=www-client/firefox-76.0-r1 fails to compile with: srtp/src/crypto/cipher/aes_gcm_nss.c:274:15: error: 'CK_GCM_PARAMS' {aka 'struct CK_GCM_PARAMS'} has no member named 'ulIvBits'

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description tt_1 2020-05-08 12:20:08 UTC]

Created attachment 636832 [details]
compressed build log from arm

this is plain ebuild from tree, without any modifications

=www-client/firefox-76.0 was okay

[Comment 1 tt_1 2020-05-08 12:21:38 UTC]

Created attachment 636834 [details]
output from emerge --info

[Comment 2 tt_1 2020-05-08 12:47:17 UTC]

I think it's this patch from the patchset causing the problem: 0026-bmo-1624128-Update-CK_GCM_PARAMS-uses-for-PKCS11-v3..patch

I've got the same issue with firefox-77.0_beta2, where this patch is backported from, and so I assume this fix is incomplete. I'll try to discuss this with upstream and report back.

[Comment 3 tt_1 2020-05-08 14:01:50 UTC]

I got this answer from upstream, a direct quote from #1624128

"Please see the note added in https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.52_release_notes (in Notable Changes). If you still think there's an issue, a new bug would be appropriate.

This is more likely a build/configuration issue causing Firefox to pull in a pre-3.52 version of NSS."

reading through the release notes, it seems to be kind of an api breakage that happened here and is now causing problems?

[Comment 4 Thomas Deutschmann (RETIRED) 2020-05-08 14:33:32 UTC]

First I'd like to understand why you see this only on arm and why we don't hit this on amd64.

And please tell us against which nss version you are building.

[Comment 5 tt_1 2020-05-08 14:38:01 UTC]

sure, here's my crypto stuff for arm

[ebuild   R   ~] dev-libs/nss-3.52::gentoo to /usr/armv7a-unknown-linux-gnueabihf/ USE="-cacert -utils" 0 KiB
[ebuild   R    ] dev-libs/nspr-4.25::gentoo to /usr/armv7a-unknown-linux-gnueabihf/ USE="-debug" 0 KiB
[ebuild   R    ] app-crypt/p11-kit-0.23.19-r1::gentoo to /usr/armv7a-unknown-linux-gnueabihf/ USE="asn1 libffi trust -debug" 0 KiB

the answer to your question is most likely that mozilla doesn't test for arm build failures, so I'm trying to keep up with their pace and report any breakages. 

would you like me to try with nss-3.51.1 instead?

[Comment 6 Armitage 2020-05-08 14:55:12 UTC]

(In reply to Thomas Deutschmann from comment #4)
> First I'd like to understand why you see this only on arm and why we don't
> hit this on amd64.
> 
> And please tell us against which nss version you are building.

I have the same error on amd64. Is there any information that I can provide in order to find the problem?

My nss version is:

dev-libs/nss-3.51.1

[Comment 7 Armitage 2020-05-08 14:56:47 UTC]

Those are the USE flags that are enabled for firefox in my sistem: clang gmp-autoupdate hwaccel lto pgo pulseaudio screenshot startup-notification system-av1 system-harfbuzz system-icu system-jpeg system-libevent system-libvpx system-webp wayland.

[Comment 8 tt_1 2020-05-08 15:05:19 UTC]

As you mention it, I forgot to paste my useflags: 

Calculating dependencies... done!
[ebuild    U  *] www-client/firefox-76.0.1::gentoo [76.0::gentoo] to /usr/armv7a-unknown-linux-gnueabihf/ USE="hwaccel lto system-harfbuzz system-icu system-jpeg system-libevent system-libvpx system-webp -bindist -clang -custom-cflags -custom-optimization -debug (-eme-free) -geckodriver -gmp-autoupdate (-hardened) -jack (-pgo) -pulseaudio -screenshot (-selinux) -startup-notification -system-av1 -test -wayland -wifi" CPU_FLAGS_ARM="neon" L10N="de -ach -af -an -ar -ast -az -be -bg -bn -br -bs -ca -cak -cs -cy -da -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 -nl -nn -oc -pa -pl -pt-BR -pt-PT -rm -ro -ru -si -sk -sl -son -sq -sr -sv -ta -te -th -tr -uk -ur -uz -vi -xh -zh-CN -zh-TW" 0 KiB

Total: 1 package (1 reinstall), Size of downloads: 0 KiB

downgrading nss to 3.51.1 doesn't help

[Comment 9 Armitage 2020-05-08 15:05:51 UTC]

(In reply to tt_1 from comment #3)
> I got this answer from upstream, a direct quote from #1624128
> 
> "Please see the note added in
> https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.
> 52_release_notes (in Notable Changes). If you still think there's an issue,
> a new bug would be appropriate.
> 
> This is more likely a build/configuration issue causing Firefox to pull in a
> pre-3.52 version of NSS."
> 
> reading through the release notes, it seems to be kind of an api breakage
> that happened here and is now causing problems?

I didn't see that comment. Sorry for the noise... I'm recompiling with nss-3.52 and let you know the result.

[Comment 10 Jan Vesely 2020-05-08 15:09:42 UTC]

I can confirm that using dev-libs/nss fixes the issue on amd64.
It looks like said patch bumps the nss requirement.

[Comment 11 Jan Vesely 2020-05-08 15:10:26 UTC]

(In reply to Jan Vesely from comment #10)
> I can confirm that using dev-libs/nss fixes the issue on amd64.
> It looks like said patch bumps the nss requirement.

=dev-libs/nss-3.52

[Comment 12 Thomas Deutschmann (RETIRED) 2020-05-08 16:32:13 UTC]

This bug is already confusing.

For the records: It is important which nss version is/was present *during* firefox build time.

For anyone getting build failures/do tests please report

1) arch
2) used nss version during build

[Comment 13 tt_1 2020-05-08 16:43:52 UTC]

the build fails for firefox-76.0.1 with these configs: 

1) arm (target), amd64 (host)
2) nss-3.52 (target), nss-3.51.1 (host)
2) nss-3.51.1 (target), nss-3.51.1 (host)

[Comment 14 Armitage 2020-05-08 17:41:54 UTC]

(In reply to Jan Vesely from comment #11)
> (In reply to Jan Vesely from comment #10)
> > I can confirm that using dev-libs/nss fixes the issue on amd64.
> > It looks like said patch bumps the nss requirement.
> 
> =dev-libs/nss-3.52

I can confirm it too.

[Comment 15 Armitage 2020-05-08 17:45:32 UTC]

(In reply to tt_1 from comment #13)
> the build fails for firefox-76.0.1 with these configs: 
> 
> 1) arm (target), amd64 (host)
> 2) nss-3.52 (target), nss-3.51.1 (host)
> 2) nss-3.51.1 (target), nss-3.51.1 (host)

It's like your libraries are getting mixed between the host and the target, what could indicate a wrong configuration or that something is broken. What's the result if you compile firefox with nss-3.52 in both (target and host)?

[Comment 16 Armitage 2020-05-08 17:53:28 UTC]

In addition, be sure that the include path is correct in target. Is it possible that the target uses the include path (/usr/include/nss/) of the host?

[Comment 17 Thomas Deutschmann (RETIRED) 2020-05-08 18:55:46 UTC]

I can reproduce with nss-3.51.1 on amd64 so I plan to require 3.52.

[Comment 18 tt_1 2020-05-08 19:01:37 UTC]

Ok, great, I think the additional confusion came from some sort of header missmatch with cross compiling. Please don't take any further actions with that, as this is a really fragile setup. 

In short, the nss versions of host and target need to be both the same, which wasn't obvious as I got away with mixing them in the past.

[Comment 19 Toralf Förster 2020-05-08 19:42:56 UTC]

>=nss-3.52 is needed at hardened amd64 IMO

[Comment 20 Thomas Deutschmann (RETIRED) 2020-05-08 19:46:50 UTC]

The patch will require 3.52+ everywhere.

[Comment 21 Larry the Git Cow 2020-05-08 19:48:38 UTC]

The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=52318536c7457a13f4e4eca4927916807573dc24

commit 52318536c7457a13f4e4eca4927916807573dc24
Author:     Thomas Deutschmann <[e-mail]>
AuthorDate: 2020-05-08 19:47:24 +0000
Commit:     Thomas Deutschmann <[e-mail]>
CommitDate: 2020-05-08 19:47:42 +0000

    www-client/firefox: require dev-libs/nss-3.52
    
    Closes: https://bugs.gentoo.org/721626
    Package-Manager: Portage-2.3.99, Repoman-2.3.22
    Signed-off-by: Thomas Deutschmann <[e-mail]>

 www-client/firefox/firefox-76.0-r1.ebuild | 2 +-
 www-client/firefox/firefox-76.0.1.ebuild  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)