Gpc November 1999

gpc@gnu.de

32 participants
67 discussions

native building of gpc 19991030 / gcc 2.95.2 for djgpp
by Maurice Lombardi 16 Nov '99

16 Nov '99

Hi all I succeeded in this native building with only one change to gpc sources due to a DOS peculiarity. The problem comes from the following lines contained (at two different locations) in p/Make-lang-2.95.in CC="`echo $(GCC_FOR_TARGET) | sed -e 's,-B$[^/]$,-B../../\1,g' -e 's,^$[^/][^ ]*$,../../\1,'`" \ PC="`echo $(GPC_FOR_TARGET) | sed -e 's,-B$[^/]$,-B../../\1,g' -e 's,^$[^/][^ ]*$,../../\1,'`" \ It means that to go the to rts subdirectory it prepends ../.. to G?C_FOR_TARGET if this is a relative, not an absolute directory name. Absolute is recognized by the first character being a slash. However in DOS an absolute pathname starts with a drive letter c:/ In particular GCC_FOR_TARGET is in my case an absolute pathname built through `pwd` in the top makefile, which gives the drive letter. Solutions could be - saying that an absolute pathname has either / as first character or : as second. Can be garbled by a unix relative path starting with d: is this possible in this context? This gives the attached notroot.dif - saying that a relative pathname starts by ./ or ../ This is what occurs for GPC_FOR_TARGET. Can be garbled if the relative path starts with an ordinary character, is this possible in this context? This gives the attached relative.dif. You can incorporate one of these solutions (or a better you may imagine) into the gpc sources, or let the djgpp maintainers to make the patch only for djgpp (and probably other DOS systems). The last solution would mean however the need to modify the patch for each new gpc alpha or beta distribution, so that the first is highly preferred. The building has been made in a W98 DOS box, LFN=Y, with binutils 2.8.1 and the beta version 2.0.3 of bash for djgpp. I can upload the resulting binary file if you are interested. For those interested to internals of djgpp. The beta bash version enables (when setting PATH_EXPAND=N) pwd to output /dev/c/ instead of c: to have a more unix-like behavior, which seems to solve the above problem. Bash understands command lines starting with /dev/c/bin/something.exe but DOS (command.com) does not understand ! Now, as explained to me by Eli Zaretskii to solve an other hairy problem, the djgpp port of Make sends command lines to bash only if he thinks that the shell is involved, and to COMMAND.COM otherwise (to save overhead). He recognizes that the shell is needed if the make line includes something which belongs to the shell, which could be a simple ; at the end of the makefile line. I have tried to build with PATH_EXPAND=N, it stops building the rts at the first command line $(GCC_FOR_TARGET) so so When adding a ; at the end of that makefile line, make goes somewhat further, but stops at the next occurrence, which shows that this is indeed the problem. Now is the overhead in make large enough to warrant all these inconveniences? Hope this helps. -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 51 45 44 mailto:Maurice.Lombardi@ujf-grenoble.fr

1 0

PROBLEM TO COMPILE WITH GPC
by Yves POCCHIOLA 15 Nov '99

15 Nov '99

For my first trial of GNU PASCAL, I get compilation error with message: impossible to load module GPC. I have loaded GNU PASCAL for LINUX with the binary package "gpc-19990118-egcs-1_1_1_i386-pc-linux-gnu". The decompression gives a directory "usr" in the working directory. There is no indication on howto configure the environment (PATH, specific variables). I have made some tentatives with PATH (bin and lib directory declaration) and variables (COMPILER_PATH, LIBRARY_PATH) but I always get a message saying a module is missing. This problem occurs either in command line mode or EMACS. Can somebody help me. Thanks.

2 1

GPC 19991030 for Solaris 7 Sparc/x86
by Mariusz Zynel 14 Nov '99

14 Nov '99

GNU Pascal Compiler binaries for Sun Solaris 7 (Sparc/x86) operating environment in native Solaris packages form are available at: Sparc: ftp://mizar.uwb.edu.pl/pub/misc/solaris7/sparc http://math.uwb.edu.pl/download/solaris7/sparc x86: ftp://mizar.uwb.edu.pl/pub/misc/solaris7/x86 http://math.uwb.edu.pl/download/solaris7/x86 For installation instructions read Readme.txt file. GPC 19991030 was compiled based on GCC 2.95. Hope someone uses this -- . Mariusz Zynel Institute of Mathematics | phone: +48 (85) 745 75 52 University of Bialystok | Akademicka 2 St | mailto:mariusz@math.uwb.edu.pl 15-267 Bialystok | Poland | http://math.uwb.edu.pl/~mariusz/

