| View previous topic :: View next topic |
| Author |
Message |
jpsollie
Guru
Joined: 17 Aug 2013
Posts: 323
|
 Posted: Mon Sep 30, 2024 7:55 am Post subject: |
 |
|
| logrusx wrote: | | jpsollie wrote: |
*EDIT* : I assume you meant --builtpkgonly. |
| man emerge: | --buildpkg [ y | n ], -b
Tells emerge to build binary packages for all ebuilds processed in addition to actually merging the packages. Useful for maintainers or if you administrate multiple Gentoo Linux systems (build
once, emerge tbz2s or gpkgs everywhere) as well as disaster recovery. The package will be created in the PKGDIR directory (see make.conf(5)). An alternative for already-merged packages is to use
quickpkg(1) which creates a tbz2 or gpkg from the live filesystem.
...
--buildpkgonly, -B
Creates binary packages for all ebuilds processed without actually merging the packages. This comes with the caveat that all build-time dependencies must already be emerged on the system.
|
Buildpkgonly will break because portage needs the packages merged to link against them. Essentially you'll have almost identical copy of your laptop's system in that chroot. I think you could even synchronize it with rsync but it would be easier if you used binary packages.
Also, why are you not able to run emerge or compile distcc on the build server? How did you built it first place? It doesn't require gui. Only ssh.
Best Regards,
Georgi |
The build server is fine. However: it has no GUI and I'd like to keep it that way.
Compiling qtwebengine into a binary package requires some compile-time dependencies which need to be installed before the package can be compiled, eg qtbase.
If I need to install all this junk onto a no-gui system, binary packages may indeed be the fastest way out
_________________
The power of Gentoo optimization (not overclocked): [img]https://www.passmark.com/baselines/V10/images/503714802842.png[/img] |
|
| Back to top |
|
 |
