Summary: | >=dev-libs/nss-3.66: fails to emerge - multiple make targets? | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Mike Benson <mike> |
Component: | Current packages | Assignee: | Mozilla Gentoo Team <mozilla> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | dev, sam |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Build log |
Description
Mike Benson
2021-06-24 00:37:32 UTC
Created attachment 718401 [details]
Build log
I have a question - why is the ebuild so different from the build process (gyp -> ninja) documented by Mozilla? Doesn't that make things hard for us? I get the same with version 3.68.1: make[4]: Entering directory '/tmp/portage/dev-libs/nss-3.68.1/work/nss-3.68.1/nss-abi_x86_64.amd64/lib/nss' ../../coreconf/rules.mk:202: *** multiple target patterns. Stop. make[4]: Leaving directory '/tmp/portage/dev-libs/nss-3.68.1/work/nss-3.68.1/nss-abi_x86_64.amd64/lib/nss' make[3]: *** [../coreconf/rules.mk:44: nss] Error 2 make[3]: Leaving directory '/tmp/portage/dev-libs/nss-3.68.1/work/nss-3.68.1/nss-abi_x86_64.amd64/lib' make[2]: *** [coreconf/rules.mk:44: lib] Error 2 make[2]: Leaving directory '/tmp/portage/dev-libs/nss-3.68.1/work/nss-3.68.1/nss-abi_x86_64.amd64' make[1]: *** [manifest.mn:26: prepare_build] Error 2 make[1]: Leaving directory '/tmp/portage/dev-libs/nss-3.68.1/work/nss-3.68.1/nss-abi_x86_64.amd64' make: *** [Makefile:53: nss_build_all] Error 2 make: Leaving directory '/tmp/portage/dev-libs/nss-3.68.1/work/nss-3.68.1/nss-abi_x86_64.amd64' [31;01m*[0m ERROR: dev-libs/nss-3.68.1::gentoo failed (compile phase): [31;01m*[0m emake failed [31;01m*[0m [31;01m*[0m If you need support, post the output of `emerge --info '=dev-libs/nss-3.68.1::gentoo'`, [31;01m*[0m the complete build log and the output of `emerge -pqv '=dev-libs/nss-3.68.1::gentoo'`. [31;01m*[0m The complete build log is located at '/var/log/portage/ebuilds/dev-libs:nss-3.68.1:20220106-090019.log'. [31;01m*[0m For convenience, a symlink to the build log is located at '/tmp/portage/dev-libs/nss-3.68.1/temp/build.log'. [31;01m*[0m The ebuild environment file is located at '/tmp/portage/dev-libs/nss-3.68.1/temp/environment'. [31;01m*[0m Working directory: '/tmp/portage/dev-libs/nss-3.68.1/work/nss-3.68.1/nss-abi_x86_64.amd64' [31;01m*[0m S: '/tmp/portage/dev-libs/nss-3.68.1/work/nss-3.68.1/nss' Dear All, I was looking at nss's website (https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Building), and saw a recommendetion to have gyp installed. So, I merged dev-util/gyp and retried dev-libs/nss. It went through and successfully merged. Maybe it's worth investigating nss<->gyp relations and/or add gyp to the build deps? Yep, it's definitely worth a try. There's this warning message in nss's readme: **This build system is under development. It does not yet support all the features or platforms that NSS supports. To build on anything other than Mac or Linux please use the legacy build system as described below.** But it does sound like it's ready-to-go on linux... I'll investigate the switch to 3.75 _latest_, but for now, I'd like to keep the ESR-3.68.2 building with legacy make. With 3.75 out, let's try to convert it to gyp. Okay I've got something, but since this will most likely break on arches I can't test this on, need to re-request keywording (which to be honest was expected when migrating build systems). And since Firefox-97 will most likely require 3.75 I believe it's best to push 3.75 using GNU make, and work on gyp-ebuild getting support in parallel. I.e. do maybe a masked 3.75-r10 gyp release to be keyworded and tested separately. (In reply to Joonas Niilola from comment #7) > Okay I've got something, but since this will most likely break on arches I > can't test this on, need to re-request keywording (which to be honest was > expected when migrating build systems). And since Firefox-97 will most > likely require 3.75 I believe it's best to push 3.75 using GNU make, and > work on gyp-ebuild getting support in parallel. I.e. do maybe a masked > 3.75-r10 gyp release to be keyworded and tested separately. Fair enough but note that you only need to worry about a handful of arches anyway for Firefox, not the full NSS arch set, which is used for other packages Thanks for looking into this! |