1 0

Cannot compile GPC
by Konstantin R.Beliaev 13 Nov '99

13 Nov '99

Hello. Something is wrong when I try to compile GPC. Can anyone helps me ? I have downloaded gcc-2.8.1, gpc-19990118, # patch -s -p1 < p/diffs/gcc-2.8.1.diff (without any messages) # ./configure # make LANGUAGES=pascal Last statement produce message "`all' not remade because of errors". Why? See session log as attachment. Thanks in advance, Konstantin main# pwd /usr/src/gnu/gcc-2.8.1 main# ./configure loading cache ./config.cache checking host system type... i386-unknown-freebsd2.2.8 checking target system type... i386-unknown-freebsd2.2.8 checking build system type... i386-unknown-freebsd2.2.8 checking for gcc... (cached) gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... (cached) yes checking whether gcc accepts -g... (cached) yes checking whether make sets ${MAKE}... (cached) yes checking for mawk... (cached) awk checking for flex... (cached) flex checking for yywrap in -lfl... (cached) yes checking for ranlib... (cached) ranlib checking for bison... (cached) bison -y checking for a BSD compatible install... (cached) /usr/bin/install -c checking how to run the C preprocessor... (cached) gcc -E checking for ANSI C header files... (cached) yes checking whether time.h and sys/time.h may both be included... (cached) yes checking for limits.h... (cached) yes checking for stddef.h... (cached) yes checking for string.h... (cached) yes checking for strings.h... (cached) yes checking for stdlib.h... (cached) yes checking for time.h... (cached) yes checking for fcntl.h... (cached) yes checking for unistd.h... (cached) yes checking for sys/file.h... (cached) yes checking for sys/time.h... (cached) yes checking for sys/resource.h... (cached) yes checking for sys/param.h... (cached) yes checking for sys/times.h... (cached) yes checking for inttypes.h... (cached) no checking for strerror... (cached) yes checking for putenv... (cached) yes checking for popen... (cached) yes checking for vprintf... (cached) yes checking for bcopy... (cached) yes checking for bzero... (cached) yes checking for bcmp... (cached) yes checking for index... (cached) yes checking for rindex... (cached) yes checking for kill... (cached) yes checking for getrlimit... (cached) yes checking for setrlimit... (cached) yes checking for sysconf... (cached) yes checking whether malloc must be declared... (cached) no checking whether realloc must be declared... (cached) no checking whether calloc must be declared... (cached) no checking whether free must be declared... (cached) no checking whether index must be declared... (cached) no checking whether rindex must be declared... (cached) no checking whether getenv must be declared... (cached) no checking whether sbrk must be declared... (cached) no checking for sys_siglist declaration in signal.h or unistd.h... (cached) yes Using `./config/i386/i386.c' to output insns. Using `./config/i386/i386.md' as machine description file. Using `./config/i386/freebsd.h' as target machine macro file. Using `./config/i386/xm-i386.h' as host machine macro file. Using `./objc/thr-single.c' as Objective-C Runtime thread file. Links are now set up to build a native compiler for i386-unknown-freebsd2.2.8 updating cache ./config.cache creating ./config.status creating Makefile creating cp/Makefile creating auto-config.h auto-config.h is unchanged Merged i386/t-freebsd. Created `objc/Makefile'. Merged i386/t-freebsd. Created `p/Makefile'. main# make LANGUAGES=pascal gcc -DIN_GCC -g -DHAVE_CONFIG_H -I. -I. -I./config -DGCC_INCLUDE_DIR=\` gcc -DIN_GCC -g -DHAVE_CONFIG_H -I. -I. -I./config -DPREFIX=\"/usr/loc` gcc -DIN_GCC -g -DHAVE_CONFIG_H -o cccp cccp.o cexp.o prefix.o version.o rm -f cpp ln cccp cpp > /dev/null 2>&1 || cp cccp cpp /bin/sh ./genmultilib "" "" "" "" "" > tmp-mlib.h ./move-if-change tmp-mlib.h multilib.h multilib.h is unchanged touch s-mlib gcc -DGPC -DIN_GCC -g -DHAVE_CONFIG_H -I. -I. -I./config -DGPC_MAJOR=o gcc -DGPC -DIN_GCC -g -DHAVE_CONFIG_H -I. -I. -I./config -DGPC_TIME="\o gcc -DIN_GCC -g -DHAVE_CONFIG_H -o xgpc p/gpc.o prefix.o p/version.o cho gcc -DIN_GCC -g -DHAVE_CONFIG_H -I. -I. -I./config -DSTANDARD_STARTFIL` gcc -DIN_GCC -g -DHAVE_CONFIG_H -o xgcc gcc.o prefix.o version.o choose- rm -f tmplibgcc1.a for name in _mulsi3 _udivsi3 _divsi3 _umodsi3 _modsi3 _lshrsi3 _ashrsi3 _ashlse _mulsi3 _udivsi3 _divsi3 _umodsi3 _modsi3 _lshrsi3 _ashrsi3 _ashlsi3 _divdf3 _muldf3 _negdf2 _adddf3 _subdf3 _fixdfsi _fixsfsi _floatsidf _floatsisf _truncdfsf2 _extendsfdf2 _addsf3 _negsf2 _subsf3 _mulsf3 _divsf3 _eqdf2 _nedf2 _gtdf2 _gedf2 _ltdf2 _ledf2 _eqsf2 _nesf2 _gtsf2 _gesf2 _ltsf2 _lesf2 for file in .. ; do if [ x${file} != x.. ]; then name=`echo ${file} | sed -ee if [ -f /usr/bin/ranlib -o -f /bin/ranlib ] ; then ranlib tmplibgcc1.a; else tri mv tmplibgcc1.a libgcc1.a if [ -f libgcc2.ready ] ; then true; else touch libgcc2.ready; fi Graph cycles through pascal rm -f include/float.h if [ -f /usr/include/float.h ] && if grep 'ifndef _FLOAT_H___' /usr/include/flc ./xgcc -B./ -DIN_GCC -g -I./include enquire.o -o enquire ./enquire -f > tmp-float.h grep '#define [^_]' tmp-float.h >/dev/null || true > tmp-float.h mv tmp-float.h float.h-nat rm -f gfloat.h cp float.h-nat gfloat.h rm -f include/float.h if [ -s gfloat.h ]; then cp gfloat.h include/float.h && chmod a+r include/floi touch stmp-headers ./xgcc -B./ -dumpspecs > tmp-specs mv tmp-specs specs gcc -DIN_GCC -g -DHAVE_CONFIG_H -I. -I. -I./config -DSTANDARD_STARTFILc gcc -DIN_GCC -g -DHAVE_CONFIG_H -o g++ g++.o g++spec.o prefix.o version. echo "int xxy_us_dummy;" >tmp-dum.c ./xgcc -B./ -S tmp-dum.c echo '/*WARNING: This file is automatically generated!*/' >tmp-under.c if grep _xxy_us_dummy tmp-dum.s > /dev/null ; then echo "int prepends_underscoi ./move-if-change tmp-under.c underscore.c underscore.c is unchanged rm -f tmp-dum.c tmp-dum.s touch s-under gcc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I. -I./config underscore.c gcc -DIN_GCC -g -DHAVE_CONFIG_H obstack.o ` case "gcc" in "cc") echo "" ;o `all' not remade because of errors.

