Mail Archives: djgpp-workers/2001/09/03/12:17:15
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?= <wojciech DOT galazka AT polkomtel DOT com DOT pl> 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 <Martin DOT Stromberg AT epl DOT ericsson DOT se>
> 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 <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
make.exe: *** [makemake.exe] Error 1
Regards,
Guerrero, Juan Manuel.
- Raw text -