www-client/ungoogled-chromium: Allow specifying linker thread count

[mrnoname1000]

My desktop has 8 cores/16 threads so my MAKEOPTS is set to -j16, but when linking chromium with thinlto enabled, the 32GB of RAM eventually fills up. Could you add an environment variable or other way to specify how many linker threads should be used?

Also, QtWebengine's pre-emerge check multiplies makeopts_jobs by an estimate of the compiler's RAM usage, which if implemented here would prevent the OOM I encountered.

[PF4Public]

Right now it is kind of hardcoded here:

gentoo-overlay/www-client/ungoogled-chromium/ungoogled-chromium-123.0.6312.105_p1.ebuild

Line 1377 in 9f611c8

append-ldflags "-Wl,--thinlto-jobs=$(makeopts_jobs)"

How would you imagine this could be changed?

[mrnoname1000]

Upon further examination I think the simplest solution would be to scan LDFLAGS for the relevant flag. The value of the flag would probably need to be parsed out if the aforementioned pre-emerge check is implemented, but it would be an easy change to skip the append-ldflags call. I'm not very familiar with the ebuild infrastructure, but [[ " $LDFLAGS " =~ [[:space:]]-Wl,--thinlto-jobs=([[:digit:]]+|all)[[:space:]] ]] should do the trick. $BASH_REMATCH[1] can be used to grab the value too.

As the user, I would modify LDFLAGS like so:

# /etc/portage/package.env
www-client/ungoogled-chromium thinlto-jobs.conf

# /etc/portage/env/thinlto.jobs.conf
LDFLAGS="$LDFLAGS --Wl,--thinlto-jobs=8"

Alternatively, a dedicated environment variable could be used (like LTOTHREADS or something) but I'm not aware of any existing convention for this.

[mrnoname1000]

Just realized -flto=n could also be grepped to avoid the Clang-specific flag. Everything else I mentioned should still apply.