even with LTO disabled, it fails on Raspberry pi rev 1 (256 MB). Previous version is OK, I don't use LTO !!! >>> Verifying ebuild manifests >>> Running pre-merge checks for x11-libs/cairo-1.12.16-r3 * Checking for sufficient memory to build cairo with USE=lto * Checking for at least 768 MiB RAM ... [ !! ] * There is NOT at least 768 MiB RAM Reproducible: Always
it seems IUSE=+lto in that new version. Please disable LTO in memory-restricted arches.
it passes by setting USE="-lto" in make.conf
<flag name="lto">Try to build with Link-Time Optimization if supported by the compiler. This is recommended by upstream, but can cause build failure in some environments and on machines with little memory.</flag>
(In reply to Xavier Miller from comment #1) > Please disable LTO in memory-restricted arches. This sounds like a reasonable request; though, are there architectures that only have low memory devices available? Every time I see a bug like this I start to like the ideas of mixins (eg. a lowmemory mixin) and/or board specific profiles (eg. a Raspberry Pi profile) more and more.
(In reply to Tom Wijsman (TomWij) from comment #4) > (In reply to Xavier Miller from comment #1) > > Please disable LTO in memory-restricted arches. > > This sounds like a reasonable request; though, are there architectures that > only have low memory devices available? Every time I see a bug like this I > start to like the ideas of mixins (eg. a lowmemory mixin) and/or board > specific profiles (eg. a Raspberry Pi profile) more and more. I think the only thing we can do here is give a better error message.
Previous versions of cairo *always* built with lto, and *always* failed for people trying to build e.g. on machines with 320M memory and no swap. I tried to measure memory usage on amd64 with USE=lto and different gcc versions, and got figures between 500MB and 650MB, so marked the minimum memory requirements as 768M to be safe. But I don't have access to an arm machine, maybe lto on arm is more memory-efficient. Could you test how much it takes on the Raspberry Pi? To measure, get the memusg script from https://gist.github.com/netj/526585 and run # USE=lto I_KNOW_WHAT_I_AM_DOING=yes bash memusg.sh emerge -1 cairo
Or even simpler (as suggested by Alex Xu): # USE=lto I_KNOW_WHAT_I_AM_DOING=yes busybox time -v emerge -1 cairo and look at the "Maximum resident set size" line.
(In reply to Alexandre Rostovtsev from comment #7) > I_KNOW_WHAT_I_AM_DOING=yes Please! No more! Gentoo users, *by definition*, should know what they're doing. While a nice error message is a welcome improvement, we should not prevent people from shooting themselves in the feet *if they so choose*. And I believe LTO falls into that category. My humble 2 euro cents. :)
(In reply to Rémi Cardona from comment #8) Unlike most packages in the tree, cairo's upstream build system injects -flto if it detects that the compiler supports it. It's a completely different case from someone shooting themselves in the foot by enabling lto globally in CFLAGS in their make.conf.
(In reply to Alexandre Rostovtsev from comment #6) > Previous versions of cairo *always* built with lto, and *always* failed for > people trying to build e.g. on machines with 320M memory and no swap. > > I tried to measure memory usage on amd64 with USE=lto and different gcc > versions, and got figures between 500MB and 650MB, so marked the minimum > memory requirements as 768M to be safe. But I don't have access to an arm > machine, maybe lto on arm is more memory-efficient. Could you test how much > it takes on the Raspberry Pi? > > To measure, get the memusg script from https://gist.github.com/netj/526585 > and run > > # USE=lto I_KNOW_WHAT_I_AM_DOING=yes bash memusg.sh emerge -1 cairo memusg: peak=108448 BUT this is a X-less version (headless system, cairo used by cups), using distcc: [ebuild R ] x11-libs/cairo-1.12.16-r3 USE="glib lto svg -X (-aqua) -debug -directfb (-drm) (-gallium) (-gles2) -legacy-drivers -opengl -openvg (-qt4) -static-libs -valgrind -xcb -xlib-xcb" 0 kB
(In reply to Xavier Miller from comment #10) Well, on a headless system, cairo should not be enabling lto by default - squeezing out maximum performance matters when you are using gtk-based graphical applications and cairo is responsible for most of the rendering work. I think the best way to solve this is to enable USE=lto by default only in desktop profiles (and hopefully, people running a desktop profile have a machine with sufficient memory). + 04 May 2014; Alexandre Rostovtsev <tetromino@gentoo.org> + targets/desktop/package.use: + Enable cairo LTO by default only for desktop profiles, bug #509552 + 04 May 2014; Alexandre Rostovtsev <tetromino@gentoo.org> + cairo-1.12.16-r3.ebuild, cairo-9999.ebuild: + Do not enable LTO by default everywhere (bug #509552); it will be enabled by + default in profiles where needed.
