Bug#1085890: loupe: FTBFS on i386: rustc-LLVM ERROR: out of memory; Couldn't compile the test

Matthias Geiger werdahias at riseup.net
Wed Oct 23 13:52:40 BST 2024


On 23.10.24 12:00, Simon McVittie wrote:
> Source: loupe
> Version: 47.0-1
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
> X-Debbugs-Cc: debian-rust at lists.debian.org, bunk at debian.org
> Control: block 1085885 by -1
> User: debian-qa at lists.debian.org
> Usertags: i386
>
> loupe failed to build from source on i386:
>
> https://buildd.debian.org/status/fetch.php?pkg=loupe&arch=i386&ver=47.0-3&stamp=1728056118&raw=0
>> running 2 tests
>> test src/util/gettext.rs - util::gettext::apply_unicode_escapes (line 46) ... FAILED
>> test src/util/gettext.rs - util::gettext::hex_to_char (line 83) ... FAILED
>>
>> failures:
>>
>> ---- src/util/gettext.rs - util::gettext::apply_unicode_escapes (line 46) stdout ----
>> rustc-LLVM ERROR: out of memory
>> Allocation failed
>> Couldn't compile the test.
>> ---- src/util/gettext.rs - util::gettext::hex_to_char (line 83) stdout ----
>> rustc-LLVM ERROR: out of memory
>> Allocation failed
>> Couldn't compile the test.
> This seems to be repeatable: the build of 47.0-3 was retried a couple of
> times and it fails like this every time. 47.0-1 and -2 had what appears
> to be the same issue.
Right, I have been meaning to look into this.
>
> I think the most recent version that built successfully on i386, 46.2-2,
> might not have had a test suite at all?

yes, the compile tests are a nuisance; I disabled lto because of this 
for three gtk-rust apps already (and extended the timeout generously).

> 47.0-1 appears to have had the same symptom on armel and armhf, our only
> other 32-bit architectures where loupe's build-dependencies are available,
> and that was addressed by disabling LTO on those architectures. If
> the problem is that the buildd ran out of virtual address space, then
> it's going to affect every 32-bit architecture equally, so perhaps this
> workaround needs to be extended to all 32-bit architectures? That would
> look something like:
>
> -ifneq (,$(filter armel armhf,$(DEB_HOST_ARCH)))
> +ifeq ($(DEB_HOST_ARCH_BITS),32)
>
> (Or perhaps the Rust team could arrange for rustc/dh_cargo to disable
> memory-hungry optimizations like LTO in all 32-bit builds automatically?)

This might be a sensible default. While it is only an issue for large 
binaries such as loupe, snapshot and glycin-loaders I think the are no 
downsides to making it the default since GTK+rust always takes long to 
compile (even on my build machine with 32 GBs of RAM).

Since f_g kindly fixed the escaping in the wrapper it now can be 
simplified to

ifeq ($(DEB_HOST_ARCH_BITS),32)

DEB_BUILD_OPTIONS=-lto

endif


I will upload a fixed version later today incorporating this.


best,

werdahias



More information about the pkg-gnome-maintainers mailing list