From: "Juan Manuel Guerrero" Organization: Darmstadt University of Technology To: pavenis AT lanet DOT lv, Eli Zaretskii , Date: Mon, 3 Sep 2001 18:15:10 +0200 Subject: Re: gcc-301 difficulty CC: djgpp-workers AT delorie DOT com X-mailer: Pegasus Mail for Windows (v2.54DE) Message-ID: <617D4F26ABD@HRZ1.hrz.tu-darmstadt.de> Reply-To: djgpp-workers AT delorie DOT com On Mon, 3 Sep 2001, Andris Pavenis wrote: > > Btw, I have tried to recompile gcc301s.zip. This seems impossible > > using win95 (4.00.950). The genattrib program always dies with > > the message that virtual memory has become exhausted. (DPMI > > memory available=48726KB, DPMI swap space available=16106KB). > > Am I missing something here? Can win95 not be used to compile gcc301? > > Win95 is not guilty. You have not enough RAM as genattrtab is very > memory hungry. Try setting memory for DOS box to 65535K and see whether > it helps. I built gcc-3.0.1 on PIII machine with 128Mb of memory, so I > used default (auto) and didn't get any problems > > There are some existing patches which makes genattrtab to use less > memory but these patches are not yet in official sources I know about the settings for the DOS box. This is well explained somewhere in the FAQs. What you are describing are exactely the settings of my DOS box. The DPMI memory is set to 65535K instead of auto. As you can see, when the DOS box is opened there are still "DPMI memory available=48726KB" available. There are no background programs running. This DPMI memory _together_ with the available "DPMI swap space available=16106KB" memory makes a total amount of about 65MB for the DOS box and this seems not to be enough to compile gcc-3.0.1. On Mon, 3 Sep 2001, Wojciech_Ga=B3=B1zka?= wrote: > You seem to mix EDO and FP RAM which is a bad idea as they work a bit > differently. Try compiling with only one type of memory (the other one > removed) and try also to tinker a bit with BIOS setting like "Slow refresh" On Mon, 3 Sep 2001, Martin Stromberg > What happens if you only use one type of memory? I wrote: > I am using a system composed by: > MB: Tyan Trinity 100AT > uP: SGS-Thomson ST6x86 P166+ (FSB 66MHz, CPU Multiplicator: 2x) > RAM: 32MB (fast page) + 32MB (edo) My information was completely wrong. I have **never** mixed fast page and edo ram on the same board. These are both configurations I have tested: MB: Tyan Trinity 100AT uP: SGS-Thomson ST6x86 P166+ (FSB 66MHz, CPU Multiplicator: 2x) RAM: 32MB (edo 60ns) + 32MB (edo 60ns). Both modules are from the same manufacturer (ACE 72 pin PS/2 SIMMs) MB: Chaintech 5IFM uP: SGS-Thomson ST6x86 P166+ (FSB 66MHz, CPU Multiplicator: 2x) RAM: 32MB (fast page 70ns) (HITACHI 30 pin SIMMs) Both boards use the same processor. With *both* boards the compilation fails. Please note that I am using different memory modules. It fails with my BIOS settings *and* it fails with "load BIOS defaults" settings on both boards. It fails even with the slowest possible settings in the BIOS of both boards. I have also used only one of the PS/2 modules at the time (only 32MB on board instead of 64MB. I have done this with both modules). No positive result. I have also used the 30 pins modules with an adapter in the tyan board and PS/2 modules in the chaintech board. Also no positive result. I have been using the tyan board for almost 3 years and before the chaintech board for 2 years in the above configurations with out any difficulty using linux, msdos622 and win95. Anyway. Either the processor is brocken in some way (i have no cyrix substitute to test this) or gcc is brocken. A year ago I have stopped to follow the pgcc developement. Have the pgcc people introduced some changes to gcc that may be the source of this difficulty? Here is the output if -v flag is used: gcc -v -O2 makemake.c -o makemake.exe Reading specs from D:/CVS/BIN/../lib/gcc-lib/djgpp/3.01/specs Configured with: ../configure i586-pc-msdosdjgpp --prefix=/dev/env/DJDIR --enable-languages=c,c++,f77,objc --disable-nls Thread model: single gcc version 3.0.1 D:/CVS/BIN/../lib/gcc-lib/djgpp/3.01/cc1.exe -lang-c -v -iprefix D:\CVS\BIN/../lib/gcc-lib/djgpp/3.01/ -D__GNUC__=3 -D__GNUC_MINOR__=0 -D__GNUC_PATCHLEVEL__=1 -D__MSDOS__ -D__GO32__ -D__unix__ -D__M SDOS__ -D__GO32__ -D__unix__ -Asystem=msdos -Asystem=unix -D__OPTIMIZE__ -D__STDC_HOSTED__=1 -remap -imacros D:/CVS/BIN/../lib/gcc-lib/djgpp/3.01/djgpp.ver -Acpu=i386 -Amachine=i386 -Di386 -D__i386 - D__i386__ -D__tune_i586__ -D__tune_pentium__ -DMSDOS -DGO32 -Dunix makemake.c -quiet -dumpbase makemake.c -O2 -version -o Z:/TMP\ccQhzaUk.s GNU CPP version 3.0.1 (cpplib) (80386, BSD syntax) GNU C version 3.0.1 (djgpp) compiled by GNU C version 3.0.1. ignoring nonexistent directory "D:/CVS/djgpp/include" ignoring nonexistent directory "d:/cvs/djgpp/include" #include "..." search starts here: #include <...> search starts here: D:/CVS/lib/gcc-lib/djgpp/3.01/include d:/cvs/lib/gcc-lib/djgpp/3.01/include d:/cvs/include End of search list. makemake.c: In function `process_makefile': makemake.c:59: Internal error: Segmentation violation Please submit a full bug report, with preprocessed source if appropriate. See for instructions. make.exe: *** [makemake.exe] Error 1 Regards, Guerrero, Juan Manuel.