dev-libs/nss-3.107 missing 'endif'

[ian848uig]

Hi everyone, since a week ago I have a problem with nss version 3.107 failing because of missing endif, I tried compiling version 3.106 and recompiling version 3.105, but it gives the same error.
I tried to add the missing endif in the file on line 53, but portage deletes the directory (theoretically) when I try to re-emerge nss, which makes adding the missing line useless.
output:

https://pastebin.com/7NwCyyH8

and

https://pastebin.com/jmYqDWg6

NOTE: GCC14 downgraded it from 14.3.9999 to 20241123 (the problem still persists), the error is the same, it was not necessary to copy and paste the recent output again.

Mod edit: URLs made clickable. — JRG
_________________
I like everything that is Linux, free and open source software. I am a teenager

[John R. Graham]

Looks like you've remove a hard mask from dev-build/make-9999. I'd try to downgrade back to current stable make and then retry building nss.

- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters.

[ian848uig]

So, could it be a make problem, not a GCC problem?
_________________
I like everything that is Linux, free and open source software. I am a teenager

[John R. Graham]

Yes it could. dev-libs/nss-3.107 builds successfully here with sys-devel/gcc-14.2.1_p20241116.

I was trying to reproduce your problem by building make-9999, but it wouldn't build for me, so I didn't get that far. Still, it's the likely culprit: things are generally hard masked for a reason.

- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters.

[ian848uig]

it works, I degrade make and it works and in 30 seconds (approximately) dev-libs/nss was compiled and installed.

[sam_]

If running various things from git - which can be helpful testing and rather educational, please do (and I mean this in a sincere, constructive way) "learn to debug". This is similar to http://www.catb.org/esr/faqs/smart-questions.html and also https://xyproblem.info/, but especially https://stackoverflow.com/help/minimal-reproducible-example

The difference between a mess and something actionable is whether you can try narrow down which component caused it, and then start to poke at extracting an example. Otherwise, it's just a very confused, very broken computer

In your situation, I would (ignoring that I'd probably preserve the directory and so on first) clone NSS manually and copy what the ebuild does to see if i can reproduce it. Then I can rule out the ebuild being at fault. And so on. You would soon end up hopefully with a testcase Makefile that either shows something NSS is doing wrong in its Makefiles, or a clear indicator that it's a GNU Make bug.

I would also say it should be obvious to try downgrade Make if you know you're using make from git and you're getting an error in a Makefile. If that isn't obvious, try to narrow down what is experimental about your system until this sort of investigative approach feels more comfortable to you. (For example, if you're running so much on your system from git that it wasn't at least somewhat obvious to try downgrade Make, that might be a sign you're doing too much.)

But you can get there and this post is not intended as a telling off -- just trying to give advice on doing what you're doing in a more rewarding way (for you and others).

[Hu]

ian848uig: why did you have a live ebuild of GNU make installed? If you're doing it to test compatibility or to learn, as sam_ mentioned, then that is fine. Live ebuilds can be more trouble than well tested ones, so if you don't have a specific reason why you have a live ebuild installed, then you probably should not have it installed because of the likelihood that you are causing trouble for yourself.