While emerging uae-0.8.23_pre20040129 i get these errors from gcc: Dans le fichier inclus
While emerging uae-0.8.23_pre20040129 i get these errors from gcc: Dans le fichier inclus à partir de custom.c:58: ../src/include/enforcer.h:7:7: attention : pas de retour chariot à la fin du fichier custom.c:61: attention : no previous prototype for `uae_abort' custom.c: Dans la fonction « update_fetch »: custom.c:1377: attention : comparison between signed and unsigned then memory and swap usage reach 100 % and the system crashes. I've tried lowering my CFLAGS but this led to the same result. uname -a: Linux yelmo 2.6.2-mm1 #1 Thu Feb 5 23:36:11 CET 2004 i686 Intel(R) Pentium(R) III Mobile CPU 1000MHz GenuineIntel GNU/Linux make.conf: #Copyright 2000-2003 Daniel Robbins, Gentoo Technologies, Inc. # Contains local system settings for Portage system # $Header: /home/cvsroot/gentoo-src/portage/cnf/make.conf,v 1.68 2003/09/29 18:13:42 carpaski Exp $ # Please review 'man make.conf' for more information. # Build-time functionality # ======================== # # The USE variable is used to enable optional build-time functionality. For # example, quite a few packages have optional X, gtk or GNOME functionality # that can only be enabled or disabled at compile-time. Gentoo Linux has a # very extensive set of USE variables described in our USE variable HOWTO at # http://www.gentoo.org/doc/use-howto.html # # The available list of use flags with descriptions is in your portage tree. # Use 'less' to view them: --> less /usr/portage/profiles/use.desc <-- # # 'ufed' is an ncurses/dialog interface available in portage to make handling # useflags for you. 'emerge app-admin/ufed' # # Example: #USE="X gtk gnome -alsa" USE="dvd fbcon gtk2 mmx sse stroke tiff -arts -kde -gnome -qt" # Host Setting # ============ # # If you are using a Pentium Pro or greater processor, leave this line as-is; # otherwise, change to i586, i486 or i386 as appropriate. All modern systems # (even Athlons) should use "i686-pc-linux-gnu". All K6's are i586. # CHOST="i686-pc-linux-gnu" # Host and optimization settings # ============================== # # For optimal performance, enable a CFLAGS setting appropriate for your CPU. # # Please note that if you experience strange issues with a package, it may be # due to gcc's optimizations interacting in a strange way. Please test the # package (and in some cases the libraries it uses) at default optimizations # before reporting errors to developers. # # -mcpu=<cpu-type> means optimize code for the particular type of CPU without # breaking compatibility with other CPUs. # # -march=<cpu-type> means to take full advantage of the ABI and instructions # for the particular CPU; this will break compatibility with older CPUs (for # example, -march=athlon-xp code will not run on a regular Athlon, and # -march=i686 code will not run on a Pentium Classic. # # CPU types supported in gcc-3.2 and higher: athlon-xp, athlon-mp, # athlon-tbird, athlon, k6, k6-2, k6-3, i386, i486, i586 (Pentium), i686 # (PentiumPro), pentium, pentium-mmx, pentiumpro, pentium2 (Celeron), pentium3. # Note that Gentoo Linux 1.4 and higher include at least gcc-3.2. # # CPU types supported in gcc-2.95*: k6, i386, i486, i586 (Pentium), i686 # (Pentium Pro), pentium, pentiumpro Gentoo Linux 1.2 and below use gcc-2.95* # # CRITICAL WARNINGS: ****************************************************** # # ATHLON-4 will generate invalid SSE instructions; use 'athlon' instead. # # PENTIUM4 will generate invalid SSE2 instructions; use 'pentium3' instead. # # K6 markings are deceptive. Avoid setting -march for them. See Bug #24379. # # ************************************************************************* # # # Decent examples: # #CFLAGS="-mcpu=athlon-xp -O3 -pipe" CFLAGS="-march=pentium3 -O3 -pipe -fomit-frame-pointer -fforce-addr -falign-functions=4 -mfpmath=sse,387 -ftracer" # If you set a CFLAGS above, then this line will set your default C++ flags to # the same settings. CXXFLAGS="${CFLAGS}" # Advanced Masking # ================ # # Gentoo is using a new masking system to allow for easier stability testing # on packages. KEYWORDS are used in ebuilds to mask and unmask packages based # on the platform they are set for. A special form has been added that # indicates packages and revisions that are expected to work, but have not yet # been approved for the stable set. '~arch' is a superset of 'arch' which # includes the unstable, in testing, packages. Users of the 'x86' architecture # would add '~x86' to ACCEPT_KEYWORDS to enable unstable/testing packages. # '~ppc', '~sparc' are the unstable KEYWORDS for their respective platforms. # DO NOT PUT ANYTHING BUT YOUR SPECIFIC ~ARCHITECTURE IN THE LIST. # IF YOU ARE UNSURE OF YOUR ARCH, OR THE IMPLICATIONS, DO NOT MODIFY THIS. # #ACCEPT_KEYWORDS="~arch" using gcc-3.3.2-r5 glibc 2.3.2-r9 portage 2.0.50 Reproducible: Always Steps to Reproduce: 1. 2. 3.
there is a warning about needing a lot of ram to compile this (on my box i watched one gcc proccess use over 850megs of ram :P) dholm: perhaps the auto generated files could be cleaned up somehow ? seems like >1meg per .c file is pretty excessive ... root@vapier 0 src # ls -alhS *.c | head -rw-r--r-- 1 root root 1.7M Feb 9 22:51 compemu.c -rw-r--r-- 1 root root 1011K Feb 9 22:39 cpuemu_0.c -rw-r--r-- 1 root root 969K Feb 9 22:39 cpuemu_6.c -rw-r--r-- 1 root root 910K Feb 9 22:39 cpuemu_5.c -rw-r--r-- 1 root root 513K Feb 9 22:39 cpustbl.c
Hmm, I've managed to compile this on a system with 256MB RAM (and it used about 300MB of swap)... It took a while to finish but at least it didn't crash. I will look into this, perhaps it's possible to strip down the cpuemu file or something. 0.8.22 was bad, with the addition of the new JIT engine in 0.8.23 it is even worse :(. I'll see if Richard Drummond knows more, he's the current maintainer of the UAE source.
Just to put in my 2 cents. The emerge fails with "out of memory" for me. I have 512 megs of ram, and 1gig of swap. During compilation i noticied it used the whole gig of swap. Iam running a 2,6,1 kernel, on a amd 2000+ XP. I tried lowering my CFLAGS, but that didnt help much.
I have tried to compile this on two ppc machines and one x86 box now without any problems. Perhaps this is related to kernel 2.6 somehow? Do you have a 2.4 kernel that you could try it with?
A possible fix for this has been commited. Wait a couple of hours for it to get to your rsync mirror then please test it.
Issue fixed for me. Memory usage stayed within reasonable limits, on a 2.6.2 kernel. Thanks!
Seems fixed, closing report.
