Emerge visualboyadvance 1.7.2 and 1.7.2-r1 both use an obscene amount of memory (>1Gig) and crash with an out of memory failure.
This is the last command run during the build:
if g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"VisualBoyAdvance\" -DVERSION=\"1.7.2\" -DYYTEXT_POINTER=1 -DHAVE_LIBZ=1 -DHAVE_LIBPNG=1 -DHAVE_LIBPTHREAD=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_MALLOC_H=1 -DHAVE_STRINGS_H=1 -DHAVE_UNISTD_H=1 -DHAVE_ARPA_INET_H=1 -DHAVE_NETINET_IN_H=1 -DENABLE_NLS=1 -DHAVE_GETTEXT=1 -DHAVE_DCGETTEXT=1 -DHAVE_LIBINTL_H=1 -I. -I. -I../../src -DSDL -DSYSCONFDIR=\"/etc/games\" -fno-exceptions -I/usr/include/SDL -D_REENTRANT -O3 -march=athlon-xp -fomit-frame-pointer -pipe -DC_CORE -DPROFILING -DDEV_VERSION -MT TestEmu.o -MD -MP -MF ".deps/TestEmu.Tpo" \
-c -o TestEmu.o `test -f 'TestEmu.cpp' || echo './'`TestEmu.cpp; \
then mv -f ".deps/TestEmu.Tpo" ".deps/TestEmu.Po"; \
else rm -f ".deps/TestEmu.Tpo"; exit 1; \
virtual memory exhausted: Cannot allocate memory
make: *** [GBA.o] Error 1
make: Leaving directory `/var/tmp/portage/visualboyadvance-1.7.2-r1/work/VisualBoyAdvance-1.7.2/src/sdl'
make: *** [all-recursive] Error 1
make: Leaving directory `/var/tmp/portage/visualboyadvance-1.7.2-r1/work/VisualBoyAdvance-1.7.2/src'
make: *** [all-recursive] Error 1
Steps to Reproduce:
reopen with the output from emerge --info
Here is the output requested
Portage 2.0.51_rc1 (default-x86-2004.2, gcc-3.4.1, glibc-22.214.171.12440808-r0, 2.4.27-gentoo-r1 i686)
System uname: 2.4.27-gentoo-r1 i686 AMD Athlon(tm) XP 3200+
Gentoo Base System version 1.5.3
CFLAGS="-O3 -march=athlon-xp -fomit-frame-pointer -pipe"
CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O3 -march=athlon-xp -fomit-frame-pointer -pipe"
FEATURES="autoaddcvs ccache sandbox"
GENTOO_MIRRORS="ftp://126.96.36.199/ ftp://188.8.131.52/ ftp://184.108.40.206/ ftp://gentoo.mirrors.pair.com/ ftp://ftp.snt.utwente.nl/pub/os/linux/gentoo http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/"
USE="3dnow 3dnowex X aac acpi acpi4linux aim alsa apache2 apm audiofile avi berkdb bitmap-fonts bzlib cdr crypt cups dga directfb distcache dvd dvdr dvdread encode esd etwin exif faac faad fbcon ffmpeg flac foomaticdb gdbm gif gimpprint gnome gpm gstreamer gtk gtk2 icq imap imlib immqt jack joystick jpeg latex libg++ libwww live mad mikmod mmx mmx2 motif mozilla moznocompose moznoirc moznomail mozsvg mpeg mpeg4 msn nas ncurses net network nls nvidia offensive ofx oggvorbis openal opengl oscar oss pam pda pdflib perl png python quicktime readline rtc sdl slang smime spell sse ssl svg svga tcpd tetex theora truetype usb x86 xml2 xmms xprint xv xvid xvmc yahoo zlib"
Forgot to reopen. Sorry
Does visualboyadvance-1.7.2 work?
Nope as I have mentioned in the original post neither work. Also the use flags gtk and mmx don't make any differnence either on or off.
I did however unpack the source tarbal and compile it with ./configure and make and it worked fine without using so much memory so it must be an ebuild problem.
i'm pretty suprised. You're saying if you run configure with the same arguments as the ebuild that it works?
No I am simply running it to see if it compiles at all. The commands were simply:
well, try it with the same options to configure. If that fails, try to determine which option causes the large memory usage.
Well I used the same configure string from the emerge without patching (there are two patches) and it crashed compiling the gtk frontend but didn't hog the memory. Made it further this time too.
-Then I tried without gtk (i.e I left --enable-gtk=2.4 from the configure line) and success.
-Then I tried with the homedir patch without gtk (there is a patch for gtk in the other patch so I didn't bother) and again success.
-Then I tried with both patches without gtk and success.
-Then finally I tried both with gtk and again success (i.e. exact same configure string used by the emerge and both patches used by the emerge).
Since I had (I thought) tried both with and without gtk without success using emerge I tried the emerge again. Same problem. Must be something with the ebuild as I am using the same source package that it downloaded and the patches in /usr/portage/games-emulation/visualboyadvance/files.
I don't understand much about the ebuild file structure so I can't say much more.
Try it with MAKEOPTS="-j1" and see if that works via emerge.
No luck. Doesn't seem to have any affect.
could be an issue with all the CXXFLAGS you're [ab]using
a `./configure ; make` with no env CXXFLAGS would default to '-g -O2'
LOL, Damn, you caught me! It was -O3 as far as I can tell. I went with the -O2 and march flags only and it is fine. I feel pretty stupid. However, I am definitely not the only Gentoo user with a flag abuse problem so it might be a good idea to override the flags in the ebuild if possible.
Thanks for all your help,
Forgot to close. Sorry.
Same probelm on AMD64 and gcc 3.4.4 ./configure && make (with -g-O2) doesn't work.
First was -Os -march=k8 -fomit-frame-pointer -pipe than tried -O2 -pipe. Problem stays.
Should I create new bug or you will reopen this? It doesn't compile on AMD64 but marked stable. gcc hungs memory compiling TestEmu.cpp
I guess we can investigate some more here since it seems people are still havign it (you all did emerge --sync, right?)
Yes I did emerge --sync. To test more I added line "rm -f src/sdl/TestEmu.cpp" to ebuild and tested again. Gcc eats memory compiling another file (unzip.cpp). And I of course patched Makefile to remove TestEmu.cpp
This is NO LONGER THE CASE. I used -march=pentium3 -O3 -mmmx -msse with gcc-3.4.5 by compiling the sources myself, and it works just fine.
Perhaps a check for gcc >= 3.4.5 in the ebuild will be good.
Also, what's with the use of --enable-c-core by default? Us x86 users should get the benefit of the assembly core - a USE flag or other check for architecture version would be adequate, as it stands I find it unacceptable, and will be using my rolled-myself version that I compiled to test the -O3 theory.
I'm calling this "FIXED" since we no longer support 3.3 and 3.4/4.1 are stable now.