Source: mame
Version: 0.273+dfsg.1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
User: debian-...@lists.debian.org
Usertags: armel
X-Debbugs-CC: debian-...@lists.debian.org
Control: block 1092719 by -1
As noted in #1092719, mame failed to build on the armel buildds:
> g++ -o ../../../../../mame obj/Release/src/mame/mame.o
> obj/Release/generated/mame/mame/drivlist.o obj/Release/generated/version.o
> -fuse-ld=gold -Wl,--no-keep-memory -Wl,-z,relro -Wl,-z,now -Wl,--long-plt
> -L"../../../../../../../../usr/X11/lib"
> -L"../../../../../../../../usr/X11R6/lib"
> -L"../../../../../../../../usr/openwin/lib" -L"."
> -L"../../../../../scripts/mame_mame" -L"../../../../../scripts/src/mame"
> -L"../../../../../scripts/src" -L"../../../../../scripts/src/osd/mame_mame"
> -L"../../../../../scripts/src/osd" -L/usr/lib/arm-linux-gnueabi
> -Wl,--start-group ../../../../../scripts/mame_mame/libzvt.a [... more static
> libraries ...] ../../../../../scripts/src/osd/mame_mame/libocore_sdl.a
> -lpugixml -ldl -lrt -lSDL2 -lm -lpthread -lutil -lexpat -ljpeg -lz -lFLAC
> -lutf8proc -lsqlite3 -lportaudio -lportmidi -lGL -lasound -lQt5Core -lQt5Gui
> -lQt5Widgets -lpulse -lX11 -lXinerama -lXext -lXi -lSDL2_ttf -lfontconfig
> -lfreetype -Wl,--end-group
> /usr/bin/ld.gold: out of memory
> collect2: error: ld returned 1 exit status
This seems to be erratic: its memory consumption must be somewhere around
the limit, such that linkers that are slightly more or slightly less
memory-efficient can push it above or below what's available.
If the mame maintainers are not particularly interested in keeping it
working on armel, I think the way to resolve this would be to ask for it
to be removed from armel, as Jeremy suggested in #1092719.
If this is done, then the mame maintainers will also need to make sure
subsequent versions don't flap between buildable and unbuildable over time.
It might be best to add "Build-Depends: an-unsatisfiable-dependency [armel]"
so that it will not be attempted.
Or, if an armel porter can provide tested linker options to make the
linker use less memory (perhaps by reducing debug symbols?), it might be
possible to keep mame compiling. However, mame is already using various
tricks to try to minimize its link-time memory consumption and they are
not enough, and it's now in danger of being autoremoved from testing;
so if armel porters want this, the time to suggest it would be *now*.
Thanks,
smcv