1 0

Re: segmentation fault
by Frank Heckenbach 13 Nov '99

13 Nov '99

Profeta Mickael wrote: > I installed binary of gpc on my linux/pentium computer. When I manage to > compile a pascal source, I cannot execute the file a.out created, I always got > the same answer: segmentation fault! Which binary did you use? On agnes, there are different ones for libc5 and glibc. If you got the wrong one for your system (if it's a new installation, your system it most likely glibc), it may not work. There is also a little incompatibility between some distributions in their glibc versions -- which distribution do you use? If nothing else helps, you can always get the sources (GCC and GPC), and compile GPC yourself. Under Linux, this is not very difficult. > On the other hand, to compile demos programs I must be root? If you try to compile them in the demos directory, and this is owned by root, then yes. But if you compile them while you are in your home directory (either by copying them there, or by giving the full path to the source), you don't have to be root. You can also use the option `--executable-path=$HOME/bin' (say) to tell GPC to create the exectuables a bin directory below your home directory, and similarly e.g. `--unit-destination-path=$HOME/objects' to tell it where to put compiled units. The directories must exist before calling GPC. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

segmentation fault
by Profeta Mickael 12 Nov '99

12 Nov '99

I installed binary of gpc on my linux/pentium computer. When I manage to compile a pascal source, I cannot execute the file a.out created, I always got the same answer: segmentation fault! On the other hand, to compile demos programs I must be root? May you help me to solve this trouble Thanks Mike

1 0

GPC 2.0 1999/01/18 for Sparc Solaris 7
by Mariusz Zynel 12 Nov '99

12 Nov '99

Dear GPC enthusiasts Precompiled GPC 19990118 with unit sources and precompiled units for Sparc Solaris 7 in pkgadd format is available at: http://math.uwb.edu.pl/download/solaris7/sparc/ and ftp://mizar.uwb.edu.pl/pub/misc/ Regards -- . Mariusz Zynel Institute of Mathematics | phone: +48 (85) 745 75 52 University of Bialystok | Akademicka 2 St | mailto:mariusz@math.uwb.edu.pl 15-267 Bialystok | Poland | http://math.uwb.edu.pl/~mariusz/

2 2

Re: Bug report for GPC
by Frank Heckenbach 12 Nov '99

12 Nov '99

David Chandler wrote: > Dear GPC programmers, > > Here at NPL we have Pascal compiler testing software that generates self > checking, legal Pascal source code for the purpose of testing Pascal > compilers. We used this tool to test your compiler and generated the > following bug. > > Your compiler version: > > egcs-2.91.66 1990314 (egcs-1.1.2 release) > > The results of this test show that your compiler failed during compilation > of the following program: > > program test(output); > > type > T9 = false..true; > > var > failed : boolean; > V0 :T9 ; > V2 :T9 ; > > procedure P2; > > begin > failed := false; > V0 := true; > V2 := true = V0; > > { test code } > writeln("V2: ",V2); > writeln("V0: ",V0); > writeln("true: ",true); > end; > > begin P2; > > if V2 <> 1 then > begin > writeln('Verification test failed on line 93'); > failed := true; > end; > end. {Lines of code generated = 104} > > The problem appears to be that the compiler interprets the type > type "false..true" as being different from boolean. If this type is > changed to boolean, then the program runs correctly. > > The compiler options used to generate the test executable were: > > --standard-pascal > no optimisations > > The test platform was an Intel PC. It seems to me that the test program is wrong, and GPC (at least the current alpha version; I don't have 19990314 here to check) reports this error correctly: The program compares V2, which is of type T9 which is equivalent to Boolean, with 1, an integer. Perhaps this was just a mistake in the reproduction of the test program. We've had other bugs concerning types like "false..true", and if there are still such bugs left, we'd like to see a test program to show them... I'm also interested in your test tool. Is it (or the NPL report you mentioned) available on the Web, or how can we get at it? Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

gcc 2.95.2
by Brian O'Gorman 11 Nov '99

11 Nov '99

I'm rather new at trying to install gpc, so please excuse this question if it's been discussed elsewhere. Can someone tell me if gpc can be installed if only gcc 2.95.2 is available; or is it gcc 2.8.1 that's needed?

3 2

Bug report for GPC
by David Chandler 11 Nov '99

11 Nov '99

Dear GPC programmers, Here at NPL we have Pascal compiler testing software that generates self checking, legal Pascal source code for the purpose of testing Pascal compilers. We used this tool to test your compiler and generated the following bug. Your compiler version: egcs-2.91.66 1990314 (egcs-1.1.2 release) The results of this test show that your compiler failed during compilation of the following program: program test(output); type T9 = false..true; var failed : boolean; V0 :T9 ; V2 :T9 ; procedure P2; begin failed := false; V0 := true; V2 := true = V0; { test code } writeln("V2: ",V2); writeln("V0: ",V0); writeln("true: ",true); end; begin P2; if V2 <> 1 then begin writeln('Verification test failed on line 93'); failed := true; end; end. {Lines of code generated = 104} The problem appears to be that the compiler interprets the type type "false..true" as being different from boolean. If this type is changed to boolean, then the program runs correctly. The compiler options used to generate the test executable were: --standard-pascal no optimisations The test platform was an Intel PC. If you have any queries or require further information concerning the tests performed or the tools used, please contact either myself at the contact points below, or the author of the test tool, Brian Wichmann at brian.wichmann(a)npl.co.uk If you would like further information on the test tool, PPG (Pascal Program Generator), there is an NPL report "Experience with a Compiler Testing Tool" ISSN 0262-5369. NPL Report DITC 138/89, which is available in electronic format. Regards, David Chandler ================================================================ David Chandler Email: david.chandler(a)npl.co.uk CISE SSS Tel: +44 0181 943 6962 National Physical Laboratory Mobile: +44 0789 973 4151 Teddington, Middlesex, UK. Fax: +44 0181 977 7091 WWW: http://www.npl.co.uk/

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

Gpc November 1999