Created attachment 929980 [details] Output of `emerge --info nss` Attempting to emerge nss 3.112 results in the following error: ``` make: Entering directory '/var/tmp/portage/dev-libs/nss-3.112/work/nss-3.112/nss-.arm64/coreconf' ../coreconf/tree.mk:53: *** missing 'endif'. Stop. ``` If it matters, I am using an M1 Macbook Air with the Asahi kernel.
Attach the full build log. If it's too big - compress it with xz.
What I put the message is basically it. I'll attach the whole thing though if that's helpful.
Created attachment 929981 [details] Build log for `emerge -1 nss`
Always try without ccache if it fails with ccache.
It also fails without ccache.
For completions sake, could the build.log without ccache be posted here? That error does look ccache-related. Upgrading works on my amd64 so might be arm64-related too somehow.
Created attachment 929982 [details] Build log for `emerge -1 nss` with no ccache
I just discovered by accident that this issue also occurs on my AMD64 desktop computer, which is being run completely independently of my M1. It fails with the same error: ``` make -j14 -C coreconf 'CC=x86_64-pc-linux-gnu-gcc -m32 -mfpmath=sse' make: Entering directory '/var/tmp/portage/dev-libs/nss-3.112/work/nss-3.112/nss-abi_x86_32.x86/coreconf' ../coreconf/tree.mk:53: *** missing 'endif'. Stop. ```
Could you upload tree.mk as an attachment and paste a few lines around line 53 here? Thanks.
The file is only 52 lines long. I will post the whole file as it is on my AMD64 computer.
Created attachment 929990 [details] coreconf/tree.mk from nss 3.112
Please share the output of `env`.
Created attachment 929991 [details] Output of `env`
Huh, that looks fine, you don't have any weird env vars set matching $(XYZ) in the Makefile, and when I use the Makefile and try inject things, it works fine. Could you include the environment file at: [31;01m*[0m The ebuild environment file is located at '/var/tmp/portage/dev-libs/nss-3.112/temp/environment'.
Created attachment 929992 [details] /var/tmp/portage/dev-libs/nss-3.112/temp/environment
If https://github.com/nss-dev/nss/compare/NSS_3_111_RTM...NSS_3_112_RTM is the right link, very little changed here...
Does nss-3.111 really build fine for you if you try again now?
Ah, nss 3.111 is also failing even though it's already installed on my system. Something else must've changed. Any idea what that could be?
(In reply to opensauce04 from comment #18) > Ah, nss 3.111 is also failing even though it's already installed on my > system. Something else must've changed. Any idea what that could be? Anything interesting happened recently on your system? Changed anything (e.g. CFLAGS)? Had a weird poweroff or something? Could you try rebuild dev-build/make?
Oh wait! I know what caused it. A while ago I emerged the 9999 package for GNU Make to try out a new feature, and I never removed the package.accept_keywords entry. Up until now this has never affected anything, but after downgrading to the latest release of Make, NSS is now building successfully. As such, this appears to be a symptom of some breaking change in Make which hasn't made its way into a release yet.
FWIW, it's equally possible it's a Make bug as well. You could try reduce that Makefile you pasted here and reproduce it with `make -f foo` and see if you can get it to fail if you add some basic rule like `all:\n\techo hi`, and then report it upstream if so.
I've managed to create an incredibly minimal reproduction of the issue. I will look into reporting this upstream to the Make developers shortly. Seeing as this isn't related to NSS itself, this issue should probably be closed. I'm not sure what category of "resolved" this situation falls under, so I'll leave that to you.
(In reply to opensauce04 from comment #22) > I've managed to create an incredibly minimal reproduction of the issue. Not sharing it here? > I > will look into reporting this upstream to the Make developers shortly. > Seeing as this isn't related to NSS itself, this issue should probably be > closed. Thanks. Please share a link when done. > > I'm not sure what category of "resolved" this situation falls under, so I'll > leave that to you. Let's call it WORKSFORME.
I bisected and the bad commit is: https://cgit.git.savannah.gnu.org/cgit/make.git/commit/?id=07fcee35f058a876447c8a021f9eb1943f902534 Of course whether this is really a bad change or intended and the real fault is with the nss makefiles might be a different issue, but at least you can point to a commit when reporting upstream. :) It's here: https://savannah.gnu.org/projects/make
> Not sharing it here? This is the repro I came up with: Makefile ``` ifeq (a, b) #noop else ifeq (a, b) #noop else #noop endif endif all: - echo This works ```
(In reply to opensauce04 from comment #25) > > Not sharing it here? > > This is the repro I came up with: > > Makefile > ``` > ifeq (a, b) > #noop > else > ifeq (a, b) > #noop > else > #noop > endif > endif > > all: > - echo This works > ``` Actually this can be simplified even further: Makefile ``` ifeq (a, b) #noop else ifeq (a, b) #noop endif endif all: - echo This works ``` The nested if seemingly needs to be inside the `else` for the error to occur.
I have created a bug report for this in the Make issue tracker: https://savannah.gnu.org/bugs/index.php?67168