jpsollie
Guru
Joined: 17 Aug 2013
Posts: 323
|
| Posted: Mon Sep 30, 2024 10:09 am Post subject: |
|
|
| Zucca wrote: | | Quote: | | Code: | | distcc[3974] (dcc_execvp) ERROR: failed to exec x86_64-pc-linux-gnu-g++: Argument list too long |
|
I think this a is bug. Bug in the upstream build process or in distcc.
It's quite rare to reach this limit. I mean, I think it's something like 2 megabytes or more arguments until this error is triggered. |
building without distcc took 6hrs, but compiled.
so far, so good.
Can the feature flag for distcc be turned off for a specific package?
_________________
The power of Gentoo optimization (not overclocked): [img]https://www.passmark.com/baselines/V10/images/503714802842.png[/img] |
|
| Back to top |
|
|
Goverp
Advocate
Joined: 07 Mar 2007
Posts: 2179
|
| Posted: Mon Sep 30, 2024 10:48 am Post subject: |
|
|
<Aside - as I've not followed this discussion - the problems with command line too long might be down to jumbo-build.
It might be worth creating an env file specifying: | Code: | | EXTRA_GN='jumbo_file_merge_limit=16' |
The law of diminishing returns applies for this>
_________________
Greybeard |
|
| Back to top |
|
|
jpsollie
Guru
Joined: 17 Aug 2013
Posts: 323
|
| Posted: Mon Sep 30, 2024 11:02 am Post subject: |
|
|
| Goverp wrote: | <Aside - as I've not followed this discussion - the problems with command line too long might be down to jumbo-build.
It might be worth creating an env file specifying: | Code: | | EXTRA_GN='jumbo_file_merge_limit=16' |
The law of diminishing returns applies for this> |
would this also be useful when the jumbo_build flag isn't set?
_________________
The power of Gentoo optimization (not overclocked): [img]https://www.passmark.com/baselines/V10/images/503714802842.png[/img] |
|
| Back to top |
|
|
logrusx
Advocate
Joined: 22 Feb 2018
Posts: 2435
|
| Posted: Mon Sep 30, 2024 12:05 pm Post subject: |
|
|
| jpsollie wrote: | | Goverp wrote: | <Aside - as I've not followed this discussion - the problems with command line too long might be down to jumbo-build.
It might be worth creating an env file specifying: | Code: | | EXTRA_GN='jumbo_file_merge_limit=16' |
The law of diminishing returns applies for this> |
would this also be useful when the jumbo_build flag isn't set? |
This is a parameter to jumbo built. It won't matter when jumbo is not enabled.
I'm curious, what are your arguments against building in a chroot. What are your arguments against using the binhost.
You're running circles around those and very rarely state your reasons.
Best Regards,
Georgi |
|
| Back to top |
|
|
jpsollie
Guru
Joined: 17 Aug 2013
Posts: 323
|
| Posted: Mon Sep 30, 2024 1:26 pm Post subject: |
|
|
| logrusx wrote: | | jpsollie wrote: | | Goverp wrote: | <Aside - as I've not followed this discussion - the problems with command line too long might be down to jumbo-build.
It might be worth creating an env file specifying: | Code: | | EXTRA_GN='jumbo_file_merge_limit=16' |
The law of diminishing returns applies for this> |
would this also be useful when the jumbo_build flag isn't set? |
This is a parameter to jumbo built. It won't matter when jumbo is not enabled.
I'm curious, what are your arguments against building in a chroot. What are your arguments against using the binhost.
You're running circles around those and very rarely state your reasons.
Best Regards,
Georgi |
Not much, actually:
1) for the chroot solution: I am considering it right now as it looks like a clean setup.
I got experience with it for cross-compiling for a nanopi neo3 board running on gentoo. So yes, I'm thinking about it.
2) I'm somewhat concerned about my own binpkg NFS share:
The purpose of my ryzen 5 desktop PC is to build new GUI packages, store them on NFS fileshare and check if they work
If they are working in the config I built (deps, use flags, ...) I can push them to my laptops using usepkgonly.
I'm somewhat concerned that use flags I didn't want are sneaking through, ending with a completely different setup
_________________
The power of Gentoo optimization (not overclocked): [img]https://www.passmark.com/baselines/V10/images/503714802842.png[/img] |
|
| Back to top |
|
|
logrusx
Advocate
Joined: 22 Feb 2018
Posts: 2435
|
| Posted: Mon Sep 30, 2024 1:42 pm Post subject: |
|
|
| jpsollie wrote: |
1) for the chroot solution: I am considering it right now as it looks like a clean setup.
I got experience with it for cross-compiling for a nanopi neo3 board running on gentoo. So yes, I'm thinking about it. |
I don't think you need to cross compile. I should be very much like an installation. Just copy your world, make.conf and package.* and you should be good to go, given that your compile server CPU covers the CPU_FLAGS from make.conf.
| jpsollie wrote: | 2) I'm somewhat concerned about my own binpkg NFS share:
The purpose of my ryzen 5 desktop PC is to build new GUI packages, store them on NFS fileshare and check if they work
If they are working in the config I built (deps, use flags, ...) I can push them to my laptops using usepkgonly.
I'm somewhat concerned that use flags I didn't want are sneaking through, ending with a completely different setup |
I think you can have both binhosts, yours with higher priority over Gentoo binhost and this way use some of the packages, but at a first glance it might prove to be more complicated than it's worth.
On the other hand you can:
the ones you want from Gentoo binhost and then run emerge with k switch which will use the ones in the local cache. Unfortunately there's no easy way to enable/disable one host or another. Maybe manage some symlinks in /etc/portage/binrepos.conf as a way to switch them on or off.
The packages which will benefit you the most are not that many. The problematic qtwebengine, libreoffice, chromium, the compiles and toolchains... You can isolate them to a handful or even just a few. Those will make the biggest difference.
Best Regards,
Georgi |
|
| Back to top |
|
|
eschwartz
Developer
Joined: 29 Oct 2023
Posts: 228
|
| Posted: Mon Sep 30, 2024 2:13 pm Post subject: |
|
|
| jpsollie wrote: | | eschwartz wrote: |
Is it not possible to ssh into the "compiling server" and spawn an emerge job there? If necessary you can even unpack a fresh stage3 tarball, chroot into it, configure it with the same make.conf as you have on your PC, and then use emerge --buildpkg qtwebengine. This is actually more or less what the official binhost does too, except you get to choose exactly what CFLAGS and USE flags you want. Then simply sync (or serve over https) the resulting binaries in /var/cache/binpkgs and load them on the PC.
|
ok ... but what about dependencies like eq qtcore?
*EDIT* : I assume you meant --builtpkgonly. It would be nice if you can pull everything into a chroot for compiling, otherwise you end up with a lot of use flags for dependencies compile-time dependencies on the no-GUI system you don't want... |
buildpkgonly will avoid installing the binpackage into the chroot, which means it doesn't have to satisfy RDEPEND. It doesn't help satisfy build dependencies such as qtcore.
If you install it into a chroot, it is "just" files on disk, and doesn't end up running a GUI on your server, nor starting system services of any sort, etc.
| jpsollie wrote: | | logrusx wrote: |
I'm curious, what are your arguments against building in a chroot. What are your arguments against using the binhost.
You're running circles around those and very rarely state your reasons.
|
Not much, actually:
1) for the chroot solution: I am considering it right now as it looks like a clean setup.
I got experience with it for cross-compiling for a nanopi neo3 board running on gentoo. So yes, I'm thinking about it.
2) I'm somewhat concerned about my own binpkg NFS share:
The purpose of my ryzen 5 desktop PC is to build new GUI packages, store them on NFS fileshare and check if they work
If they are working in the config I built (deps, use flags, ...) I can push them to my laptops using usepkgonly.
I'm somewhat concerned that use flags I didn't want are sneaking through, ending with a completely different setup |
FWIW, USE flags that you don't want can't sneak through since portage treats a binhost as a cache for actions it is already taking and packages it is already intending to install. The cache key consists of all your configured USE flags as well as things like SLOT dependencies. It does *not* include the CFLAGS used -- the binhost project builds two separate binhosts, one with generic -march=x86-64 and one with an optimized -march=x86-64-v3 (check if your system supports the latter, it will be listed in `ld.so --help` if so) -- so if precise CFLAGS matter to you then you may prefer building your own packages rather than use the binhost. But the technology for building your own binhost server and serving binpackages is the same either way, so you will get USE flag consistency either way, and just need to decide on your own CFLAGS compatibility.
If you want to test each package before you push it to laptops, then fetching Gentoo Binhost packages by installing them on the desktop PC would also allow you to test those packages and then re-host them yourself. Note as well that portage 3.0.66 (currently in ~arch) supports "location" in binrepos.conf, so that remotely downloaded *.gpkg.tar end up in a separate, isolated location by default. You could test a downloaded Gentoo Binhost package and then manually move that .gpkg.tar file into /var/cache/binpkgs and run emaint binhost --fix.
Then again, perhaps disabling jumbo builds is enough.  |
|
| Back to top |
|
|
freke
Veteran
Joined: 23 Jan 2003
Posts: 1029
Location: Somewhere in Denmark
|
| Posted: Mon Sep 30, 2024 4:23 pm Post subject: |
|
|
| jpsollie wrote: | | Zucca wrote: | | Quote: | | Code: | | distcc[3974] (dcc_execvp) ERROR: failed to exec x86_64-pc-linux-gnu-g++: Argument list too long |
|
I think this a is bug. Bug in the upstream build process or in distcc.
It's quite rare to reach this limit. I mean, I think it's something like 2 megabytes or more arguments until this error is triggered. |
building without distcc took 6hrs, but compiled.
so far, so good.
Can the feature flag for distcc be turned off for a specific package? |
via /etc/portage/package.env I believe https://wiki.gentoo.org/wiki//etc/portage/package.env
Never used/tried it for FEATURES myself. |
|
| Back to top |
|
|
jpsollie
Guru
Joined: 17 Aug 2013
Posts: 323
|
| Posted: Mon Sep 30, 2024 4:57 pm Post subject: |
|
|
| freke wrote: | | jpsollie wrote: | | Zucca wrote: | | Quote: | | Code: | | distcc[3974] (dcc_execvp) ERROR: failed to exec x86_64-pc-linux-gnu-g++: Argument list too long |
|
I think this a is bug. Bug in the upstream build process or in distcc.
It's quite rare to reach this limit. I mean, I think it's something like 2 megabytes or more arguments until this error is triggered. |
building without distcc took 6hrs, but compiled.
so far, so good.
Can the feature flag for distcc be turned off for a specific package? |
via /etc/portage/package.env I believe https://wiki.gentoo.org/wiki//etc/portage/package.env
Never used/tried it for FEATURES myself. |
I can work with that. Thank you!
Should I report this issue to the distcc or ninja devs?
_________________
The power of Gentoo optimization (not overclocked): [img]https://www.passmark.com/baselines/V10/images/503714802842.png[/img] |
|
| Back to top |
|
|
logrusx
Advocate
Joined: 22 Feb 2018
Posts: 2435
|
| Posted: Mon Sep 30, 2024 5:28 pm Post subject: |
|
|
| jpsollie wrote: |
Can the feature flag for distcc be turned off for a specific package? |
Here's what I used to do back in the days of struggling with old and very worked hardware: https://forums.gentoo.org/viewtopic-p-8195688.html#8195688
You can modify it for distcc.
Best Regards,
Georgi |
|
| Back to top |
|
|
jpsollie
Guru
Joined: 17 Aug 2013
Posts: 323
|
| Posted: Tue Oct 01, 2024 9:21 am Post subject: |
|
|
| logrusx wrote: |
Also, why are you not able to run emerge or compile distcc on the build server? How did you built it first place? It doesn't require gui. Only ssh.
Best Regards,
Georgi |
You must have misunderstood:
The build server is 100% ok. Distcc and emerge are working fine.
I simply do not want to install all build-time dependencies.
That's why I like the idea of chroot so much
_________________
The power of Gentoo optimization (not overclocked): [img]https://www.passmark.com/baselines/V10/images/503714802842.png[/img] |
|
| Back to top |
|
|
Banana
Moderator
Joined: 21 May 2004
Posts: 1737
Location: Germany
|
|
| Back to top |
|
|
jpsollie
Guru
Joined: 17 Aug 2013
Posts: 323
|
| Posted: Tue Oct 01, 2024 10:18 am Post subject: |
|
|
| Banana wrote: | | Quote: | The build server is 100% ok. Distcc and emerge are working fine.
I simply do not want to install all build-time dependencies. |
On the build server?
If yes: Isn't this the point of a build server to have everything needed to build? |
I also use it as a NAS, DNS, DHCP, qemu, cups forwarding and other server processes
_________________
The power of Gentoo optimization (not overclocked): [img]https://www.passmark.com/baselines/V10/images/503714802842.png[/img] |
|
| Back to top |
|
|
NichtDerHans
Apprentice
Joined: 27 Jan 2023
Posts: 177
|
| Posted: Tue Oct 01, 2024 11:14 am Post subject: |
|
|
| jpsollie wrote: | I also thought of distcc this time ...
It's hard: the PC itself is only a ryzen 5 device while the "compiling server" is a 64 core threadripper with no gui.
|
[X] chroot
export the ryzen / to nfs
ssh to threadripper
mount the ryzen /
chroot into ryzen from threadripper over ssh
Faster as distcc |
|
| Back to top |
|
|
logrusx
Advocate
Joined: 22 Feb 2018
Posts: 2435
|
| Posted: Tue Oct 01, 2024 2:49 pm Post subject: |
|
|
| NichtDerHans wrote: | | jpsollie wrote: | I also thought of distcc this time ...
It's hard: the PC itself is only a ryzen 5 device while the "compiling server" is a 64 core threadripper with no gui.
|
[X] chroot
export the ryzen / to nfs
ssh to threadripper
mount the ryzen /
chroot into ryzen from threadripper over ssh
Faster as distcc |
Is that OK on a live system? I think portage does practically the same, but I don't know if it takes additional measures against possible issues related to that.
Best Regards,
Georgi |
|
| Back to top |
|
|
Zucca
Moderator
Joined: 14 Jun 2007
Posts: 3708
Location: Rasi, Finland
|
| Posted: Tue Oct 01, 2024 3:09 pm Post subject: |
|
|
Just for "fun", I set my low-end box with dual core celeron to compile qtwebengine.
nodejs already took over 7h to complete…
EDIT: And after | Code: | real 51m39.393s
user 92m7.575s
sys 6m10.725s |
... it failed.
| Code: | Error: Cannot find module '/qtwebengine-everywhere-src-6.7.2/src/3rdparty/chromium/third_party/devtools-frontend/src/sc
ripts/build/ninja/copy-files.js'
at Module._resolveFilename (node:internal/modules/cjs/loader:1219:15)
at Module._load (node:internal/modules/cjs/loader:1045:27)
at TracingChannel.traceSync (node:diagnostics_channel:315:14)
at wrapModuleLoad (node:internal/modules/cjs/loader:215:24)
at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:158:5)
at node:internal/main/run_main_module:30:49 {
code: 'MODULE_NOT_FOUND',
requireStack: []
} |
... seems like a relevant part of the log.
Yeah. I can see why it's so frustrating.
_________________
..: Zucca :..
| My gentoo installs: | init=/sbin/openrc-init
-systemd -logind -elogind seatd |
| Quote: | | I am NaN! I am a man! |
|
|
| Back to top |
|
|
jpsollie
Guru
Joined: 17 Aug 2013
Posts: 323
|
| Posted: Tue Oct 01, 2024 6:22 pm Post subject: |
|
|
| NichtDerHans wrote: | | jpsollie wrote: | I also thought of distcc this time ...
It's hard: the PC itself is only a ryzen 5 device while the "compiling server" is a 64 core threadripper with no gui.
|
[X] chroot
export the ryzen / to nfs
ssh to threadripper
mount the ryzen /
chroot into ryzen from threadripper over ssh
Faster as distcc |
yeah ... or simply rsync all relevant config files (package.use, package.accept_keywords, ...) into a stage 3 tarball at /usr/x86_64-compiler-linux-gnu/, and let the threadripper mirror the complete OS.
This magick will work:
| Code: |
mount -o rbind /proc /usr/x86_64-compiler-linux-gnu/proc/
mount -o rbind /sys /usr/x86_64-compiler-linux-gnu/sys
mount -o rbind /dev /usr/x86_64-compiler-linux-gnu/dev
mount -o rbind var/cache/distfiles /usr/x86_64-compiler-linux-gnu/var/cache/distfiles
mount -o rbind var/cache/binpkgs /usr/x86_64-compiler-linux-gnu/var/cache/binpkgs
screen chroot /usr/x86_64-compiler-linux-gnu/ /bin/sh
emerge -eav @system @world
|
... and shutdown the client ryzen PC while the threadripper compiles everything painful (libreoffice, qtwebengine, firefox, thunderbird, you name it ...)
I think this is a better solution in a binpkg world, as you don't need to export / on a client (but off course /usr/x86_64-compiler-linux-gnu/ will be fat)
_________________
The power of Gentoo optimization (not overclocked): [img]https://www.passmark.com/baselines/V10/images/503714802842.png[/img] |
|
| Back to top |
|
|
NichtDerHans
Apprentice
Joined: 27 Jan 2023
Posts: 177
|
| Posted: Wed Oct 02, 2024 4:29 am Post subject: |
|
|
| logrusx wrote: | | NichtDerHans wrote: | | jpsollie wrote: | I also thought of distcc this time ...
It's hard: the PC itself is only a ryzen 5 device while the "compiling server" is a 64 core threadripper with no gui.
|
[X] chroot
export the ryzen / to nfs
ssh to threadripper
mount the ryzen /
chroot into ryzen from threadripper over ssh
Faster as distcc |
Is that OK on a live system? I think portage does practically the same, but I don't know if it takes additional measures against possible issues related to that.
Best Regards,
Georgi |
Do you mean live system on the compilemonster? That's fine, of course. I've been updating my little X220 laptop every two to four weeks, running a gentoo live CD in a VM on my fast computer. |
|
| Back to top |
|
|
NichtDerHans
Apprentice
Joined: 27 Jan 2023
Posts: 177
|
| Posted: Wed Oct 02, 2024 4:36 am Post subject: |
|
|
| jpsollie wrote: | | NichtDerHans wrote: | | jpsollie wrote: | I also thought of distcc this time ...
It's hard: the PC itself is only a ryzen 5 device while the "compiling server" is a 64 core threadripper with no gui.
|
[X] chroot
export the ryzen / to nfs
ssh to threadripper
mount the ryzen /
chroot into ryzen from threadripper over ssh
Faster as distcc |
yeah ... or simply rsync all relevant config files (package.use, package.accept_keywords, ...) into a stage 3 tarball at /usr/x86_64-compiler-linux-gnu/, and let the threadripper mirror the complete OS.
This magick will work:
| Code: |
mount -o rbind /proc /usr/x86_64-compiler-linux-gnu/proc/
mount -o rbind /sys /usr/x86_64-compiler-linux-gnu/sys
mount -o rbind /dev /usr/x86_64-compiler-linux-gnu/dev
mount -o rbind var/cache/distfiles /usr/x86_64-compiler-linux-gnu/var/cache/distfiles
mount -o rbind var/cache/binpkgs /usr/x86_64-compiler-linux-gnu/var/cache/binpkgs
screen chroot /usr/x86_64-compiler-linux-gnu/ /bin/sh
emerge -eav @system @world
|
... and shutdown the client ryzen PC while the threadripper compiles everything painful (libreoffice, qtwebengine, firefox, thunderbird, you name it ...)
I think this is a better solution in a binpkg world, as you don't need to export / on a client (but off course /usr/x86_64-compiler-linux-gnu/ will be fat) |
That is also a possible way forward. If there are local ebuilds or other individual things involved, this must of course also be taken into the Treadripper.
If only one computer is involved, chroot is a good solution. At least that's how it looks to me. |
|
| Back to top |
|
|
Zucca
Moderator
Joined: 14 Jun 2007
Posts: 3708
Location: Rasi, Finland
|
| Posted: Mon Oct 14, 2024 6:51 pm Post subject: |
|
|
| Code: | | 2024-10-14T12:47:02 >>> dev-qt/qtwebengine: 9:19:17 |
on | Code: | | Intel(R) Core(TM) i5-7600T (4) @ 3.70 GHz |
with 32GiB of RAM.
Holy compilation marathon, Batman!
I knew qtwebengine was big, but that big? Although I had USE=-jumbo-build.
Has anyone measured how much jumbo-build reduces the compilation time? In percents?
Also I always thought it was based on webkit and not the chromium (blink) fork.
I could then time compilation of webkit-gtk next...
_________________
..: Zucca :..
| My gentoo installs: | init=/sbin/openrc-init
-systemd -logind -elogind seatd |
| Quote: | | I am NaN! I am a man! |
|
|
| Back to top |
|
|
dmpogo
Advocate
Joined: 02 Sep 2004
Posts: 3425
Location: Canada
|
| Posted: Mon Oct 14, 2024 7:01 pm Post subject: |
|
|
| Zucca wrote: | | Code: | | 2024-10-14T12:47:02 >>> dev-qt/qtwebengine: 9:19:17 |
on | Code: | | Intel(R) Core(TM) i5-7600T (4) @ 3.70 GHz |
with 32GiB of RAM.
Holy compilation marathon, Batman!
I knew qtwebengine was big, but that big? Although I had USE=-jumbo-build.
Has anyone measured how much jumbo-build reduces the compilation time? In percents?
Also I always thought it was based on webkit and not the chromium (blink) fork.
I could then time compilation of webkit-gtk next... |
There is also an element that it seems modern compilers, while presumably being much smarter, are also much slower than compilers of the old days. |
|
| Back to top |
|
|
Zucca
Moderator
Joined: 14 Jun 2007
Posts: 3708
Location: Rasi, Finland
|
| Posted: Mon Oct 14, 2024 8:54 pm Post subject: |
|
|
| dmpogo wrote: | | There is also an element that it seems modern compilers, while presumably being much smarter, are also much slower than compilers of the old days. |
Sure. I would assume -O0 would result faster compilation because it drops most of the "smart" things off.
Or by setting CC="tcc", but wouldn't even dream qtwebengine compiling with tcc... Also isn't qtwebengine mostly C++?
_________________
..: Zucca :..
| My gentoo installs: | init=/sbin/openrc-init
-systemd -logind -elogind seatd |
| Quote: | | I am NaN! I am a man! |
|
|
| Back to top |
|
|
eschwartz
Developer
Joined: 29 Oct 2023
Posts: 228
|
| Posted: Mon Oct 14, 2024 11:44 pm Post subject: |
|
|
| Zucca wrote: | | dmpogo wrote: | | There is also an element that it seems modern compilers, while presumably being much smarter, are also much slower than compilers of the old days. |
Sure. I would assume -O0 would result faster compilation because it drops most of the "smart" things off.
Or by setting CC="tcc", but wouldn't even dream qtwebengine compiling with tcc... Also isn't qtwebengine mostly C++? |
Counterpoint: -O0 disables optimizations that lead to smaller code size, which means that the linker needs to do more work to link it all.
The extreme example is actually -ggdb, which actively adds loads of information to the program. Attempting to build very large programs like a browser with debug information is a nightmare, because linking already is a massive task that takes up tons of memory, and linking a debug-enabled version of a browser? Potentially terrifying. Maybe -O0 isn't so bad (I don't use it, I don't know) but I wouldn't be at all surprised to hear it actually increases the time and memory needed to finish linking. |
|
| Back to top |
|
|
Chiitoo
Administrator
Joined: 28 Feb 2010
Posts: 2730
Location: Here and Away Again
|
| Posted: Tue Oct 15, 2024 10:52 am Post subject: |
|
|
| Zucca wrote: | | Code: | | 2024-10-14T12:47:02 >>> dev-qt/qtwebengine: 9:19:17 |
on | Code: | | Intel(R) Core(TM) i5-7600T (4) @ 3.70 GHz |
with 32GiB of RAM.
Holy compilation marathon, Batman!
I knew qtwebengine was big, but that big? Although I had USE=-jumbo-build.
Has anyone measured how much jumbo-build reduces the compilation time? In percents? |
It's been a while since I actually tried, but I would still guess it should be about 50% of the time with 'jumbo-build' disabled (assuming the increased memory-use will not be a problem).
| Zucca wrote: | Also I always thought it was based on webkit and not the chromium (blink) fork.
|
There was Qt Webkit [1], which kind of fell into slumber, and eventually lost its outside-Qt maintainers as well.
1. https://code.qt.io/cgit/qt/qtwebkit.git/
_________________
Kindest of regardses. |
|
| Back to top |
|
|
|
Portage & Programming
