PF4Public / gentoo-overlay

Personal Gentoo overlay
80 stars 20 forks source link

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

Open mrnoname1000 opened 7 months ago

mrnoname1000 commented 7 months ago

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 commented 7 months ago

Right now it is kind of hardcoded here: https://github.com/PF4Public/gentoo-overlay/blob/9f611c84ea815bddf02198ef359e4bee9e26c0df/www-client/ungoogled-chromium/ungoogled-chromium-123.0.6312.105_p1.ebuild#L1377

How would you imagine this could be changed?

mrnoname1000 commented 7 months ago

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 commented 7 months ago

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