- Gpc - gnu.de

GNU Pascal and X-Windows
by Brooker, Steve 25 Oct '99

25 Oct '99

I wish to port 250,000 lines of DEC Pascal code running on COMPAQ Alpha under OpenVMS/X-Windows to under Linux/X-Windows on Intel (and on Alpha if possible). I know that I will have some considerable problems with the non standard parts of DEC Pascal but GNU Pascal seems to be getting better all the time. The question I have is can I keep the same user interface, i.e. direct X-Windows and MOTIF calls from the Pascal code, i.e. is there an X-Windows/MOTIF binding for GNU Pascal. If the answer to this is yes please tell me. If it is not please tell me how GNU Pascal programmers develop GUI's.

2 1

Re: Installation problems?
by Peter Gerwinski 25 Oct '99

25 Oct '99

Jawaad Ahmad wrote: > Are you sure? With or without the > > USES Crt; > > statement, or the > > PROGRAM Hello (Input, Output); > > statement, it gives me the same error about -lgcc. [...] Okay, so GPC is unable to find your GCC. That's a minor incompatibility between a version of GPC and a version of GCC that does not match exactly. To work around, you can copy the GCC-related files (`cc1' etc.) somewhere under /djgpp/lib/gcc-lib/... from GCC's directory to GPC's one. Hope this helps, Peter -- http://home.pages.de/~Peter.Gerwinski/ - G-N-U GmbH: http://www.g-n-u.de Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 GnuPG key fingerprint: 9E7C 0FC4 8A62 5536 1730 A932 9834 65DB 2143 9422 keys: ftp://ftp.gerwinski.de/pub/keys/ - AntiSpam: http://spam.abuse.net

1 0

RHIDE problem
by Adam Naumowicz 25 Oct '99

25 Oct '99

Hello, I know that probably it is not the best list to write about it, but I know that most of GPC programmers use RHIDE, so I decided to ask you. I use RHIDE on Linux successfully, but trying to install it for my friend on RedHat 6.0 I encountered RTE at the first attempt to start the editor. There was a message like 'segmentation fault, unable to connect to a terminal' or something like that. Maybe it is a known problem, maybe there is some work-around. My friend uses RIVA TNT grafic card - maybe that is the problem ? Adam Naumowicz -------------------------------------- email: adamn(a)math.uwb.edu.pl WWW : http://math.uwb.edu.pl/~adamn/ --------------------------------------

1 0

another trouble (it was: Beginner needs help)
by Nicola Girardi 25 Oct '99

25 Oct '99

hi again, this time it is because i tried to compile programs using "uses Crt" outside Rhide (i use it as my favourite IDE) this is the command line i typed (i found it somewhere in the FAQ): girardi@ux(tty4)~/devel$ gpc -g --automake -o foo foo.pas gpc: installation problem, cannot exec `cc1': No such file or directory gpc1: gpc exited with status 1 /usr/lib/gcc-lib/i486-linux/egcs-2.91.66/units/crt.pas:345: `/usr/lib/gcc-lib/i486-linux/egcs-2.91.66/units/crtc.c' could not be compiled gpc1: gpc exited with status 1 foo.pas:2: module `crt' could not be compiled so, what's up? my distrib. is Debian 2.1 (slink), and all dependencies are OK. but there's still something wrong. sincerely, -- Nicola Girardi girardi(at)keycomm.it Key fingerprint = CD 7D 57 C2 52 73 67 B5 13 48 AA 8C 3E 7F 13 DC

2 2

Beginner needs help
by Nicola Girardi 24 Oct '99

24 Oct '99

hi all, i'm going to start again programming under linux. all i had done before this was some programs for DOS (i've been using linux for just a year) with Borland Pascal. now in linux i'd like to start programming again, but there are some functions that i can't find, and that i can't implement. for example, i need something as "delay(milliseconds)" but i can't find anything similar. ok, in C, i'd use "usleep()", but what in Pascal? and, for example, again, "textcolor and textbackground" ? readkey? keypressed? and how to use Svgalib instead os DOS' BGI ? please help me ASAP. thanks in advance. -- Nicola Girardi girardi(at)keycomm.it Key fingerprint = CD 7D 57 C2 52 73 67 B5 13 48 AA 8C 3E 7F 13 DC

2 3

Re: Beginner needs help
by Frank Heckenbach 24 Oct '99

24 Oct '99

I wrote: > > > for example, i need something as "delay(milliseconds)" but > > > i can't find anything similar. ok, in C, i'd use "usleep()", > > > but what in Pascal? > > > > Program Foo; > > > > uses > > Crt; > > > > begin > > Delay ( 42 ) > > end. > > Sollte man aber nur eingeschrÃ¤nkt empfehlen, d.h. nur wenn man eh > CRT benutzt. Nur wegen Delay CRT zu benutzen, ist weder in GPC noch > in BP sehr sinnvoll (nur, daÃ BP keine einfache Alternative > bietet)... Oops, sorry, wrong language... What I said is: This is only recommendable if you use CRT anyway. It's not a good idea to use CRT just for Delay, neither in GPC nor in BP. Just that BP does not offer any easy alternative, but GPC does (Sleep and SleepMicroSeconds in the GPC unit). 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

Re: Beginner needs help
by Frank Heckenbach 24 Oct '99

24 Oct '99

> > for example, i need something as "delay(milliseconds)" but > > i can't find anything similar. ok, in C, i'd use "usleep()", > > but what in Pascal? > > Program Foo; > > uses > Crt; > > begin > Delay ( 42 ) > end. Sollte man aber nur eingeschrÃ¤nkt empfehlen, d.h. nur wenn man eh CRT benutzt. Nur wegen Delay CRT zu benutzen, ist weder in GPC noch in BP sehr sinnvoll (nur, daÃ BP keine einfache Alternative bietet)... 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

Unit Printer
by Russ Whitaker 24 Oct '99

24 Oct '99

Hi 1) How do I pass '-Praw' to PrinterArguments? 2) Any particular reason why PrinterArguments isn't just a string? Thanks, Russ

1 0

Re: no subject (file transmission)
by Frank Heckenbach 20 Oct '99

20 Oct '99

"S. Achterop IWI-120 3932" wrote: > The question of course is, does this ring a bell? Maybe... There is a known problem: : IRIX and AIX work stations (and wherever else): initializers are not : executed (GCC bug!) This affects unit/module initializers, but it seems that the call to _p_initfdr (which is called automatically for each file type variable) is done in the same way, even in the main program. As stated, this is actually a GCC problem. However, it is solved in gcc-2.95 by using a utility called collect2 (at least according to the docs -- I can't check it myself since I don't have access to a system affected). The next version of GPC will work with gcc-2.95, so perhaps this will already solve the problem. To make sure it's really this bug, you can try the following code. If it fails to write `foo', it's the bug... unit foo; interface implementation to begin do Writeln ('foo'); end. program bar; uses foo; begin end. 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

followup reset error gpc
by S. Achterop IWI-120 3932 20 Oct '99

20 Oct '99

To follow up upon the reset error I just reported, the command gpc --help yields: GNU Pascal version 19980830, based on gcc-egcs-2.91.57 19980901 (egcs-1.1 release), compiled Sep 26 1998 13:44:06. So maybe I should try a newer version? Sietse

1 0

no subject (file transmission)
by S. Achterop IWI-120 3932 20 Oct '99

20 Oct '99

L.S. This is to report a problem on the HPUX-10.20 port of GNU-Pascal. (made here locally, which went flawless) The gpc version is: egcs-2.91.57 19980901 (egcs-1.1 release) The offending program is: PROGRAM p(Input,Output); VAR fin : text; BEGIN reset(fin,'file.txt'); writeln('reset done') END. And the runtime error is (with and without an existing file 'file.txt') : internal error: _p_initfdr has not been called for file (#914) On Linux (debian 2.1) there is no problem with this program. The question of course is, does this ring a bell? If not I'll have to create a debugable version of the runtime system and start using gdb, but I would like to avoid that, hence the question:). Sietse Achterop Computing Science Department University of Groningen The Netherlands.

1 0

What do you want to have fixed/implemented in gpc-2.1?
by Peter Gerwinski 20 Oct '99

20 Oct '99

Hello, folks! We are approaching a version of GPC that will (a) compile with gcc-2.95.x and (b) only need minimal patches to the GCC backend. With the next version of the GNU Compiler Collection (GCC), we want to publish the long-expected gpc-2.1 as a fully integrated frontend. We expect this next GCC release (2.9x or 3.0) to happen within the next two months or so. It is not realistic to fix all bugs and to implement all wanted features listed in the GPC TODO list (http://fjf.gnu.de/gpc-todo_toc.html) within this time schedule. However, most of the bugs listed there are not really relevant to real-world praxis. So we are planning to re-sort the TODO list and to focus on the most important bugs and feature requests. Please tell us which bugs and/or missing features on the TODO list, section "Urgent", you consider the most urgent. And of course, your help to fix those bugs is welcome. Peter -- http://home.pages.de/~Peter.Gerwinski/ - G-N-U GmbH: http://www.g-n-u.de Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 GnuPG key fingerprint: 9E7C 0FC4 8A62 5536 1730 A932 9834 65DB 2143 9422 keys: ftp://ftp.gerwinski.de/pub/keys/ - AntiSpam: http://spam.abuse.net

3 4

Re: Installation problems?
by Peter Gerwinski 20 Oct '99

20 Oct '99

> > [Win95] C:\TEMP\pas>gpc hello.pas > > d:\djgpp\bin\ld.exe: cannot open -lgcc: No such file or directory (ENOENT) [...] > > [Win95] C:\TEMP\pas>gpc --automake hello.pas > > gpc.exe: installation problem, cannot exec `cpp': No such file or directory (ENO ENT) You seem not to have the C compiler installed which is needed to compile some parts of the CRT unit. Please install GCC for your system (DJGPP? CygWin? mingw32?) and retry. Hope this helps, Peter -- http://home.pages.de/~Peter.Gerwinski/ - G-N-U GmbH: http://www.g-n-u.de Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 GnuPG key fingerprint: 9E7C 0FC4 8A62 5536 1730 A932 9834 65DB 2143 9422 keys: ftp://ftp.gerwinski.de/pub/keys/ - AntiSpam: http://spam.abuse.net

1 0

Installation problems?
by Jawaad Ahmad 18 Oct '99

18 Oct '99

Hi, folks, I hope someone can help me out. I haven't been able to compile any Pascal programs yet using DJGPP on Windows 95. I installed DJGPP a little while ago, and I can easily compile and run C programs (with gcc) and C++ programs (with gxx). I can still do that after installing GNU Pascal. However, I cannot even compile a simple Hello World program using gpc. Here is the program listing for hello.pas. (I admit I'm a bit rusty with Pascal.) > program Hello; > > (* uses CRT; *) > > begin > Writeln ('Hello world!'); > end. > Here is what I get when I try to compile: > [Win95] C:\TEMP\pas>gpc hello.pas > hello.pas:3: module/unit interface `Crt' could not be imported > > [Win95] C:\TEMP\pas>gpc -c hello.pas > hello.pas:3: module/unit interface `Crt' could not be imported > I have a hunch, though. I installed DJGPP v2.95. Doesn't GPC assume that we have v2.81 installed? In my directory tree, I have D:\djgpp\lib\gcc-lib\djgpp. Before installing GPC, all I had in this directory was a directory called 2.95, which had files such as libgcc.a, specs, cc1.exe, and cpp.exe, along with the "include" directory containing files such as new and new.h. After installing GPC, I had a 2.81 directory along with the 2.95 directory. Inside here, I had gpc1.exe, gpc-cpp.exe, libgpc.a, specs, and a units directory which contained files such as crt.inc, crt.pas, gpc.pas, and gmp.pas. (Aren't these the things that are required in the USES statement in the program?) Also, to "install" GPC, all I did was (properly) decompress a _binary_ of it (preserving the directory structure). The file was called gpc-19990430-i386-pc-djgppv202.zip. Thank you all very much. Any help would be appreciated. -- Get paid to surf the web! Go to http://www.alladvantage.com/refhome.asp?refid=BVA866

2 2

Re: CORE DUMPED - GPC
by Frank Heckenbach 08 Oct '99

08 Oct '99

Gualberto Rabay wrote: > I have installed the binary files in my linux/pentium machine and > I have compiled the examples power.pas and factorial.pas > from the gpc distribution demo directory successfuly. > > % gpc --automake -o power power.pas > (LIBRARY_PATH=/usr/lib/gcc-lib/i386-red-hat-linux/egcs-2.91.66) > > But when I tried to run it generates a core > > % power > core dumped Does this only happen with these programs (which use the GMP library), or also with other programs? If it's only the GMP programs: which version of the GMP library do you have the installed -- the binary from Agnes, or one from your distribution. In the latter case, which version number is it (try `rpm -qf /usr/lib/libgmp.a', or the packet descriptions)? What happens if you run power with some command line arguments? 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

CORE DUMPED - GPC
by Gualberto Rabay 08 Oct '99

08 Oct '99

Hi all , I have installed the binary files in my linux/pentium machine and I have compiled the examples power.pas and factorial.pas from the gpc distribution demo directory successfuly. % gpc --automake -o power power.pas (LIBRARY_PATH=/usr/lib/gcc-lib/i386-red-hat-linux/egcs-2.91.66) But when I tried to run it generates a core % power core dumped What is happening? What should I do in order to fix that problem? Thanks in advance, ____________________________________________________ Gualberto Rabay Fone: 0XX 35 5212810 ramal 33 Depto. de Computacao e-mail: rabay(a)passos.uemg.br UEMG -Passos http://cpqd.passos.uemg.br/~rabay Brazil

1 0

Re: I installed for FreeBSD
by Frank Heckenbach 07 Oct '99

07 Oct '99

j99060(a)st.ie.u-ryukyu.ac.jp wrote: > I report about probrem of 'gpc-19990118' that I found in installation > to the system based on FreeBSD, and how I had solved it. > > As making or compiling gpc-19990118 with gcc-2.8.1 or egcs-1.1.1 > for FreeBSD, you have to edit with line 1538 on 'p/rts/file.c'. > > [...] Thanks for the report. Actually, this has been fixed in the current alpha version (gpc-19990813). If you like, you can try this one to find out if there are other problems under FreeBSD. > Note: > If you make gcc/gpc for FreeBSD3.* may have to > configurate options i386-unknown-freebsdelf3.* to build/host/target > options for your style of use gcc/gpc. I just tried to build a Linux->FreeBSD cross compiler this way, but it fails because of lack of files libgcc1.a and crt1.o. Are these files available somewhere, or do you have them handy? 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

I installed for FreeBSD
by j99060＠st.ie.u-ryukyu.ac.jp 06 Oct '99

06 Oct '99

I report about probrem of 'gpc-19990118' that I found in installation to the system based on FreeBSD, and how I had solved it. As making or compiling gpc-19990118 with gcc-2.8.1 or egcs-1.1.1 for FreeBSD, you have to edit with line 1538 on 'p/rts/file.c'. original source: #ifdef HAVE_STATVFS #include <sys/statvfs.h> #elif defined(HAVE_STATVFS) #include <sys/vfs.h> #endif changed: #ifdef __FreeBSD__ #include <sys/mount.h> #else #ifdef HAVE_STATVFS #include <sys/statvfs.h> #elif defined(HAVE_STATVFS) #include <sys/vfs.h> #endif #endif /*__FreeBSD__ */ Reason: On the FreeBSD, "statfs" structure defined in sys/mount.h. Note: If you make gcc/gpc for FreeBSD3.* may have to configurate options i386-unknown-freebsdelf3.* to build/host/target options for your style of use gcc/gpc. /***************************************************** Information Engineering Department University of the Ryukyus YAMASHIRO Jun ($B;3>k=a(B) E-mail: j99060(a)ie.u-ryukyu.ac.jp *****************************************************/

1 1

Mingw32 installationproblem
by Andreas Klostermann 04 Oct '99

04 Oct '99

hello, I am Sorry to bother you with this probable trivial problem, but I can't =get any further here. I installed the file gpc-19990118-egcs-1_1_1_i386-pc-mingw32.zip, wich =rather looks like the one I need for Mingw32 - egcs. And guess what? It doesn't work: C:\egcs\lib\gcc-lib\i386-mingw32\egcs-2.91.60\units>gpc dos.pas GPC.EXE: installation problem, cannot exec `gpc-cpp': No such file or =directory C:\egcs\lib\gcc-lib\i386-mingw32\egcs-2.91.60\units>gpc dos.pas GPC.EXE: installation problem, cannot exec `gpc-cpp': No such file or =directory C:\egcs\lib\gcc-lib\i386-mingw32\egcs-2.91.60\units>gcc dos.pas GCC.EXE: dos.pas: Pascal compiler not installed on this system GCC.EXE: installation problem, cannot exec `#Pascalld': No such file or =director y C:\egcs\lib\gcc-lib\i386-mingw32\egcs-2.91.60\units>gpc -v Using builtin specs. gpc version 19990118, based on egcs-2.91.60 19981201 (egcs-1.1.1 =release) C:\egcs\lib\gcc-lib\i386-mingw32\egcs-2.91.60\units>gcc -v Reading specs from =C:\EGCS\BIN\..\lib\gcc-lib\i386-mingw32\egcs-2.91.66\specs gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release) I also tried other pascal programs, they don't work either. It looks =like I have to modify some settings of the egcs compiler. But where? And =how? Nothing like that showed up in neither the docs nor the FAQs. please help me. Andreas Klostermann andy.klostermann(a)gmx.de

2 1

Re: SuSE (was: question)
by Russ Whitaker 02 Oct '99

02 Oct '99

My typo. sorry ---------- > From: Peter Gerwinski <peter(a)gerwinski.de> > To: gpc(a)gnu.de > Subject: SuSE (was: question) > Date: Friday, October 01, 1999 1:44 PM > > Russ Whitaker wrote: > > > > The US version of suse 6.2 has gpc-19990118 > > Good. :) > > > Their comments ended with "Recent information can be retrieved > > from the WWW site at http://home.pages.de/~GNU.Pascal/." > > Bad. :( The correct URL is > > http://home.pages.de/~GNU-Pascal/ > > with a `-', not a `.'. > > Are you sure it's not a typo? > > Peter > > --

1 0

re: question
by Russ Whitaker 01 Oct '99

01 Oct '99

Peter Gerwinski wrote > ... gpc-2.0 is obsolete and gpc-19990118 is current The US version of suse 6.2 has gpc-19990118 Their comments ended with "Recent information can be retrieved from the WWW site at http://home.pages.de/~GNU.Pascal/." incidently, they're compiling kernel 2.2.10 with gcc 2.7.2.3 Russ <russwhit(a)mind.net>

2 1

newbie building gpc
by al 30 Sep '99

30 Sep '99

Hi, I am trying to build gpc with gcc 2.95 for UnixWare and Tru64 UNIX. I have two questions... 1. In the INSTALL instructions is says to apply a patch to gcc but I can't find one for gcc 2.95. Is a patch needed for this version? 2. When I try a "make LANGUAGES=pascal" things crank along for a minute or two and then I get a message indicating that it does not know how to make pascal. Does anyone know what I need to do to get past this? Here are the last few lines generated by the make... gcc -c -DIN_GCC -DHAIFA -g -O2 -DHAVE_CONFIG_H -I. -I. -I./config -I./../include obstack.c gcc -DIN_GCC -DHAIFA -g -O2 -DHAVE_CONFIG_H -o cccp cccp.o cexp.o intl.o prefix.o version.o mbchar.o obstack.o -lmld ../libiberty/libiberty.a rm -f cpp ln cccp cpp (cd intl && make all) Make: Don't know how to make pascal. Stop. *** Exit 1 Stop. Thanks, Al Tingey Computer Administrator University of Utah Human Genetics Dept. al(a)genetics.utah.edu

2 2

can't compile gpc-19990813
by Achim Kalwa 30 Sep '99

30 Sep '99

Hello, until today I prefered gpc's binary distribution. But there is no recent gpc binary for x86 Linux. So I've tried to compile gpc-19990813 on my machine, using SuSE Linux 6.1 with egcs-2.91.66 on a Intel P90 :-| First of all I've removed all old gpc releated files (I hope so) Followed by: su cd /usr/src tar -xvzf gpc-19990813.tar.gz mv gpc/p egcs-1.1/p cd /usr/src/egcs-1.1 chgrp -R users * chown -R achim * # I've done this to avoid problems with different rigths exit I've now the following structure: egcs source is in /usr/src/egcs-1.1 gcc source is in /usr/src/egcs-1.1/gcc gpc source is in /usr/src/egcs-1.1/gcc/p # now as user "achim": cd /usr/src/egcs-1.1/gcc ./configure make LANGUAGES=pascal 2>x.x cat x.x ------ Makefile:4869: warning: overriding commands for target `check-gpc' Makefile:4865: warning: ignoring old commands for target `check-gpc' make: Circular cplib2.ready <- pascal dependency dropped. cat: ./p/gpc_release: No such file or directory ^^^^^^^^^^^ this file exists! make: *** No rule to make target `prefix.h', needed by `gcj.o'. Stop. ------ So what goes wrong? Please Help! (I'm not very experienced in compiling source distributions) Achim -- Achim Kalwa Tel.: +49 (0) 5483 / 74265 Hofbreede 8 Fax : +49 (0) 5483 / 74266 D-49536 Lienen Mobil: +49 (0) 172 / 211 37 44 mailto:achim.kalwa@gmx.net PGP Public Key available.

3 2

Re: GPC on Solaris 2.6
by Frank Heckenbach 29 Sep '99

29 Sep '99

Tom Schneider wrote: > Peter: > > > No. We use one of the mechanisms to specify the file name at > > run-time from a string. > > > > UCSD Pascal: > > > > reset ( MyFile, 'myfile.dat' ); > > > > Borland Pascal: > > > > assign ( MyFile, 'myfile.dat' ); > > reset ( MyFile ); > > > > ISO Extended Pascal: > > > > Var > > MyFile: File of whatever; > > B: BindingType; > > > > unbind ( MyFile ); > > B:= binding ( MyFile ); > > B.Name:= 'myfile.dat'; > > bind ( MyFile, B ); > > reset ( MyFile ); > > > > All this works in GPC. > > Right, and I consider that to be "machine dependent" Not machine dependent, but compiler dependent, that's a big difference! It will work on any machine, as long as it's compiled with GPC. > since such things are > not available on all Pascal compilers. So I avoid them. Well, at least the 3rd mechanism is specified in the Extended Pascal standard (ISO 10206), while your way (derving the file name from the variable name) is not standardized and therefore also compiler dependent... 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

3 5

Re: Fwd: gpc mailing list
by Jochen 29 Sep '99

29 Sep '99

On Die, 28 Sep 1999 Peter Gerwinski wrote: >Jochen wrote: >> >> first of all: Is there an uptodate archive of the mailing list ? >> >Currently there isn't. To all: Should there be one? > >Now there is one(-: > > http://www.gnu.de/archive/wilma.cgi/gpc > http://www.gnu.de/archive/wilma.cgi/gpc-announce The thread-browsing looks nice/works well ! I cannot search, though. Whatever I looked for - I chose words I saw in the thread list - returned with ZERO results :-( -- Jochen Heinrich-Heine-Universität, Institut für Physikalische Chemie I Universitätsstr. 1, Geb. 26.43.02.29, 40225 Düsseldorf, Germany phone 02118113681 fax 02118115195 -- www-public.rz.uni-duesseldorf.de/~jochen Jochen(a)Uni-Duesseldorf.de -- Jochen.Kuepper(a)FernUni-Hagen.de -- Kuepper(a)ACM.org

2 1

Problems with Pascal and gcc-2.95.1
by Geraldo Kern 29 Sep '99

29 Sep '99

HI Someone, I can't install the Gnu Pascal over the gcc-2.95.1. I tried to patch the diffs files, but I didn't obtain success. *** *** ./configure detected GCC version 2.95.1. *** GPC 2.1 requires one of the following versions of GCC sources to build: *** *** 2.8.1 *** egcs-2.91.57 *** egcs-2.91.60 *** egcs-2.92.27 *** egcs-2.92.33 *** *** (You can try to patch GCC manually by typing a command like *** `patch -p1 < p/diffs/gcc-2.8.1.diff' and patching possible rejects *** by hand before you run `./configure' again.) *** If someone knows how to install in this version of gcc, please send me a emails. thanks in advice, -- Geraldo Kern kern(a)iprj.uerj.br

2 1

None
by Jochen 28 Sep '99

28 Sep '99

Hi Peter, thanks for your answers. Peter Gerwinski wrote: >Jochen wrote: >> first of all: Is there an uptodate archive of the mailing list ? >Currently there isn't. To all: Should there be one? I don't know what you guys need, and that's what counts, after all. Still it would make life easier for people like me encountering some problems, 'cause I could skim the archive first (so a searchable archive would be really nice :-). Also I don't know if you send replies to the list only - in that case it would help, since not everybody like me wants to subscribe the list (there are to many already). With an archive I would just recheck every few days wethere there is a answer. >> I try to compile a gcc-2.95.1 patched/extended by the gpc-19990813 >> sources/patch. (Same results with plain gcc-2.95.) > >This cannot work. Support for gcc-2.95.x in gpc-19990813 is >work in progress and not yet stable. However, gpc-19990813 does >work with gcc-2.8.x or egcs-1.1.x. Well, I read about that alpha version - just wanted to look in and thought I let you know... I read some stuff on the egcs ml as well. Anyhow, it hasn't worked with egcs-1.1.2 (I think that was the one I used) for me as well. I don't have any egcs sources around right now, but I will get back to try it and will send in the problems I get. (IIRC it was just the same, not sure about that, though.) Right now I am using the binaries from the gpc ftp page, they are working nice for me. Next thing I would like to see is a gcc-3.0 including gpc :-) Btw: If this is still of any interest, I could help setting up a cvs repository for gpc. In case it will be incorporated into gcc really soon, there is no need, but otherwise... I have a 486 that is our dedicated cvs server, I could create a repository there, that is a slow but doable solution. Moreover I could set it up somewhere else, if you provide me with a user login and the admin is willing to do some work as well. Anyway: Good work guys, keep on going, -- Jochen Jochen.Kuepper(a)FernUni-Hagen.de http://www-public.rz.uni-duesseldorf.de/~jochen

3 2

compiler optimization
by Russ Whitaker 27 Sep '99

27 Sep '99

Hi Usuing gcc-2.8.1 and i586-pc-linux-gnu, compiled gpc with no optimization, O1, and O2 (except part where O2 would crash) Then used gpc to compile 4 of the demo programs. While there was little difference between the no optimazation and the O2 version, the O1 version produced programs that were significantly smaller: pi 248155 bytes power 253838 bytes schemademo 152992 bytes stringschemademo 153690 bytes just thought you'd like to know thanks, Russ <russwhit(a)mind.net>

3 2

Mailing list archive available online
by Anja Drewitz 27 Sep '99

27 Sep '99

Hello, now you can access the gpc and gpc-announce mailing list archives via the world wide web: http://www.gnu.de/archive/wilma.cgi/gpc http://www.gnu.de/archive/wilma.cgi/gpc-announce Currently, the archive dates back to June 1999 only. We are going to put earlier messages online, too, as time permits. Best wishes, Anja

1 0

Re: BP 7.0 compatibility
by Frank Heckenbach 23 Sep '99

23 Sep '99

Adam Naumowicz wrote: > But there is one more missing (??) thing I have found. I just tried > to use include and exclude procedures for sets (enums). I know that > it can be replaced almost equivalently with assignment S:=S+[new element], > but maybe these procedures should be implemented as above within your > system unit. Yes, they're listed on our To-Do list (http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html), as one of the few missing features to be implemented before the next release. Actually, Peter is already working on changes to the set handling code, and these routines will be part of the changes. 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

Re: BP 7.0 compatibility
by Frank Heckenbach 23 Sep '99

23 Sep '99

Adam Naumowicz wrote: > Hello, > I found some information on the official web pages of your project, > that the compiler 'completely' supports Borland Pascal syntax. Trying > to compile some old BP 7.0 sources with GPC I noticed that the compiler > knows nothing about SetTextBuf declared in BP system unit I suppose. Thanks for the report. As Peter said, such a routine is not really necessary in GPC because GPC files do their own buffer management. But I will add a do-nothing SetTextBuf procedure to the System unit. BTW, the reason why I missed it was that I looked through BP's system.pas pseudo-unit to see what was missing, and for some reason they call the procedure `BufferText' there, so I didn't see SetTextBuf... 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

2 1

question
by michael paap 22 Sep '99

22 Sep '99

hello, i forward you the following question from the fernuni-hagen-pascalnewsgroup: Carsten Simon wrote: > > Hallo, > > ich bin gerade dabei einige Beispiele nachzuprogrammieren (Ãbung macht > den Meister...). Ich arbeite unter LINUX mit GNU-Pascal fÃ¼r LINUX. > Bisher hatte ich eigentlich keine groÃen Probleme mit dem Compiler > (Aufruf: gpc --standard-pascal --pedantic -g -o). Nun habe ich aber > ein Feld mit dem component type boolean deklariert. Bei der spÃ¤teren > Zuweisung eines boolean-Wertes zu einer indizierten Variablen (wie > z.B. Kurs 1612 Bsp. 4.2.1.7) meckert mich der Compiler wie folgt an: > 'cannot convert to a boolean type'. Den gleichen Quellcode mit dem > SPAR-Compiler auf bonsai - kein Problem. > > Ist das ein prinzipielles GNU-Pascal-Problem, mit dem ich mich > abfinden muÃ, oder gibt es da einen Trick? michael -- michael: michael paap, ICQ: 7024000 homepage: http://www.dj-koeln.de/michael/index.html

2 3

BP 7.0 compatibility
by Adam Naumowicz 22 Sep '99

22 Sep '99

Hello, I found some information on the official web pages of your project, that the compiler 'completely' supports Borland Pascal syntax. Trying to compile some old BP 7.0 sources with GPC I noticed that the compiler knows nothing about SetTextBuf declared in BP system unit I suppose. Is there any equivalent for that procedure or maybe it is contained in some other unit ? Or maybe the job to make GPC with -fBorlanf-Pascal switch to act like BP on basic stage is not completed ? Adam Naumowicz -------------------------------------- email: adamn(a)math.uwb.edu.pl WWW : http://math.uwb.edu.pl/~adamn/ --------------------------------------

2 1

two questions about GPC
by michael paap 21 Sep '99

21 Sep '99

hello, i would like to know two things: 1. is it right, that gps is not compatible to standardpascal in this respect, that it does not look for the right part of a statement like the below, if the first part is true? if (j > a) or (i[b] > a) then ... so that there will be no mistake, if in the example (j > a) is true and b is out of border of the definition of the arrayindex of i[]? 2. what does the option --pedantic do? michael paap -- michael: michael paap, ICQ: 7024000 homepage: http://www.dj-koeln.de/michael/index.html * homepage der jungenschaft kÃ¶ln: http://www.dj-koeln.de/index.html * die kohtenrunde: http://www.dj-koeln.de/kohtenrunde/index.html * inhaltsverz. jugendbewegter websites: http://www.dj-koeln.de/jbinhalt/index.html

2 1

Re: Several questions on GPC
by Frank Heckenbach 20 Sep '99

20 Sep '99

"Alex" wrote: > Hello, > > I've several questions on Gnu Pascal: > I'd like to use the CRT-Unit in Gnu Pascal. How is it possible? The only > procedure I need is RANDOM (CLRSCR would be nice too, but isn't necessary). > > How can I do it? Just get a current GPC version (beta 19990118 or alpha 19990813) and install either the ncurses library (for Unix system on terminals -- note that ncurses is already installed by default on most Unix systems, including most Linux distributions) or the PDCurses library (for Unix, X11 versions, and for Dos systems). These libraries (source and binaries for some platforms) are available from ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/libs/ Then, just add `uses CRT;' to your program, and don't forget the `--automake' command line parameter. BTW, Random is not part of the CRT unit -- it's built into the compiler in current GPC versions. 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

Several questions on GPC
by Alex 20 Sep '99

20 Sep '99

Hello, I've several questions on Gnu Pascal: I'd like to use the CRT-Unit in Gnu Pascal. How is it possible? The only procedure I need is RANDOM (CLRSCR would be nice too, but isn't necessary). How can I do it? Thanks, Alex

1 0

Re: Is it a bug ?
by Frank Heckenbach 16 Sep '99

16 Sep '99

Emmanuel Chaput wrote: > I have a problem with gpc on a sun sparc. A simple program like > this crashes the compiler (with gpc1 receiving a sig 11) : > > program foo; > begin > writeln(round(3.1)) > end. > > Note that round(x) works fine. A debugger told me that in function > expand_fix from file optabs.c, GET_MODE (from) was used with > from = 0. > > I then discovered in file p/rts.c that there were differences between > > how trunc and round were implemented. So I tried to change the > "case p_ROUND" in that file. That is I changed > > retval = fold(build1(... > > into > > retval = convert(long_long_integer_type_node, val); > > And it seems to work ! > > Could someone explain this to me ? Did I make something wrong ? > Or is this the good way to correct the bug ? I think you made Round work like Trunc now!? What does `Round (2.8)' say? It should, of course, say 3, but after your patch, doesn't it say 2? Frank PS: Are you subscribed to the list now? I'm CCing you a copy, just in case not... 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

Is it a bug ?
by Emmanuel Chaput 16 Sep '99

16 Sep '99

Hi ! I have a problem with gpc on a sun sparc. A simple program like this crashes the compiler (with gpc1 receiving a sig 11) : program foo; begin writeln(round(3.1)) end. Note that round(x) works fine. A debugger told me that in function expand_fix from file optabs.c, GET_MODE (from) was used with from = 0. I then discovered in file p/rts.c that there were differences between how trunc and round were implemented. So I tried to change the "case p_ROUND" in that file. That is I changed retval = fold(build1(... into retval = convert(long_long_integer_type_node, val); And it seems to work ! Could someone explain this to me ? Did I make something wrong ? Or is this the good way to correct the bug ? Thanks a lot ... -- E. Chaput *5 61 58 82 10 Emmanuel.Chaput(a)enseeiht.fr ENSEEIHT, DÃ©pt TÃ©lÃ©com & RÃ©seaux

1 0

Re: GPC on Solaris 2.6
by Frank Heckenbach 16 Sep '99

16 Sep '99

Tom Schneider wrote: > > I've put the patch into the official sources, but inactivated by > > `#if 0'. So, all you've got to do is activate the patch before > > compiling future GPC versions. > > Ok, great! That solves one problem. (Though I don't know how to "activate a > patch" other than just patch or download the source again.) Since it's in the sources, starting from the next release, all you'll have to do is replace `#if 0' by `#if 1'... Frank PS: No need to CC me a copy. Since I'm subscribed to the list, I'm getting your mail twice... -- 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

Script install-gpc-binary uploaded
by Frank Heckenbach 16 Sep '99

16 Sep '99

Hi, due to recent needs, I wrote a little script to simplify the installation of a GPC *binary* distribution into *another* directory than it was intended. To explain the situation: The gpc executable uses some files (e.g. the preprocessor gpc-cccp, the actual compiler gpc1 and the runtime library libgpc.a) which are usually stored in a directory <prefix>/lib/gcc-lib/<target>/<version>/. The <prefix>, i.e. the base directory for the GPC installation, can be specified while building GPC, and is then hard-coded into the gpc executable. When using gpc, it can be overridden with a `-B' option (for gpc-cccp and gpc1) and a `-L' option (for libgpc.a). The purpose of the install-gpc-binary script is just to create another script which calls gpc with those two options (in addition to any options given on the command-line). It examines the installed GPC binary distribution to find out the correct directories. The script created will be called gpc, and should be in the PATH, while the actual gpc executable should not be in the PATH, so calling `gpc' will invoke the script. Then, `gpc' can be used just like a gpc installed in the normal way, which is quite useful for using third-party Makefiles etc. Who needs this script? Those who get a binary distribution of GPC and don't install it into the right directory. These are usually not PC (including Linux) users, because most of them have root access and can install GPC into the right directory. There are also usually not system administrators of multi-user machines (who have root access and usually will prefer to build their software themselves, anyway). So, these are e.g. users on multi-user machines who can't convince their admins to install GPC for them, or just need it quickly, and/or don't have enough space in their home to build GPC... How to use it? - Get a GPC binary for your system, and the install-gpc-binary script. The script is available in the same FTP directories on agnes as the GPC binaries, i.e.: ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/binary/install-gpc-binary ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/binary/install-gpc-binary - Unpack the GPC binary into any directory (but don't move it around after running the script). - Change into its "base" directory -- e.g. if the archive unpacks into usr/local/bin/..., usr/local/lib/..., etc. (below the current directory), change into usr/local, or move the contents of usr/local up to the current directory. In any case, the bin and lib directories should now be subdirectories of the current directory (the script will make sure this was done correctly). - Run this script and answer a few simple questions. - That's all. If you set your $PATH appropriately, you can now invoke `gpc' in the normal way. Frank -- Frank Heckenbach, frank(a)g-n-u.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Re: GPC on Solaris 2.6
by Frank Heckenbach 16 Sep '99

16 Sep '99

Tom Schneider wrote: > Thanks for the instructions on using patch (it's simple!) but I realized that > it is not good way to go because a version I provide to people would be > quickly out of date, or I would be forced to keep patching the latest version > (and eventually the patch would not work of course). I've put the patch into the official sources, but inactivated by `#if 0'. So, all you've got to do is activate the patch before compiling future GPC versions. If you want the compiler switch, you can either wait until we get around to it in our normal progress of work, or you can pay us (or any other programmer) to do it now. That's your option with free software... 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

2 1

Re: Compiling GPC - mysteries
by Frank Heckenbach 16 Sep '99

16 Sep '99

Sorry, if two of my mails arrived twice. I had a head-crash, and after restoring my backups, those postings (which were apparently in the spool directory at the time of backup) came back... 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

Re: Compiling GPC - mysteries
by Frank Heckenbach 16 Sep '99

16 Sep '99

Hi, I hope you don't mind my reply to the list, but perhaps there are others who'd like a little insight into the Makefiles (or correct my mistakes)... The Chief wrote: > To make sure that I was not doing anything wrong, I downloaded the > latest GPC snapshot again, and extracted the files. I am a bit > confused by what I see in the directory tree: > > Directory of C:\cygnus\p > 03/08/99 08:10 23,724 Makefile.in > 1 File(s) 23,724 bytes > > Directory of C:\cygnus\p\rts > 20/06/99 20:11 3,674 Makefile.in > 1 File(s) 3,674 bytes > > Directory of C:\cygnus\p > 03/08/99 08:18 4,139 config-lang.in > 1 File(s) 4,139 bytes > > Directory of C:\cygnus\p\rts > 05/08/99 18:05 3,107 configure.in > 1 File(s) 3,107 bytes > > This shows that there are 2 different copies of 'Makefile.in' in the > GPC source tree. Which is the right one? Both of them. Actually, things are even more complicated. The main Makefile is created from Makefile.in and p/Make-lang.in (and possibly Make-lang.in's of other languages when installed). p/Makefile is created from p/Makefile.in. When you call make, you use Makefile. This does some work and at some time calls make with p/Makefile, calls p/rts/configure which creates p/rts/Makefile from p/rts/Makefile.in, and then calls make with p/rts/Makefile. Complicated, huh? configure.in, p/config-lang.in and p/rts/configure.in are used to create configure and p/rts/configure by the maintainers (with a utility called autoconf), so you don't normally execute them, but only configure, whereas p/rts/configure is called by Makefile (see above). > When I run 'configure' from > the 'rts' directory, everything works okay [...] That might be the problem, very probably indeed. You're not supposed to run configure in the p/rts directory because the Makefile does this and passes some appropriate parameters. In fact, after some recent changes of mine, it is now possible to run configure in p/rts manually -- but only if a current GPC is already installed, which is exactly not the case when building a new version of GPC... > If I copy the other 'Makefile.in' into the rts directory and run 'configure' > from there, a different makefile is generated, which contains > references to 'xgpc'. However, this makefile seems buggy. First, it > points to '../configure' - which doesn't exist. Second, if I copy > 'configure' to where it expects it, then any attempt to run 'make' > results in a message that I should invoke it from top level directory. You should not have to move files around. As described above, the Makefiles and configure scripts in the various directories are quite different ones and only work in their respective directories. > To compile GPC, copy or move `gpc/p' to become a subdirectory `p' > of the GCC source directory, `cd' to the GCC source directory, and > type > > ./configure > make CFLAGS="-g -O3" LANGUAGES=pascal > make CFLAGS="-g -O3" LANGUAGES=pascal install > > Well, this does not work, because 'configure' does not exist in the > GCC source directory. AFAICS it only exists in the 'p/rts' directory, No, it should be in the GCC source directory. If it doesn't, this explains why you ran the "wrong" configure, and probably explains the other problems, but why doesn't it exist? Which GCC sources did you get, the official gcc-2.8.1.tar.gz (or another version) from a GNU site, or from somewhere else? gcc-2.8.1.tar.gz contains one directory (gcc-2.8.1) which is the GCC source directory, and in this directory, there is a configure script. You can rename this directory to whatever you want, but the `p' directory must be a subdirectory of it. So to sum up: > 1. in which exact directory do I have to run 'configure'? In the GCC source directory, which is above the p directory. There must be a configure script there, otherwise something's wrong. You might want to try with the official GNU GCC sources... > 2. why are there 2 different copies of 'makefile.in' ? > 3. which is the correct one? See above. All of them, for different purposes. > 4. in which exact directory do I have to run 'make' ? In the GCC source directory, i.e. the same directory where you ran configure. > 5. Is the generated copy of 'Makefile' correct, or do I have to make > manual changes? You should not have to make any manual changes. However, you might need some additional makeflags (i.e. parameters on the make command line), e.g. (most likely) `exeext=.exe'. Also, you'll need a fairly complete set of GNU file, text and other utilities for the compilation and installation to succeed, including `ln' (in whatever way this might be realised, since MS-Windows does not support symbolic or hard links, AFAIK -- but if `ln' just copies, this would be sufficient here, except for increased disk space usage). Frank -- Frank Heckenbach, frank(a)g-n-u.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Re: GPC on Solaris 2.6
by Frank Heckenbach 16 Sep '99

16 Sep '99

Tom Schneider wrote: > Thanks Frank. Would the following modification just > leave the names alone properly? Yes, but it would leave them alone like the compiler stores them, i.e. first letter capitalized, the rest lower-case. That might not be what you want. It is planned to change this as soon as we've got the qualified identifiers working (before that, doing so would cause name space conflicts with libc). > Also, since I haven't gotten around to applying patches like this, > what would the command line be? Change into the right directory and do `patch < patchfile'. You might need GNU patch (haven't tried Solaris' patch, so I don't know if it works with unified diffs, but after my recent experiences with other Solaris tools, I doubt it...), and take care of the directory which is the most common source of problems with patch (note the `-p' option to patch). Afterwards, of course, recompile and reinstall. 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

4 8

Re: Compiling GPC - round 2
by Frank Heckenbach 16 Sep '99

16 Sep '99

"Dr A Olowofoyeku" wrote: > I now have the gcc sources for egcs-1.1.2 installed. I have run > 'configure' successfully. When I run 'make', I see that some EXEs > have been created in the 'gcc' subdirectory of the GCC source > directory - 'cpp.exe' and 'cccp.exe' (which both seem to be the same > file), That's right, that's just two different names for the same thing (`C Pre-Processor' and `C-Compatible Compiler Preprocessor'). Of course, on a real OS they are hard links to the same inode, so they don't waste disk space twice... > and some '.o' files have also been created there. However, I > finally get this output: > "make[1]: *** No rule to make target `pascal', needed by `native'. > Stop." > > Nothing at all seems to have happened in the 'p' subdirectory of the > GCC source directory. Now the questions: > > 1. Is egcs-1.1.2 okay for compiling GPC ? I think so. I never used EGCS, so, Peter, correct me if I'm wrong. > 2. If not, which version of GCC is okay? > 3. If egcs-1.1.2 is okay, then any suggestions as to what I am doing > wrong? I don't know. Have you: - unpacked GCC and GPC sources from the original archives (not influenced by "round 1") - moved the GPC sources into the right directory (so there is, say, gcc.c in the "main" directory, and gpc.c in a directory called p below it), - run configure in the "main" directory, - been asked if the GCC patch should be applied (or run patch before configure), - run something like `make LANGUAGES=pascal CFLAGS=-O2 exeext=.exe'? If you like, send me a log (your input and the output of the commands -- not the files created), and I'll check 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

Re: Compile gpc-19990118 on Solaris 2.7/7
by Frank Heckenbach 16 Sep '99

16 Sep '99

Kuang-Yu Liu wrote: > Hi, > > I have a novice question. According to p/diffs/gcc-2.8.1.diff parts 12, > 14, 16, files > > gcc-2.8.1/ansidecl.h > gcc-2.8.1/system.h > gcc-2.8.1/mbchar.c > > among other files, need to be patched. My question is my gcc 2.8.1 > source distribution does not have any of these files. I also checked > 2.5.8, 2.7.2.3, and 2.8.0. None of them has these three either. Where > can I find them? I got my gcc source distribution files straight from > GNU Mirror Sites. These files are created when patching. At least GNU patch does this automatically. If your version of patch doesn't, just create empty files of those names. > Trying to use binary distribution of gpc was not good either. I got > error message: > > module/unit interface `Gpc' could not be imported Please use the `--automake' option. 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

Re: External names of GPC-compiled functions (was: GPC on Solaris 2.6)
by Frank Heckenbach 16 Sep '99

16 Sep '99

"Sergio A. Kessler" wrote: > >> >I was rather thinking of something like "MyProgram_MyFunction" > >> >or "MyUnit_MyFunction". When we introduce function overloading, > >> >additional suffixes indicating the parameter types can come up. > >> > >> "GPC_MyUnit_MyFunction" I think this will never choke with the linker... It will very easily. Just declare `int GPC_MyUnit_MyFunction;' in a C file and try to link it. What we should use IMHO is `MyUnit.MyFunction' (or any character instead of `.' that cannot occur in an identifier). Then, we can be sure that it doesn't cause problems (except perhaps with C++ which does its own name mangling, so we might have to look at it -- but it's quite different in different compilers and versions)-: ... > >I'd find it a little egocentric of GPC to name all user > >functions after himself ... ;-) > > I don't think so... GPC must say "this is my territory, don't bother me" > > I think is a clever namespace for GPC, well deserved. > egocentry of a _product_ is not bad ... That's a marketing question, and I don't disagree. ;-) However, as I said, anything only consisting of letters, numbers and underscores in a way is already C's "reserved" name space... 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

Compile gpc-19990118 on Solaris 2.7/7
by Kuang-Yu Liu 15 Sep '99

15 Sep '99

Hi, I have a novice question. According to p/diffs/gcc-2.8.1.diff parts 12, 14, 16, files gcc-2.8.1/ansidecl.h gcc-2.8.1/system.h gcc-2.8.1/mbchar.c among other files, need to be patched. My question is my gcc 2.8.1 source distribution does not have any of these files. I also checked 2.5.8, 2.7.2.3, and 2.8.0. None of them has these three either. Where can I find them? I got my gcc source distribution files straight from GNU Mirror Sites. Trying to use binary distribution of gpc was not good either. I got error message: module/unit interface `Gpc' could not be imported -- Regards, Kuang-Yu Liu liu(a)bacchus.wustl.edu

1 0

Compiling GPC - round 2
by Dr A Olowofoyeku 15 Sep '99

15 Sep '99

Hi all This is round 2. :-? I now have the gcc sources for egcs-1.1.2 installed. I have run 'configure' successfully. When I run 'make', I see that some EXEs have been created in the 'gcc' subdirectory of the GCC source directory - 'cpp.exe' and 'cccp.exe' (which both seem to be the same file), and some '.o' files have also been created there. However, I finally get this output: "make[1]: *** No rule to make target `pascal', needed by `native'. Stop." Nothing at all seems to have happened in the 'p' subdirectory of the GCC source directory. Now the questions: 1. Is egcs-1.1.2 okay for compiling GPC ? 2. If not, which version of GCC is okay? 3. If egcs-1.1.2 is okay, then any suggestions as to what I am doing wrong? Thanks. Best regards, The Chief -------- Dr. Abimbola A. Olowofoyeku (The African Chief) Email: laa12(a)keele.ac.uk Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ Author of: Chief's Installer Pro v5.20a for Win32 ftp://ftp.demon.co.uk/pub/ibmpc/win95/apps/chief32/chief52a.zip

1 0

Re: GPC on Solaris 2.6
by Frank Heckenbach 13 Sep '99

13 Sep '99

Tom Schneider wrote: > However, any file names in the header are demanded by the program > interactively, which makes it useless for me. I posted on this some days ago > on this group with no responses. I would like to see a switch to turn off > the file name requests and have the names default to the ones given in the > header. If that's so crucial to you, you can help yourself with a patch like the following -- after all, GPC is free software. The reason why we don't do this in the official source is becuase most GPC users do not prefer this behaviour, and implementing a switch is more work... If you install the modified GPC in a public place, just make sure to let other users know of the change, to avoid confusion... The upper/lower case issue is not solved. The patch will just convert everything to lower case. --- p/rts/rts.h.orig Mon Aug 2 10:55:22 1999 +++ p/rts/rts.h Mon Sep 13 21:26:37 1999 @@ -435,6 +435,7 @@ extern char *_p_strlcpy PROTO ((char *, const char *, size_t)); extern char *_p_strscan PROTO ((const char *, char)); extern char *_p_strrscan PROTO ((const char *, char)); +extern char *_p_strlower PROTO ((char *)); extern Boolean _p_str_eq PROTO((char *, int, char *, int)); extern Boolean _p_str_lt PROTO((char *, int, char *, int)); extern Boolean _p_eq PROTO((char *, int, char *, int)); --- p/rts/file.c.orig Mon Aug 2 10:44:13 1999 +++ p/rts/file.c Mon Sep 13 21:26:37 1999 @@ -245,6 +245,12 @@ if (isStdFile (File)) return NULL; + /* Derive the external file name from the internal one without + asking the user. This is currently non-standard GPC behaviour! */ + m_EXTNAM (File) = _p_strlower (_p_strdup (m_NAM(File))); + _p_osdirseparator2slash_cstring (m_EXTNAM (File)); + return m_EXTNAM (File); + /* Try to write filename prompts to /dev/tty and try to read responces from there also, to avoid mungling with stdin & stdout. 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

2 1

Re: GNU Pascal on Solaris ?
by Peter Gerwinski 13 Sep '99

13 Sep '99

-- forwarded message -- Path: tim.gerwinski.de!not-for-mail From: Peter Gerwinski <peter(a)gerwinski.de> Newsgroups: comp.lang.pascal.misc Subject: Re: GNU Pascal on Solaris ? Date: 13 Sep 1999 20:33:14 GMT Organization: G-N-U GmbH, http://www.g-n-u.de Lines: 25 Message-ID: <7rjn2a$sk8$1(a)tim.gerwinski.de> References: <37DCC731.9995268F(a)enseeiht.fr> NNTP-Posting-Host: esmeralda.gerwinski.de X-Server-Date: 13 Sep 1999 20:33:14 GMT User-Agent: tin/pre-1.4-980618 (UNIX) (Linux/2.0.36 (i586)) Xref: tim.gerwinski.de comp.lang.pascal.misc:2002 Emmanuel Chaput <Emmanuel.Chaput(a)enseeiht.fr> wrote: > gpc-19990118 : I can not even compile gpc ! "./configure" failed > > gpc-19990607 : The compile failed to compile some simple programs > (gpc1 got signal 11) > > gpc-19990813 : Same as previous ! These versions can be compiled with the GCC backend version 2.8.x and EGCS 1.1.x. GCC version 2.95.x currently CANNOT be used as a backend for GPC. Using that results in failures when compiling even simple programs - which is why I suspect that this is what you tried to do. Please retry compiling GPC with gcc-2.8.x or egcs-1.1.x. Hope this helps, Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75 *** Vote against SPAM! ********* http://www.politik-digital.de/spam/ *** -- end of forwarded message --

1 0

Re: Compiling GPC - initial successes
by Frank Heckenbach 13 Sep '99

13 Sep '99

"Dr A Olowofoyeku" wrote: > > Can you make sure by looking at the make output whether this is the > > case. Normally, the GPC just created (called `xgpc') should be used. > > Can't find any "xgpc". It doesn't seem to be created. So, there > seems to be a problem somewhere :( Neither xgpc.exe or whatever it may be called? The file should be in the GCC main directory (the one above the `p' directory, if you're building in the source directory, and the main build directory otherwise). Can you search for any files with similar names (under Linux, I'd try things like `ls -tr' to see the files created most recently or `ls *gpc*' to see all files with `gpc' in their names, and if you have bash and ls installed, this might work on your system as well)... I think we have to find out why xgpc is not created (or created and not used). So, if the above doesn't provide any clues, perhaps try running the whole configure and make process again (i.e. after a `make distclean'), and send me the whole configure and make output by private mail... > In the meantime, [...] Thoguh this might be an interesting exercise, I don't think you'll get a workable RTS unless when compiling it with the current 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

Re: GPC on Solaris 2.6
by Frank Heckenbach 13 Sep '99

13 Sep '99

Emmanuel Chaput wrote: > I need a Pascal compiler and I have a big problem with gpc. > > I'd like to know if anyone managed to use gpc on a Solaris 2.6 > sun workstation. Yes, I did. There is a binary for Solaris of the lasst beta version (19990118). It was cross-compiled from a Linux host, but runs under Solaris. I also managed smoe time ago to build it natively under Solaris with the help of our sys-admin. It was not quite straightforward. There were some problems with headers, but he knew the problems from GCC and had a solution in the form of fixed headers. These are available from ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/misc/solaris-includes.tar.gz But note that they were used with (I think) Solaris 2.5 and perhaps an older GCC version, so use with care... > Here are the problems I get : > > gpc 2.0 does not want to compile the Pascal source ! It directly > gives the source file to the linker !!! 2.0 is stone age, anyway... ;-) > gpc-19990118 : I can not even compile gpc ! "./configure" failed What is the exact problem? > Here is a program which compilation causes signal 11 : > > program foo; > begin > writeln(round(3.14)) > end. That's a GPC bug. Floating point under Solaris in GPC is quite buggy, I'm afraid. A workaround for this example is using a typed constant rather than a plain constant: program foo; const a:real=3.14; begin writeln(round(a)) end. I've put your example in the testsuite (chaput1.pas), so it will be fixed ASAP... 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

GPC on Solaris 2.6
by Emmanuel Chaput 13 Sep '99

13 Sep '99

Hi ! I need a Pascal compiler and I have a big problem with gpc. I'd like to know if anyone managed to use gpc on a Solaris 2.6 sun workstation. Here are the problems I get : gpc 2.0 does not want to compile the Pascal source ! It directly gives the source file to the linker !!! gpc-19990118 : I can not even compile gpc ! "./configure" failed gpc-19990607 : The compile failed to compile some simple programs (gpc1 got signal 11) gpc-19990813 : Same as previous ! Here is a program which compilation causes signal 11 : program foo; begin writeln(round(3.14)) end. I would appreciate any help !!! Thanks ... Emmanuel Chaput Emmanuel.Chaput(a)enseeiht.fr

2 1

Re: Compiling GPC - initial successes
by Frank Heckenbach 13 Sep '99

13 Sep '99

"Dr A Olowofoyeku" wrote: > > Actually, that's good news. ;-) The GPC sources contain a workaround for > > a mingw problem. Apparently, the mingw problem has been solved now, so > > the workaround doesn't work anymore. But if you remove the workaround, > > i.e. the following lines in rts/file.c, it should work: > > > > #if defined (_WIN32) && !defined (CYGWIN32) > > #define mkdir(path,mode) mkdir(path) > > #endif > > Removing those 3 lines did it. Fine. I'll remove them from the official sources as well. > The process then chokes on compiling 'files.pas', with these errors; > line 257: function 'Sleepmicroseconds' > argument does not match conformant array formal parameter > invalid use of void expression > argument does not match conformant array formal parameter > too few arguments to function 'Ioselect' Strange, this was a bug, but it has been fixed. A possible reason why it still occurs is that there is an older GPC version installed which is used to compile the RTS. This does not work. Can you make sure by looking at the make output whether this is the case. Normally, the GPC just created (called `xgpc') should be used. If it isn't used, you can try giving the parameter `GPC_FOR_TARGET=<file name with full path of xgpc>' to make, but then we should try to find out why that's necessary. You're using the gpc-19990813 sources, aren't you? > line 310: function 'Stringtfdd_rewrite' > assignment from incompatible pointer type > > I have looked at 'files.pas', and it is not obvious why there should be > a problem with those lines. However, I will continue to work on it. In > the meantime, I am open to suggestions ;) There's indeed a bug here. Here's the fix: --- p/rts/files.pas.orig Mon Sep 13 04:21:57 1999 +++ p/rts/files.pas Mon Sep 13 04:22:02 1999 @@ -307,7 +307,7 @@ Buf.Chars := GPC_PChars (@s[1]); Buf.Truncate := True; (**) Buf.StringType := AnyStringLong; - Buf.PLongLength := @GPC_PString (@s)^.Length; + Buf.PLongLength := @Cardinal (GPC_PString (@s)^.Length); AnyStringTFDD_Rewrite (f, Buf) end; > My mistake. It was 2 parameters, but I got confused by all the stars > and commas, etc. I can imagine that well... :-) 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

2 2

Re: Compiling GPC - initial successes
by Frank Heckenbach 13 Sep '99

13 Sep '99

"Dr A Olowofoyeku" wrote: > Okay, so what succeeded? Bash succeeded in running "./configure". > All sorts of things start appearing on my screen, including the fact > that these files were not found; > 1.glob.h > 2.fnmatch.h > 3.sys/statvfs.h > > That did not seem to affect things though. No, it shouldn't. These are files that don't exist on each system, and one of the purposes on configure is exactly to find out if they exist, and write this information to some headers, so the code will use them only if they exist. > The thing finishes running, > and has created a number of files (including config.log and rts- > config.h). I run "make", and some things happen, and then it chokes > on 'file.c', at line:1665. So you get already to the RTS. Not too bad for the first compilation. :-) > It claims that there are too few arguments to > 'mkdir', in the function '_p_mkdir'. Actually, that's good news. ;-) The GPC sources contain a workaround for a mingw problem. Apparently, the mingw problem has been solved now, so the workaround doesn't work anymore. But if you remove the workaround, i.e. the following lines in rts/file.c, it should work: #if defined (_WIN32) && !defined (CYGWIN32) #define mkdir(path,mode) mkdir(path) #endif > I can't seem to locate where 'mkdir' is defined in the Cygwin headers, > but I did find a reference to it in one header file, which seems to > suggest that it takes 3 parameters, instead of 2. 3? That's strange -- according to POSIX, mkdir takes 2 parameters, and in older versions of mingw, it took only 1 parameter. So, I've got no idea what the 3rd parameter could be. So, if removing the workaround doesn't work, please tell me what the parameters are (as far as it says in the headers -- perhaps the parameter names give some hints), and we might need another workaround... :-( 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

2 1

Compiling GPC
by Dr A Olowofoyeku 12 Sep '99

12 Sep '99

Peter Gerwinski once wrote: >The normal procedure is to type first `./configure' and then >`make LANGUAGES=pascal' in the GCC directory that contains the >GPC source in a subdirectory `p'. However I know that mingw32 >needs special care. Like I said before, I can't do anything with "configure" under Win32. The system simply fails to recognise the script as something that it can execute. This is so even when trying to run the script under Bash. Since this script seems really to be a unix thing, perhaps an alternative could be made for non-unix systems? - basically, either to translate the "configure" script into batch commands that the Dos or Windows command interpreters can process (which is probably impossible, because the script seems too complex to translate into a Dos batch file) or to write a Pascal (or C) program that does everything that the "configure" script does. I would do this myself (i.e., translate into a Pascal program) if I understood the script - but I don't (at least, not most of it). Does this seem a feasible option, or am I barking up the wrong tree here? If it is feasible, does anyone wish to take up the task? PS: Perhaps I can get bash to run the script. If I try to run "configure.in", bash seems to start trying to run it, and then finally chokes. However, with "configure", it just says that the file does not exist - which is not true. Doing "ls -all config*" shows that the attributes of "configure.in" are "-rw-r--r--", while those of "configure" are "-rwxr-xr-x". Is the difference significant? If so, what parameters do I pass to "chmod" so as to change the attributes of "configure" to the same one as "configure.in"? Thanks. Best regards, The Chief -------- Dr. Abimbola A. Olowofoyeku (The African Chief) Email: laa12(a)keele.ac.uk Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ Author of: Chief's Installer Pro v5.20a for Win32 ftp://ftp.demon.co.uk/pub/ibmpc/win95/apps/chief32/chief52a.zip

4 5

Re: Compiling GPC
by Frank Heckenbach 11 Sep '99

11 Sep '99

Peter Gerwinski wrote: > The African Chief wrote: > > > > Like I said before, I can't do anything with "configure" under Win32. > > The system simply fails to recognise the script as something that it > > can execute. This is so even when trying to run the script under > > Bash. Since this script seems really to be a unix thing, perhaps an > > alternative could be made for non-unix systems? - basically, either to > > translate the "configure" script into batch commands that the Dos or > > Windows command interpreters can process (which is probably > > impossible, because the script seems too complex to translate into > > a Dos batch file) or to write a Pascal (or C) program that does > > everything that the "configure" script does. I would do this myself > > (i.e., translate into a Pascal program) if I understood the script - but I > > don't (at least, not most of it). If bash already works under mingw, it should be far easier (and a one-time effort) to get the script run by bash than translating it after each release. You might want to try to run the script as 'bash configure' (telling the command interpreter explicitly to run it with bash). This might work, but still run into problems later if it (or something else) tries to execute another script, but it might be worth a try... > Maybe the script expects a program "\bin\sh.exe" because the > first line reads "#!/bin/sh". This problem once occured under > DJGPP ... But by now they've patched bash to avoid this problem, or why doesn't it occur anymore? So, perhaps a similar (or even the same) patch might do for mingw... You might want to ask the one who ported bash to mingw or cygwin how to make it run a script -- he's probably the one who ought to know best --, or ask the DJGPP people how they solved the problem... > > PS: Perhaps I can get bash to run the script. If I try to run > > "configure.in", bash seems to start trying to run it, and then finally > > chokes. However, with "configure", it just says that the file does not > > exist - which is not true. Doing "ls -all config*" shows that the > > attributes of "configure.in" are "-rw-r--r--", while those of "configure" > > are "-rwxr-xr-x". Is the difference significant? > > Yes - `x' means "eXecutable". > > > If so, what parameters > > do I pass to "chmod" so as to change the attributes of "configure" to > > the same one as "configure.in"? > > chmod +x configure.in Isn't this the wrong way around? According to the permissions as given above, configure should be executable, and configure.in should not. Anyway, I suppose, since configure.in does not contain a `#!' in the first line, it is executed by bash, which also happens under Linux (though that's not the right thing to do with this file, because it's not a script, just a template for a script, but that's another issue). But the explicit /bin/sh in configure causes problems (see above). BTW, does it work if you actually create a \bin directory and put bash in it (as a temporary solution)? 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

Re: Re: GPC BUG? or how to use unit-path
by pdietrich＠synstar.de 10 Sep '99

10 Sep '99

Frank, thank you for your help. Using the right argument syntax solves the problem. BTW, I found another problem (or feature?): If you type gpc -L. -lmylib myprog.pas the compiler generates an ld command with "-lmylib" inserted before the myprog binary. So external subroutines called in myprog are not resolved because the loader processes mylib first. To get the link working I typed gpc -L. myprog.pas -lmylib This looks strange to me, and I think the first format works with all c compilers. Peter Frank Heckenbach <frank(a)g-n-u.de> am 09.09.99 00:00:11 An: gpc(a)gnu.de Kopie: (Blindkopie: Peter Dietrich/SYNSTAR/DE) Thema: Re: GPC BUG? or how to use unit-path pdietrich(a)synstar.de wrote: > The --unit-path option does not work (or maybe I don't know, how it works). > The following program "mainprog" uses a unit in directory ..\test-units. I > tried: > > gpc --unit-path ..\test\units mainprog.pas There's an `=' missing after the `--unit-path'. (The GNU compilers treat their command-line arguments differently than most other GNU tools, so you can't omit the `=' after long options...) 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 ________________________________________________________________________________________ This communication contains information which may be confidential. It is for the exclusive use of the intended recipient. If you are not the intended recipient, please note that any distribution, copying or use of this communication or the information in it is prohibited. If you have received this communication in error, please notify us by email or by telephone on ++49 6151 989 0 and then delete the email and any copies of it.

2 1

Re: Re: GPC BUG: Problems with automake and autobuild
by pdietrich＠synstar.de 10 Sep '99

10 Sep '99

Frank, you are right, the problem vanishes when I'm using the "--unit-path=...". Thank you for your advise. Peter Frank Heckenbach <frank(a)g-n-u.de> am 09.09.99 00:05:51 An: gpc(a)gnu.de Kopie: (Blindkopie: Peter Dietrich/SYNSTAR/DE) Thema: Re: GPC BUG: Problems with automake and autobuild pdietrich(a)synstar.de wrote: > If a unit A is included in a USE clause which includes unit B, and B in turn > includes > unit A the compiler gets an error when it tries to compile A again. This is true > with > option --autobuild and option --automake. The error does not occur if all units > are in > the same directory. > Why does the compiler try to recompile A? Since I don't like "circular uses" very much, and therefore don't use them, I don't know exactly how well they're supported now and if there are any bugs. However, a utility which is planned for the nearer future should make their compilation easier... For now, perhaps the problem vanishes if you get the unit-path working and don't need the paths in the source. 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 ________________________________________________________________________________________ This communication contains information which may be confidential. It is for the exclusive use of the intended recipient. If you are not the intended recipient, please note that any distribution, copying or use of this communication or the information in it is prohibited. If you have received this communication in error, please notify us by email or by telephone on ++49 6151 989 0 and then delete the email and any copies of it.

1 0

Additional linking for 'sin, cos' required?
by Matthias Friedrich 09 Sep '99

09 Sep '99

Hello, with the compiler-options 'gpc --automake -o .....' I get the following error on Solaris2.6 : Undefined first referenced symbol in file sinl maths.o cosl Stroem.o ld: fatal: Symbol referencing errors. No output written... although there is no 'sinl' or 'cosl' in the source code. Are there some special Linking-options (e.g. in C the -l option for mathmatical libraries) that I missed?? Hope, somebody can help me Thanks very much Matthias _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ - Matthias Friedrich - email: mafri(a)ipg.uni-freiburg.de

2 1

Re: GPC BUG: Problems with automake and autobuild
by Frank Heckenbach 08 Sep '99

08 Sep '99

pdietrich(a)synstar.de wrote: > If a unit A is included in a USE clause which includes unit B, and B in turn > includes > unit A the compiler gets an error when it tries to compile A again. This is true > with > option --autobuild and option --automake. The error does not occur if all units > are in > the same directory. > Why does the compiler try to recompile A? Since I don't like "circular uses" very much, and therefore don't use them, I don't know exactly how well they're supported now and if there are any bugs. However, a utility which is planned for the nearer future should make their compilation easier... For now, perhaps the problem vanishes if you get the unit-path working and don't need the paths in the source. 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

Re: GPC BUG? or how to use unit-path
by Frank Heckenbach 08 Sep '99

08 Sep '99

pdietrich(a)synstar.de wrote: > The --unit-path option does not work (or maybe I don't know, how it works). > The following program "mainprog" uses a unit in directory ..\test-units. I > tried: > > gpc --unit-path ..\test\units mainprog.pas There's an `=' missing after the `--unit-path'. (The GNU compilers treat their command-line arguments differently than most other GNU tools, so you can't omit the `=' after long options...) 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

GPC BUG: Problems with automake and autobuild
by pdietrich＠synstar.de 08 Sep '99

08 Sep '99

Hello, I found the following bug in the Beta version of GPC. Best regards, Peter Dietrich -------------------- GPC-Version (gpc -v): Reading specs from C:\usr\local\lib\gcc-lib\i386-mingw32\2.8.1\specs gpc version 19990118, based on gcc-2.8.1 System-Version: Windows NT 4.0 on i386 Problem description: If a unit A is included in a USE clause which includes unit B, and B in turn includes unit A the compiler gets an error when it tries to compile A again. This is true with option --autobuild and option --automake. The error does not occur if all units are in the same directory. Why does the compiler try to recompile A? Looking at the gpi file I found that only the filename is stored, not the full or relative path name. In the following test case replace A by "windows.pas" and B by "sysutils.pas": C:\Di\gp\uvw>gpc --autobuild -g -O0 --extended-syntax --short-circuit ..\lib\kernel32.a uvw.pas ..\\isidef\\isidefnt.pas:99: warning: identifiers should not contain two adjacent underscores ..\\isidef\\isidefnt.pas:137: warning: identifiers should not start with an underscore ..\\lib\\sysdef.pas:21: warning: identifiers should not start with an underscore ..\\lib\\sysdef.pas:46: warning: identifiers should not contain two adjacent underscores uvw_def.pas:13: module `windows' could not be compiled gpc1.exe: gpc exited with status 1 uvw.pas:44: module `uvw_def' could not be compiled C:\Di\gp\uvw>dir DatentrÃ¤ger in Laufwerk C: hat keine Bezeichnung. DatentrÃ¤gernummer: 18CF-0161 Verzeichnis von C:\Di\gp\uvw 08.09.99 14:37 <DIR> . 08.09.99 14:37 <DIR> .. 08.09.99 14:29 118.175 gpc.gpi 08.09.99 14:29 7.882 gpc.o 08.09.99 14:29 53.174 isidefnt.gpi 08.09.99 14:29 37.585 isidefnt.o 08.09.99 14:29 34.918 sysdef.gpi 08.09.99 14:29 6.140 sysdef.o 08.09.99 14:29 21.989 sysutils.gpi 08.09.99 14:29 13.331 sysutils.o 08.09.99 14:37 3.511 units.txt 08.09.99 13:44 169.401 uvw.pas 08.09.99 12:04 71.933 uvw_def.pas 08.09.99 14:29 19.733 windows.gpi 08.09.99 14:29 5.437 windows.o 15 Datei(en) 563.209 Bytes 683.836.416 Bytes frei C:\Di\gp\uvw>dir ..\lib DatentrÃ¤ger in Laufwerk C: hat keine Bezeichnung. DatentrÃ¤gernummer: 18CF-0161 Verzeichnis von C:\Di\gp\lib 08.09.99 14:18 <DIR> . 08.09.99 14:18 <DIR> .. 16.06.99 12:18 14.286 kernel32.a 16.06.99 12:18 293 kernel32.def 08.09.99 14:04 5.650 paslib.pas 08.09.99 13:58 32.315 ssvlib.pas 08.09.99 13:21 14.523 sysdef.pas 08.09.99 14:18 6.085 sysutils.pas 08.09.99 14:29 5.754 windows.pas 9 Datei(en) 78.906 Bytes 683.840.000 Bytes frei C:\Di\gp\uvw>dir ..\isidef DatentrÃ¤ger in Laufwerk C: hat keine Bezeichnung. DatentrÃ¤gernummer: 18CF-0161 Verzeichnis von C:\Di\gp\isidef 08.09.99 11:57 <DIR> . 08.09.99 11:57 <DIR> .. 21.04.99 11:46 469 iokeywords.pas 08.09.99 13:41 279.742 isidef.pas 21.06.99 12:27 78.592 isidefdt.pas 08.09.99 14:03 31.008 isidefmap.pas 10.06.99 13:28 43.015 isidefmap.pas.uvw 10.06.99 12:22 353 isidefmap_U.PAS 03.06.99 10:00 2.525 isidefmsg.pas 08.09.99 13:32 31.246 isidefnt.pas 17.06.99 15:26 1.388 test_isidef.pas 11 Datei(en) 468.338 Bytes 683.840.000 Bytes frei C:\Di\gp\uvw> Headers of program and units: ----------------------------- PROGRAM uvw ; {$IFDEF __GPC__} {$DEFINE GP} {$ELSE} {$DEFINE BP} {$LONGSTRINGS ON} {$APPTYPE CONSOLE} {$ENDIF} {$B-} USES {$IFDEF BP} Sharemem, Math, FileCtrl, SysUtils, sysdef, isidefnt, uvw_def; {$ELSE} sysutils in '..\lib\sysutils.pas', sysdef in '..\lib\sysdef.pas', isidefnt in '..\isidef\isidefnt.pas', uvw_def; {$ENDIF} -------- UNIT sysutils; INTERFACE USES GPC, windows in '..\lib\windows.pas'; -------- UNIT windows; INTERFACE USES GPC; -------- UNIT sysdef; {$IFDEF __GPC__} {$DEFINE GP} {$ELSE} {$DEFINE BP} {$LONGSTRINGS ON} {$ENDIF} INTERFACE USES {$IFDEF BP} Sharemem, isidefnt; {$ELSE} isidefnt in '..\isidef\isidefnt.pas'; {$ENDIF} -------- UNIT isidefnt; {$IFDEF __GPC__} {$DEFINE GP} {$ELSE} {$DEFINE BP} {$LONGSTRINGS ON} {$ENDIF} INTERFACE USES {$IFDEF BP} Sharemem, Math, FileCtrl, Windows, SysUtils; {$ELSE} GPC, windows in '..\lib\windows.pas', sysutils in '..\lib\sysutils.pas'; {$ENDIF} -------- UNIT uvw_def; INTERFACE USES {$IFDEF BP} Sharemem, Math, sysutils, sysdef, isidefnt; {$ELSE} sysutils in '..\lib\sysutils.pas', sysdef in '..\lib\sysdef.pas', isidefnt in '..\isidef\isidefnt.pas'; {$ENDIF} ________________________________________________________________________________________ This communication contains information which may be confidential. It is for the exclusive use of the intended recipient. If you are not the intended recipient, please note that any distribution, copying or use of this communication or the information in it is prohibited. If you have received this communication in error, please notify us by email or by telephone on ++49 6151 989 0 and then delete the email and any copies of it.

1 0

GPC BUG? or how to use unit-path
by pdietrich＠synstar.de 08 Sep '99

08 Sep '99

Hello, The --unit-path option does not work (or maybe I don't know, how it works). The following program "mainprog" uses a unit in directory ..\test-units. I tried: gpc --unit-path ..\test\units mainprog.pas where mainprog.pas was: program mainprog; uses gpc, unit1; begin unitvar := 'Test ok'; writeln (unitvar); end. The compiler complained that it could not compile "unit1". Then I tried: gpc --autobuild mainprog.pas where mainprog.pas was: program mainprog; uses gpc, unit1 in '..\test-units\unit1.pas'; begin unitvar := 'Test ok'; writeln (unitvar); end. This worked, but I don't like to put pathnames into source code. Is there a better way to do compilations with units in different directories? Best regards, Peter Dietrich -------------------- GPC-Version (gpc -v): Reading specs from C:\usr\local\lib\gcc-lib\i386-mingw32\2.8.1\specs gpc version 19990118, based on gcc-2.8.1 System-Version: Windows NT 4.0 on i386 ________________________________________________________________________________________ This communication contains information which may be confidential. It is for the exclusive use of the intended recipient. If you are not the intended recipient, please note that any distribution, copying or use of this communication or the information in it is prohibited. If you have received this communication in error, please notify us by email or by telephone on ++49 6151 989 0 and then delete the email and any copies of it.

2 1

WHERE ARE THE INTERFACES - beginners doubt
by Rabay＠passos.uemg.br 06 Sep '99

06 Sep '99

Hi All, i have just installed the binary version of GPascal in a 586 linux machine. When I try to compile some demo, for instance power.pas I get this error message: power.pas :25: module/unit interface 'Gpc' could not be imported It seems a path problem - the compiler can not find any interface modules. Is there a place where they should be? I have read the documentation but I've found no hints. Could someone give me some help? Thanks in advance. Gualberto Rabay Univ. of Minas Gerais - Brazil to: IN:gpc@gnu.de cc: rabay

2 1

Re: Compiling GPC
by Frank Heckenbach 06 Sep '99

06 Sep '99

"Dr A Olowofoyeku" wrote: > Peter Gerwinski wrote: > > >The normal procedure is to type first `./configure' and then > >`make LANGUAGES=pascal' in the GCC directory that contains the > >GPC source in a subdirectory `p'. However I know that mingw32 > >needs special care. > > You are right. For one, there is no such program as "configure". This > must be a Linux thing, or am I missing something here? A configure script comes with the GCC sources (which you need to build GPC, anyway). However, I don't know if it runs under mingw (if bash runs under mingw, there might be a chance)... 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

2 1

Re: CStrings getting corrupted on return from Modules.
by Frank Heckenbach 05 Sep '99

05 Sep '99

Just to clarify some points about CStrings which are really confusing... "Kevin A. Foss" wrote: > > Your program is doing exactly what you told it to do You defined a CString > > which begins byte1 = H, > > byte 2 = e, etc., disabled error detection with {$X+} and then called it a > > string: first 4 bytes is capacity, > > next 4 bytes current length, then the string bytes > [...] > > So take out the {$X+} and use functions CString2String and String2CString > > where you need them. > > Yes, this seems to be exactly what I need. Like I said in my original > message it was just a case of me misunderstanding how the different > string types cooperate -- and I mistakenly thought that straight > CString := String assignments worked in a previous gpc version. GPC does in fact support assignments of Pascal strings to CStrings and handles them correctly (i.e., sets the CString pointer to the beginning of the text in the string, not to the capacity field, and adds a #0 terminator). That was not the problem in your program. The problem was that a local variable is assigned to a CString, and the variable vanishes after the function returns, and a CString is only a pointer and therefore does not contain a *copy* of the text, but only points to the variable which is gone. This problem will *not* be solved if you use String2CString -- even though it might appear so, since it works a little different internally, the result is still undefined and could be wrong some day. Correct solutions are e.g. GetMem/FreeMem (or New/Dispose), or declaring the local variable static -- in this case it will not vanish, so the CString will remain valid after the function returns, but only until the local variable is changed (i.e., until the function is called again, in general). Something like this is in fact what some libc routines do, and this is considered quite problematic (more difficult to use from a program, not thread-safe, etc.), therefore also my advice: don't use CStrings here. :-) > Is there a guide to all of the different String functions for > conversion and what not? Not yet, I think, but I as far as CStrings are concerned, String2CString and CString2String should be all that's needed (and the former one only rarely, because of the automatic String 2 CString assignments). Also, the block of functions from CStringLength to CopyCString in the GPC unit deals with CStrings. When calling a routine (of the RTS or of some C library) that expects a CString parameter, don't worry, just pass it a Pascal string :-) -- unless the function will modify the CString, then things get more difficult... 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

3 2

Re: Help! Nothing runs
by Frank Heckenbach 05 Sep '99

05 Sep '99

Some days ago, I sent the following message, but it did not seem to arrive for some reason. So, another try, sorry if anyone gets this twice... > > > internal error: duplicate constructor I'm still on vacation, therefore only a short answer. The message is produced by the RTS, but is harmless. You can simply comment it out in one of the files in the rts directory (don't have the sources handy, but you can easily grep for it). This has already been done in the current alpha versions. Frank -- Frank Heckenbach, frank(a)g-n-u.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Re: make error
by Frank Heckenbach 05 Sep '99

05 Sep '99

"Dmitry S. Luhtionov" wrote: > This message has been displayed when i try build gpc-19990813.tar.gz > > OS: FreeBSD 3.2 > > # make > `echo gcc | sed 's/gcc/gpc/'` -c -I. -Wall -Wpointer-arith -Wmissing-prototypes > -Wmissing-declarations -O2 -DBSD_RTS=0 `if [ x = xyes ] ; then echo -fPIC; fi` > --unit-path= --automake files.pas > files.pas: In function `Sleepmicroseconds': > files.pas:257: argument does not match conformant array formal parameter > files.pas:257: incompatible type for argument 1 of `Ioselect' > files.pas:257: argument does not match conformant array formal parameter > files.pas:257: too few arguments to function `Ioselect' > files.pas: In function `Stringtfdd_rewrite': > files.pas:310: assignment from incompatible pointer type > *** Error code 1 The problem is (I suppose) that an older installed gpc (`echo gcc | sed 's/gcc/gpc/'`) is used to build the RTS rather than the GPC just created. This cannot work since the RTS relies on the latest compiler features. Did you specify any configure or make options (like GCC_FOR_TARGET) or environment variables? If so, try without them. 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

Re: re; new snapshot
by Frank Heckenbach 05 Sep '99

05 Sep '99

"Russ Whitaker" wrote: > ran into two little bugs: > > 1: Since compiling previous snapshot changed motherboards here > so i486 became i586. Ran into the "ar" bug again. While a soft link > fixes the problem, changing line 74 of Makefile.in does it nicely: > > From: > AR = ar > To: > AR = /usr/bin/ar I think /usr/bin/ar might not be correcton every system. You said you ran into this bug again. When was the first time, I don't remember, and what was the cure then? Why does `AR = ar' not work on yor system, if ar is in /usr/bin (and /usr/bin is certainly in your $PATH, isn't it)? Besides, since this is the GCC Makefile.in, we can't really make any changes there, anyway... > 2. The date in gpc_release doesn't match the snapshot date Yep. Shouldn't be a serious problem, however. ;-) 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

header files
by Simon Nath 05 Sep '99

05 Sep '99

Hi, I'm trying to modularize my pascal programs into multiple source files. I was able to do this using Units but now I'm having trouble defining data types and global variables in a single file that can be included by pascal source files. Is there an interface file or definition file concept in GNU Pascal? Thanks -simon ____________________________________________________________________ Get your own FREE, personal Netscape WebMail account today at http://webmail.netscape.com.

4 3

Re: Internal compiler error with arithmetic or arrays?
by Frank Heckenbach 05 Sep '99

05 Sep '99

Matthias Friedrich wrote: > Hello! > > Who can help me with my gpc-compiler error? I think its an arithmetic problem, > maybe the declaration of Single-Arrays... > > > > The following code produces an 'Internal compiler error: program gpc1 got fatal > signal 6' on my Solaris2.6 system: Unfortunately, real arithmetic is buggy under Solaris. I added your program to our test suite (matt1.pas). 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

Re: gpc-19990813+gcc-2.95.1/alphaev56-dec-osf4.0d => failure
by Frank Heckenbach 05 Sep '99

05 Sep '99

Alexandre Oliva wrote: > --- gcc/p/rts/rts.c~ Fri Aug 6 12:49:33 1999 > +++ gcc/p/rts/rts.c Sun Aug 29 15:29:31 1999 > @@ -330,6 +330,10 @@ > > static clock_t initial_clocks = 0; > > +#ifndef CLOCKS_PER_SEC > +#define CLOCKS_PER_SEC 1000 > +#endif > + > int > _p_get_cpu_time (MicroSecond) > int *MicroSecond; Hmpf. Isn't there another way to get the value on this system (perhaps in another header file, or under another name)? The code above would set it to 1000 whenever it's not defined. This might be wrong on a system that uses a value other than 1000 and does not define CLOCKS_PER_SEC in the headers we include. 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

Re: DIV bug found in GPC 19990510
by Frank Heckenbach 05 Sep '99

05 Sep '99

"GPC on Ken Linder's Linux Box" wrote: > Howdy all... > Found an oddity with the DIV operation. The following line correctly > produces a compile error (as it should): > > aninteger := 12.1 div 5.5; > > However, the following compiles & runs, behaving like a REAL division > operation: > > writeln( 12.1 div 5.5 ); > > Very strange indeed! Thanks for the report (kevin14.pas). 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

gpc-
by Jochen 05 Sep '99

05 Sep '99

Hi All, first of all: Is there an uptodate archive of the mailing list ? I try to compile a gcc-2.95.1 patched/extended by the gpc-19990813 sources/patch. (Same results with plain gcc-2.95.) This is on alpha-de-linux-gnu and i586-ps-linux-gnu. After applying the gcc-2.95 patch and moving the p directory, I do a configure and the make bootstrap. I always get the following error about object files that cannot be build (right after libiberty.a is build): stage1/xgcc -Bstage1/ -B/usr/alphaev5-dec-linux-gnu/bin/ -DGPC -DIN_GCC -DHAIFA -O2 -O3 -pipe -Wall -DHAVE_CONFIG_H -I. -I../../gcc-2.95.1/gcc -I../../gcc-2.95.1/gcc/config -I../../gcc-2.95.1/gcc/../include \ -DGPC_MAJOR="\"2\"" \ -DGPC_MINOR="\"0\"" \ -DGPC_RELEASE="\"`cat ../../gcc-2.95.1/gcc/p/gpc_release`\"" \ -DSTANDARD_STARTFILE_PREFIX=\"/usr/lib/\" -DSTANDARD_EXEC_PREFIX=\"/usr/lib/gcc-lib/\" -DDEFAULT_TARGET_VERSION=\"2.95.1\" -DDEFAULT_TARGET_MACHINE=\"alphaev5-dec-linux-gnu\" -DTOOLDIR_BASE_PREFIX=\"/usr/\" \ -c `echo ../../gcc-2.95.1/gcc/p/gpc.c | sed 's,^\./,,'` -o p/gpc.o ../../gcc-2.95.1/gcc/p/gpc.c: In function `read_specs': ../../gcc-2.95.1/gcc/p/gpc.c:1770: warning: implicit declaration of function `read' ../../gcc-2.95.1/gcc/p/gpc.c:1774: warning: implicit declaration of function `close' ../../gcc-2.95.1/gcc/p/gpc.c: In function `delete_if_ordinary': ../../gcc-2.95.1/gcc/p/gpc.c:2092: warning: implicit declaration of function `unlink' ../../gcc-2.95.1/gcc/p/gpc.c: In function `putenv_from_prefixes': ../../gcc-2.95.1/gcc/p/gpc.c:2269: warning: implicit declaration of function `putenv' ../../gcc-2.95.1/gcc/p/gpc.c: In function `find_a_file': ../../gcc-2.95.1/gcc/p/gpc.c:2299: warning: implicit declaration of function `access' ../../gcc-2.95.1/gcc/p/gpc.c: In function `init_automake_temp_file_name': ../../gcc-2.95.1/gcc/p/gpc.c:4821: warning: unused variable `is_pascal' ../../gcc-2.95.1/gcc/p/gpc.c: In function `fatal_error': ../../gcc-2.95.1/gcc/p/gpc.c:5069: warning: implicit declaration of function `getpid' ../../gcc-2.95.1/gcc/p/gpc.c: In function `main': ../../gcc-2.95.1/gcc/p/gpc.c:5087: warning: unused variable `buf' make[2]: *** No rule to make target `choose-temp.o', needed by `xgpc'. Stop. make[2]: Leaving directory `/tmp/gcc/gcc' make[1]: *** [bootstrap] Error 2 make[1]: Leaving directory `/tmp/gcc/gcc' make: *** [bootstrap] Error 2 Is this a known problem ? Any ideas or help ? PS: I am currently using the available binaries for gpc build against gcc-2.8.1 for evaluation. This is not a solution, though, since I want to use it in a mixed C++/FORTRAN/PASCAL project where I need the newer gcc-2.95. -- Jochen Heinrich-Heine-Universität Düsseldorf jochen(a)uni-duesseldorf.de Institut für Physikalische Chemie I phone ++49-211-8113681 Universitätsstr. 26.43.02.29 fax ++49-211-8115195 40225 Düsseldorf, Germany www-public.rz.uni-duesseldorf.de/~jochen

4 4

Compiling GPC
by Dr A Olowofoyeku 05 Sep '99

05 Sep '99

Peter Gerwinski wrote: >The normal procedure is to type first `./configure' and then >`make LANGUAGES=pascal' in the GCC directory that contains the >GPC source in a subdirectory `p'. However I know that mingw32 >needs special care. You are right. For one, there is no such program as "configure". This must be a Linux thing, or am I missing something here? > Better ask the list for help. Ok. Anyone managed to compile GPC for Mingw32 successfully? If so, can you please give me any tips? Thanks. Best regards, The Chief -------- Dr. Abimbola A. Olowofoyeku (The African Chief) Email: laa12(a)keele.ac.uk Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ Author of: Chief's Installer Pro v5.20a for Win32 ftp://ftp.demon.co.uk/pub/ibmpc/win95/apps/chief32/chief52a.zip

1 0

Problems building new snapshot under EGCS
by david＠tcs01.demon.co.uk 05 Sep '99

05 Sep '99

In message <38919B7D.19990813155556.FOO-5D74.frank(a)g-n-u.de> Frank Heckenbach writes: > Hello, folks, > > a new GPC snapshot is available: > > ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/gpc-19990813.tar.gz > Help! I'm having lots of problems building the new snapshot under RedHat Linux 6.0 (kernel 2.2.5-15 on i586) using EGCS (source RPM egcs-1.1.2-12, appears to be version 2.91.66). I unpacked the egcs source into a directory tree, moved the snapshot's p directory into gcc, applied the gcc-egcs-2.91.66 patch (after a bit of editing of directory names within the patch file), did a ./configure, and am now trying make LANGUAGES=pascal. Is this the correct sequence of actions? The INSTALL file in the snapshot doesn't seem to cover building GPC under EGCS. I guess my first question is: should I be using EGCS or would I be better off with a plain gcc source, and if so what version? Various things I've come across so far: The p/gpc_release file contains 19990610, I think it should contain 19990813. I think there is something strange about the way the contents of the gpc_release file is accessed - at the point where I see the make doing a cd p, I then see an error message from cat that it cannot find the gpc_release file. It looks as if there is one too few "../"s on the front of the path to the file. In p/gpc-common.c at line 2893, TREU_OVERFLOW should be TREE_OVERFLOW, I think. (Not a GPC problem): In my gcc/flow.c at line 1493, the code says REG_N_SEDS, it should be REG_N_SETS, I think. Finally, I come to a halt with make[1]: Entering directory `/home/david/egcs/objs/gcc' gcc -DIN_GCC -g -O2 -DHAVE_CONFIG_H -o cc1 c-parse.o c-lang.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common collect2: ld terminated with signal 11 [Segmentation fault], core dumped make[1]: *** [cc1] Error 1 make: *** [all-gcc] Error 2 make[1]: Leaving directory `/home/david/egcs/objs/gcc' I think the GCC line has been truncated in copying it between systems. Has anyone succeeded in compiling this snapshot in a similar environment? -- David James mailto:david@tcs01.demon.co.uk Special Stage Rally results archive <URL:http://www.tcs01.demon.co.uk/>

3 2

Division by 'Single' not allowed ?
by Matthias Friedrich 05 Sep '99

05 Sep '99

Hello! In my previous mail to this mailing list yesterday I had an 'Internal Compiler Error'. Now I changed the last few lines to: For i:=1 to II DO if h_c[i,j,k]=1 then begin if dx[i]<0 then test:=-(exp(ln(-dx[i])*(-1))) else test:=(exp(ln(dx[i])*(-1))); du:=abs((0.5*(UU[i,j,k]+UU[i+1,j,k]))*test); This works! And it means to me that the division by a 'Single'-Variable is not always allowed in GNUPascal. Is this true (or is there a bug) ?? Hope somebody can helpme Thanks for your answers Matthias _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ - Matthias Friedrich - email: mafri(a)ipg.uni-freiburg.de

1 0

Internal compiler error with arithmetic or arrays?
by Matthias Friedrich 05 Sep '99

05 Sep '99

Hello! Who can help me with my gpc-compiler error? I think its an arithmetic problem, maybe the declaration of Single-Arrays... The following code produces an 'Internal compiler error: program gpc1 got fatal signal 6' on my Solaris2.6 system: function GetdtCourant:Single; var i,j,k:Integer; du,dv,dw:Single; dtmax,dthier:Single; begin dtmax:=10.0; if LowWindMode then dtmax:=0.1; For k:=1 to KK DO For j:=1 to JJ DO For i:=1 to II DO if h_c[i,j,k]=1 then begin du:=abs((0.5*(UU[i,j,k]+UU[i+1,j,k]))/dx[i]);gpc: Internal compiler error: program gpc1 got fatal signal 6 If I replace 'dx[i]' with '2' or '2.5', it works. (I find it strange...) For better debugging I append the declaration of all variables and constants: UNIT Stroemtest; INTERFACE function GetdtCourant:Single; const max_x=70; const MAX_Y=70; const MAX_Z=32; const maxCFLStep:Single=1.0; const ee:Single=1*10e-10; const courantfactor:Single=1.0; const MAX_Zges=32+15; type maingrid= Array[1..max_X,1..Max_Y,0..Max_Z] of Single; var uu: maingrid; vv: maingrid; ww: maingrid; LowWindMode: Boolean=false; II: SmallInt; JJ: smallInt; KK: Smallint; H_c: Array[1..max_X,1..Max_Y,0..Max_Z] of Byte; dx: Array[0..Max_x] of Single; dy: Array[0..Max_y] of Single; dz: ARRAY[0..MAX_Zges] of Single; IMPLEMENTATION function GetdtCourant:Single; var i,j,k:Integer; . . . . ==> great thanks for helping Matthias _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ - Matthias Friedrich - email: mafri(a)ipg.uni-freiburg.de

1 0

`IN' operator warning
by GPC on Ken Linder's Linux Box 05 Sep '99

05 Sep '99

I have the following simple program: program fooin; var s1, s2, s3 : integer; begin s1 := 1; s2 := 3; s3 := 5; if 10 in [s1, s2, s3] then writeln('OK') else writeln('not OK') end. The code itself executes ok but at compilation gives this warning: fooin.pas:8: warning: constructing limited integer set '0..255' Does this mean I can compare a single ordinal (LHS) to a set with a maximum number of elements of 255 (RHS) ? TNX Ken Linder http://kc7rad.lvcm.com/

2 1

Unsubscribe
by John Herbster 05 Sep '99

05 Sep '99

I wish that you were a NEWSGROUP instead of just a mailing list. I =would have read a lot more of the messages. John Herbster, Herbster Scientific, 12807 Park Royal, Houston, TX w077-2249, Phn:281-531-4423, herb-sci(a)swbell.net, Elders Unite Against =Ignorance and Stupidity

2 1

Help! Nothing runs
by John L. Ries 05 Sep '99

05 Sep '99

I installed the latest GPC beta (gpc-19990118) on a DEC3000/800 (Alpha) running Digital UNIX 4.0B and was able to compile and install without difficulty. However, anything I compile gives me the following error message when run: internal error: duplicate constructor No coredump or anything else is produced. I compiled on top of GCC 2.8.1. 128 MB of RAM is installed. I uninstalled the DEC Pascal runtime to insure no conflict. John L. Ries System Administrator Salford Systems Phone: (619) 543-8880 x25 Fax: (619) 543-8888 E-Mail: jries(a)salford-systems.com

2 2

GNU pascal installation problem
by Konstantin R.Beliaev 05 Sep '99

05 Sep '99

Hello! I'm trying to install the GNU pascal (version gpc-19990118 + gcc-2.8.1) on FreeBSD 2.2.8, but without success. The installation stops when I "make LANGUAGES=pascal" with message "`all' not remade because of errors". The latest command the script executes is "gcc -DIN_GCC -g -DHAVE_CONFIG_H obstack.o ` case "gcc" in "cc") echo "" ;; esac ` -o c++filt cxxmain.o underscore.o getopt.o getopt1.o" Please, HELP ! Reply to my e-mail: konst(a)RL7.bmstu.ru With hope, Konstantin

2 1

Re: gpc-19990813+gcc-2.95.1/alphaev56-dec-osf4.0d => failure
by Nick Burrett 05 Sep '99

05 Sep '99

Alexandre Oliva <oliva(a)dcc.unicamp.br> writes: > On Aug 31, 1999, Nick Burrett <nick(a)dsvr.net> wrote: > > > Alexandre Oliva <oliva(a)dcc.unicamp.br> writes: > > >> +++ gcc/p/rts/file.c Sun Aug 29 15:56:11 1999 > >> @@ -887,7 +887,7 @@ > >> _p_f_write (File, Buf, Size) > [snip] > >> - ssize_t result = > >> + size_t result = > [snip] > >> - if (result < 0) > >> + if (result == (size_t)-1) > > > You cannot do this. size_t may be unsigned. > > That's the reason why I'm explicitly casting -1 to that type. > > > Also fwrite returned zero on error > > That's not covered in the original code. Since I've never heard of > fwrite returning less than -1, I think it is as correct as the > original code. I'm suggesting that perhaps you stumbled across a proper bug. According to the man pages fwrite returns 0 on error and >0 on success. This is why I originally suggested that your fix may be not quite correct. We'll come up with a proper solution if you want. Cheers, Nick.

1 0

Re: option for file name input supression
by Tom Schneider 05 Sep '99

05 Sep '99

Peter: For folks on the mailing list, the issues I'm concerned with are: 1. Gpc asks for file names. I have some 200 pascal programs http://www.lecb.ncifcrf.gov/~toms/delila/delilaprograms.html and each uses as many as 10 file names. Typing all this is a waste of my time. No other compiler I've encountered (Sun, vax, CDC Cyber (!)) does this. So I'm suggesting that there be an option on gpc to simply use the file name given in the header line of the program. 2. When gpc asks for the file name, it capitalizes it. On Unix file names are case sensitive, so this is setting up for confusion and ambiguity. So I am suggesting that file names be left alone. No changing of case from what the user does. ... > > I can't do this because it would force my 200 programs to become compiler > > specific. No compiler I have encountered in the past 15 years ever forced me > > to do this. > > So all standard Pascal compilers use the same mechanism to > derive the external file name from the variable name? > Interesting. If so, GPC should do the same. Well, I don't know about ALL or how standard they are. I am currently working on Sun's rather stable complier (but hey, I found bugs in it too!! ;-). The CDC Cyber - an ancient beast running an OS called Kronos - had a really neat feature that I was sorry to see go when I went to Unix. One would type the program name followed by a series of file names: for program x(a,b,c,d,output); one could type x,1,,2,3 Kronos would: map 1 to a use file b for b map 2 to c map 3 to d That was rather handy and very quick to type. Such an option - in which if one didn't type anything at all one would get all file names to default - would be VERY handy. > How do they deal with inconsistent capitalization? Sun flags it as an unidentified symbol: program x(output); var a: integer; begin A := 5; end. 4 A := 5; E 18420---------^--- Undefined variable In program x: E 18240 A undefined on line 4 So it evidently just treats "a" and "A" as different symbols. program x(output); var a: integer; A: char; begin a := 5; A := '!'; end. I tried that and it compiled just fine. > > Is it really that difficult to have an option to just use the name as given > > in the header line? [...] > > The only problem is the capitalization issue; see below. > > > While it may be true that Pascal is supposed to be case-insensitive, it turns > > out that under Solaris it is case sensitive. This has already forced me to > > be *consistent* with the names I use, which is not unreasonable. > > Yes, I am also consistent with capitalization of my Pascal > sources, but the compiler must not depend on this. This is a matter of standards. It actually scares me that one can have that second program above and not realize the situation! However, I DO like the idea of being consistent throughout the program: either A or a, but not both. I do not like the idea of the program changing the capitalization that I set. > > It seems to me that you must have put a mechanism IN to capitalize the first > > letter. All I'm saying is that it would be best simply to remove that > > mechanism. It would be simpler, cleaner and never confusing. > > It would make user identifiers crash with libc functions while > linking. Oy. I had this problem when I first started working with Sun. It is irritating!!! In Pascal I used to have my main procedure named ... main of course. Well that is illegal because it conflicts with the underlying C compiler! (I renamed them 'themain', ugh.) What's really annoying is that I could easily have a variable named main inside the procedure, since its scope would be protected. *************************************************************** * SCOPE SOLUTION: * * Why can't the concept of symbol scope be applied to the * * entire program? Then there would be no conflict at all and * * Pascal names would be independent of the damn C complier * * names!!! * *************************************************************** On the Sun compiler, this code compiles just fine: program x(output); var a: integer; A: char; procedure x(z: char); procedure main(j: char); begin writeln(output,j); end; begin main(z); end; begin a := 5; A := '!'; x(A); end. Though the following compiles, it fails rather weirdly: program x(output); var a: integer; A: char; procedure main(z: char); procedure themain(j: char); begin writeln(output,j,' in themain'); end; begin writeln(output,z,' in main'); themain(z); end; begin a := 5; A := '?'; main(A); end. gives: ----- in main in themain ---- So using the word 'main' messes up the variable transfer. If I change the name to xmain, it works ok: ---- ? in main ? in themain ---- > What we could do is to keep the capitalization of the first > occurrence of each identifier for use with the option you are > suggesting. My initial suggestion was that if you are going to ask for file names, the string you should give should match the name in the pascal program header. *Anything* *else* is setting up for confusion on the part of the user! > It would also be a good thing for error messages and such. No, it would lead to confusion on operating systems like Unix which are case sensitive for file names. Just leave the names alone, don't modify them. > For public names however, we must use something that > does not overlap with the name space of the C library. See above scope suggestion. > Introducing this would be non-trivial. It would also be > possible (and much easier) to put the identifier into lower case > in order to derive the file name. If you make *ANY* changes in the name, you are setting it up to cause trouble at some point. I would think that ignoring the case would be simpler. > Since the discussion is now about suggested changes to GPC, > I think it's really time to move it to the GPC mailing list > <gpc(a)gnu.de>. Be welcome to forward or cite my mail there. Ok, here goes! Hmm. Thats funny. On http://agnes.dida.physik.uni-essen.de/~gnu-pascal/support.html#archives it gives gpc(a)hut.fi. as the mailing list name. Which is correct? (While we are at it, would you mind removing the periods at the ends of emails and urls on that page? They make it harder to cut and paste. Thanks.) > Thanks for your thoughts, You're welcome. > Peter > > -- > Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ > Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 > PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75 > *** Vote against SPAM! ********* http://www.politik-digital.de/spam/ *** Tom Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu http://www.lecb.ncifcrf.gov/~toms/

1 0

Re: gpc-19990813+gcc-2.95.1/alphaev56-dec-osf4.0d => failure
by Alexandre Oliva 05 Sep '99

05 Sep '99

On Aug 31, 1999, Nick Burrett <nick(a)dsvr.net> wrote: >> That's not covered in the original code. Since I've never heard of >> fwrite returning less than -1, I think it is as correct as the >> original code. > I'm suggesting that perhaps you stumbled across a proper bug. According > to the man pages fwrite returns 0 on error and >0 on success. Indeed. So you (we, if you will :-) don't even need ssize_t, size_t and `== 0' will do. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva(a){dcc.unicamp.br,guarana.{org,com}} aoliva(a){acm.org,computer.org} oliva(a){gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them

1 0

GPC-19990813 AND DJGPP
by Andris Pavenis 05 Sep '99

05 Sep '99

Hi! Browsed source archive of GPC 19990813 alpha version. There is one problem with building binaries for DJGPP to be used with GCC-2.95.X: gpc-cccp.c doesn't still support 2 directory separators (DIR_SEPARATOR, DIR_SEPARATOR_2) and corresponding static function is_dir_separator() like in cccp.c in GCC-2.95. As result I'll not build GCC-2.95.1 together with GPC yet as I did it for egcs-1.1.2 in March (when releasing DJGPP port of egcs-1.1.2) Andris PS. Please answer me also directly as I'm not subscribed to GPC mailing list

2 1

Re: CStrings getting corrupted on return from Modules.
by Russ Whitaker 05 Sep '99

05 Sep '99

Hi Kevin Your program is doing exactly what you told it to do You defined a CString which begins byte1 = H, byte 2 = e, etc., disabled error detection with {$X+} and then called it a string: first 4 bytes is capacity, next 4 bytes current length, then the string bytes As far as I know the only time you'll need {$X+} is for a wrapper around function setlength() ( remember to also use {$X-} ) So take out the {$X+} and use functions CString2String and String2CString where you need them. Also noticed the function twine in the interface doesn't match function twine in the implementation. It didn't trigger an error message but I don't know if that's a bug or a extended pascal "extension". In the rewrite which follows couldn't return a CString so changed it to a string. Think this is a language restriction. ( However it could be me ) Type string25 appears twice becaue the implementation section din't see it in the interface section. I think that's a bug. Hope this helps Russ <russwhit(a)mind.net> {---------------------------------------------------------} Module FOO interface; Export FOO = (twine); type String25 = String(25); function twine( foobar: CString ): String25; end. {interface} Module FOO implementation; type String25 = String(25); function twine( foobar: CString ): String25; var local : string25 value 'oops'; begin writeln('In Module: ', CString2String( foobar)); writestr(local, CString2String( foobar), chr(0)); writeln('In Module(2): ', local); twine := local; end; {twine} end. {-----------------------------------------------------} program KFoss( input, output ); import foo; var foobaz : CString; begin foobaz := "Hello there."; writeln('Main Loop: ', CString2String( foobaz)); writeln('After Module: ', twine( foobaz )); end. ---------- > From: Kevin A. Foss <kfoss(a)mint.net> > To: gpc(a)hut.fi > Subject: CStrings getting corrupted on return from Modules. > Date: Sunday, August 29, 1999 9:36 AM > > Hi, > I'm having a problem where strings seem to get corrupted when > they are returned as a CString from a module. > > It is certainly possible that this is a problem on my end as I may be > illegally modifying strings in someway, as I am mixing EP string() > type variables and CStrings, as well as using {$x+} features. Is > there a good guide on how to use/convert the different string > types? I know this code used to work with older versions of gpc -- > trying to move my Pascal code from OS/2 to Linux (more on that in next > message) caused me to find this. > > Anyways here is a sample run of the code included below: > > Main Loop: Hello there. > In Module: Hello there. > In Module(2): Hello there. > After Module: x)@xY@ere. > > I replaced the high ASCII with an x to avoid mailer mangling. > > I'm using the latest version of gpc (compiled for gcc-2.95) available > as a Debian package. It claims to be 19990610, but someone said that > the latest snapshot misreports? -- so I think it is the latest version. > If I'm wrong, sorry. > > The code follows below: > foo.pas: > > Module FOO Interface; > > Export > FOO = (twine); > > function twine(foobar : CString): CString; > > end. { Interface } > > Module FOO Implementation; > > type > String25 = String(25); > function twine; > {$x+} > var > local : String25; > > begin > writeln('In Module: ', foobar); > writestr(local, foobar, chr(0)); > writeln('In Module(2): ', local); > twine := local; > end; { twine } > > end. { FOO } > > test.pas: > program test(input, output); > > import foo; > > var > foobaz : Cstring; > > begin > {$x+} > foobaz := "Hello there."; > writeln('Main Loop: ', foobaz); > writeln('After Module: ', twine(foobaz)); > end. > > Thanks, > -Kevin > -- > Kevin A. Foss ---- kfoss(a)mint.net >

3 3

gpc-19990813+gcc-2.95.1/alphaev56-dec-osf4.0d => failure
by Alexandre Oliva 05 Sep '99

05 Sep '99

I've been trying to build gcc 2.95.1 with gpc 19990813 on a couple of platforms. I had to apply the attached patch in order to get them to build xgpc and gpc1 in stage2, but this was useless on at least one platform (alphaev56-dec-osf4.0d), in which that gpc1 would print: ../../xgpc -B/n/gnu/gcc-2.95.1-gpc-19990813-libg++-2.8.1.3-libgcj-2.95.1/alphaev56-dec-osf4.0d/bin/ -B../../ -c -I. -Wall -Wpointer-arith -Wmissing-prototypes -Wmissing-declarations -O4 -DBSD_RTS=0 `if [ x@with_shared@ = xyes ] ; then echo -fPIC; fi` --unit-path=/usr/local/tmp/install-gnu-gcc-2.95.1-gpc-19990813-libg++-2.8.1.3-libgcj-2.95.1-bela-8709/libg++-2.8.1.3/gcc/p/rts --automake heap.pas error.pas: In function `Geterrormessage': error.pas:362: Internal compiler error in `copy_to_mode_reg', at explow.c:669 Please submit a full bug report. See <URL:http://www.gnu.org/software/gcc/faq.html#bugreport> for instructions. gpc1: ../../xgpc exited with status 1 heap.pas:30: module/unit `error' could not be compiled It is worth noting that the directory pointed to by the first -B argument does not exist yet, so it is definitely using the just-built gpc1. If you need further informations, I'd be glad to provide, but make sure you Cc:me, since I'm not subscribed in this list. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva(a){dcc.unicamp.br,guarana.{org,com}} aoliva(a){acm.org,computer.org} oliva(a){gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them

3 3

Re: gpc-19990813+gcc-2.95.1/alphaev56-dec-osf4.0d => failure
by Alexandre Oliva 05 Sep '99

05 Sep '99

On Aug 31, 1999, Nick Burrett <nick(a)dsvr.net> wrote: > Alexandre Oliva <oliva(a)dcc.unicamp.br> writes: >> +++ gcc/p/rts/file.c Sun Aug 29 15:56:11 1999 >> @@ -887,7 +887,7 @@ >> _p_f_write (File, Buf, Size) [snip] >> - ssize_t result = >> + size_t result = [snip] >> - if (result < 0) >> + if (result == (size_t)-1) > You cannot do this. size_t may be unsigned. That's the reason why I'm explicitly casting -1 to that type. > Also fwrite returned zero on error That's not covered in the original code. Since I've never heard of fwrite returning less than -1, I think it is as correct as the original code. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva(a){dcc.unicamp.br,guarana.{org,com}} aoliva(a){acm.org,computer.org} oliva(a){gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them

1 0

Re: gpc-19990813+gcc-2.95.1/alphaev56-dec-osf4.0d => failure
by Alexandre Oliva 05 Sep '99

05 Sep '99

On Aug 30, 1999, Peter Gerwinski <peter(a)gerwinski.de> wrote: > Yes. gpc-19990813 does not build correctly with gcc-2.95.1. > This is work in progress. Well, I only had trouble on alpha platforms: both DU4.0 and GNU/Linux crash the same way. It built correctly (but I haven't tested it at all) on Solaris 7/sparc and /x86 and GNU/Linux/sparc and /x86. It also presented some problems on SunOS 4.1.3, and installed man-pages in the wrong directory. These problems are fixed with the following additional patch: -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva(a){dcc.unicamp.br,guarana.{org,com}} aoliva(a){acm.org,computer.org} oliva(a){gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them

1 0

Re: gpc-19990813+gcc-2.95.1/alphaev56-dec-osf4.0d => failure
by Nick Burrett 05 Sep '99

05 Sep '99

Alexandre Oliva <oliva(a)dcc.unicamp.br> writes: > --=-=-= > > On Aug 30, 1999, Peter Gerwinski <peter(a)gerwinski.de> wrote: > > > Yes. gpc-19990813 does not build correctly with gcc-2.95.1. > > This is work in progress. > > > --- gcc/p/rts/file.c~ Mon Aug 2 05:44:13 1999 > +++ gcc/p/rts/file.c Sun Aug 29 15:56:11 1999 > @@ -887,7 +887,7 @@ > _p_f_write (File, Buf, Size) > void *File; const char *Buf; size_t Size; > { > - ssize_t result = > + size_t result = > /*@@@@@@@@ fwrite() has a known bug (fh19990305.2), but using write() > together with fread(), fseek() etc. causes bigger problems. > We choose the lesser of two evils by default. */ > @@ -896,7 +896,7 @@ > #else > fwrite (Buf, 1, Size, (FILE *) File); > #endif > - if (result < 0) > + if (result == (size_t)-1) You cannot do this. size_t may be unsigned. Also fwrite returned zero on error or a positive integer (number of elements written) on success. Cheers, Nick.

1 0

bug in gpc, map[b].b
by Tom Schneider 05 Sep '99

05 Sep '99

Hi - We just got the latest version of gpc: GNU Pascal version 19990118, based on gcc-2.8.1, compiled Aug 25 1999 09:07:02. and it is objecting to a line of code in one of my programs: ftp://ftp.ncifcrf.gov/pub/delila/makelogo.p I am compiling with: gpc makelogo.p -o makelogo The message I get is: makelogo.p: In function `Themain': makelogo.p:4093: cannot take address of bitfield `B' Line 4093 is: readln(symvec,map[b].b, map[b].n); b is defined as: b: integer; (* index to a symbol *) map is defined as: position = 0..mapmax; place = packed record b: char; (* the symbol *) n: integer (* the number of symbols *) end; so is it getting confused about the "two" uses of b? I changed b to 'bloop' and made a new variable, but the other b was still around and it still yelled: makelogo.p: In function `Themain': makelogo.p:4094: cannot take address of bitfield `B' I even changed the definition so that: readln(symvec,map[bloop].bsymbol, map[bloop].n); but *STILL* got: makelogo.p: In function `Themain': makelogo.p:4094: cannot take address of bitfield `Bsymbol' since map is used in other places, there seems to be a bug in the use here in the middle of a readln. So I defined c: char; and separated it; readln(symvec,c, map[bloop].n); map[bloop].bsymbol := c; and now it compiles. This program compiles just fine with the Sun compiler and translates into C with p2c and compiles with gcc. Regards, Tom Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu http://www.lecb.ncifcrf.gov/~toms/

2 1

CStrings getting corrupted on return from Modules.
by Kevin A. Foss 05 Sep '99

05 Sep '99

Hi, I'm having a problem where strings seem to get corrupted when they are returned as a CString from a module. It is certainly possible that this is a problem on my end as I may be illegally modifying strings in someway, as I am mixing EP string() type variables and CStrings, as well as using {$x+} features. Is there a good guide on how to use/convert the different string types? I know this code used to work with older versions of gpc -- trying to move my Pascal code from OS/2 to Linux (more on that in next message) caused me to find this. Anyways here is a sample run of the code included below: Main Loop: Hello there. In Module: Hello there. In Module(2): Hello there. After Module: x)@xY@ere. I replaced the high ASCII with an x to avoid mailer mangling. I'm using the latest version of gpc (compiled for gcc-2.95) available as a Debian package. It claims to be 19990610, but someone said that the latest snapshot misreports? -- so I think it is the latest version. If I'm wrong, sorry. The code follows below: foo.pas: Module FOO Interface; Export FOO = (twine); function twine(foobar : CString): CString; end. { Interface } Module FOO Implementation; type String25 = String(25); function twine; {$x+} var local : String25; begin writeln('In Module: ', foobar); writestr(local, foobar, chr(0)); writeln('In Module(2): ', local); twine := local; end; { twine } end. { FOO } test.pas: program test(input, output); import foo; var foobaz : Cstring; begin {$x+} foobaz := "Hello there."; writeln('Main Loop: ', foobaz); writeln('After Module: ', twine(foobaz)); end. Thanks, -Kevin -- Kevin A. Foss ---- kfoss(a)mint.net

1 0

M2 frontend for gcc
by Matthias Klose 05 Sep '99

05 Sep '99

Maybe this could be of some interest to you. The thread starts at http://egcs.cygnus.com/ml/gcc/1999-08/msg00865.html

1 0

gpc-19990813: problems with #include ?
by Ian Thurlbeck 05 Sep '99

05 Sep '99

Dear All I'm having problems with multiple #include "filename" lines with gpc-19990813 in a program that worked with gpc-19990118 (and others). Example program is: --------- solver.p ----------- program SOLVER(input,output); #include "TurboP.def" #include "WinLib.def" #include "PlotLib.def" #include "MxFiler.def" begin writeln("Hello!"); end. ------------------------- % gpc -I./modules solver.p solver.p:5: WinLib.def: No such file or directory solver.p:6: PlotLib.def: No such file or directory solver.p:7: MxFiler.def: No such file or directory % gpc -I./modules -I./modules -I./modules -I./modules solver.p % ./a.out Hello! Actually gpc -v reports 19990610, by the way. Thanks Ian -- Ian Thurlbeck http://www.stams.strath.ac.uk/ Statistics and Modelling Science, University of Strathclyde Livingstone Tower, 26 Richmond Street, Glasgow, UK, G1 1XH Tel: +44 (0)141 548 3667 Fax: +44 (0)141 552 2079

2 2

HP-UX installation trouble
by Dimitrios Bartzos 05 Sep '99

05 Sep '99

Hi, I still can't seem to be able to build gpc for HP-UX 10.20. I tried all three available versions 19990118, 19990409, 19990607 and for each I get the same error: ../../xgpc -B../../ -c -I. -Wall -Wpointer-arith -Wmissing-prototypes -Wmissing-declarations -O2 -g -O2 -DBSD_RTS=0 `if [ x@with_shared@ = xyes ] ; then echo -fPIC; fi` --unit-path=/ece2/eeof/egcs-1.1.2/gcc/p/rts --automake /ece2/eeof/egcs-1.1.2/gcc/p/rts/files.pas /ece2/eeof/egcs-1.1.2/gcc/p/rts/files.pas: In function `Ioselect': /ece2/eeof/egcs-1.1.2/gcc/p/rts/files.pas:162: internal error--unrecognizable insn: (insn 288 285 290 (set (zero_extract:SI (reg:SI 223) (const_int 32) (const_int 0)) (reg:SI 222)) -1 (insn_list 285 (insn_list 287 (nil))) (expr_list:REG_DEAD (reg:SI 222) (nil))) ../../../egcs-1.1.2/gcc/p/../toplev.c:1385: Internal compiler error in function fatal_insn make[3]: *** [files.o] Error 1 make[3]: Leaving directory `/ece2/eeof/gcc/gcc/p/rts' make[2]: *** [pascal.rts] Error 2 make[2]: Leaving directory `/ece2/eeof/gcc/gcc' make[1]: *** [bootstrap] Error 2 make[1]: Leaving directory `/ece2/eeof/gcc/gcc' make: *** [bootstrap] Error 2 Anyone else had this problem? Is it a known limitation? (I'm not saying bug...) Has anyone successfully built gpc on HP-UX? Please cc me, Thanks, Dimitrios.

2 4

Problems building new snapshot under EGCS
by david＠tcs01.demon.co.uk 05 Sep '99

05 Sep '99

In message <38919B7D.19990813155556.FOO-5D74.frank(a)g-n-u.de> Frank Heckenbach writes: > Hello, folks, > > a new GPC snapshot is available: > > ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/gpc-19990813.tar.gz > Help! I'm having lots of problems building the new snapshot under RedHat Linux 6.0 (kernel 2.2.5-15 on i586) using EGCS (source RPM egcs-1.1.2-12, appears to be version 2.91.66). I unpacked the egcs source into a directory tree, moved the snapshot's p directory into gcc, applied the gcc-egcs-2.91.66 patch (after a bit of editing of directory names within the patch file), did a ./configure, and am now trying make LANGUAGES=pascal. Is this the correct sequence of actions? The INSTALL file in the snapshot doesn't seem to cover building GPC under EGCS. I guess my first question is: should I be using EGCS or would I be better off with a plain gcc source, and if so what version? Various things I've come across so far: The p/gpc_release file contains 19990610, I think it should contain 19990813. I think there is something strange about the way the contents of the gpc_release file is accessed - at the point where I see the make doing a cd p, I then see an error message from cat that it cannot find the gpc_release file. It looks as if there is one too few "../"s on the front of the path to the file. In p/gpc-common.c at line 2893, TREU_OVERFLOW should be TREE_OVERFLOW, I think. (Not a GPC problem): In my gcc/flow.c at line 1493, the code says REG_N_SEDS, it should be REG_N_SETS, I think. Finally, I come to a halt with make[1]: Entering directory `/home/david/egcs/objs/gcc' gcc -DIN_GCC -g -O2 -DHAVE_CONFIG_H -o cc1 c-parse.o c-lang.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o collect2: ld terminated with signal 11 [Segmentation fault], core dumped make[1]: *** [cc1] Error 1 make: *** [all-gcc] Error 2 make[1]: Leaving directory `/home/david/egcs/objs/gcc' I think the GCC line has been truncated in copying it between systems. Has anyone succeeded in compiling this snapshot in a similar environment? -- David James mailto:david@tcs01.demon.co.uk Special Stage Rally results archive <URL:http://www.tcs01.demon.co.uk/>

1 0

2 dim arrays
by Russ Whitaker 05 Sep '99

05 Sep '99

Hi can't initialize 2 dimensional array: var ch : array[ 1..2, 1..2 ] of char = ( 'e', 'a', 's', 'y'); should it work? Thanks, Russ <russwhit(a)mind.net>

2 1

Error building the latest gpc snapshot
by Alexander Sokolov 05 Sep '99

05 Sep '99

Just tried to build the latest gpc snapshot (19990813) with gcc-2.95.1 sources and got the following error: gcc -DGPC -DIN_GCC -g0 -O2 -fomit-frame-pointer -march=pentiumpro -malign-loops=2 -malign-jumps=2 -malign-functions=2 -mpreferred-stack-boundary=2 -DHAVE_CONFIG_H -I. -I../../gcc-2.95.1/gcc -I../../gcc-2.95.1/gcc/config -I../../gcc-2.95.1/gcc/../include \ -DGPC_MAJOR="\"2\"" \ -DGPC_MINOR="\"0\"" \ -DGPC_RELEASE="\"`cat ../../gcc-2.95.1/gcc/p/gpc_release`\"" \ -DSTANDARD_STARTFILE_PREFIX=\"/usr/lib/\" -DSTANDARD_EXEC_PREFIX=\"/usr/lib/gcc-lib/\" -DDEFAULT_TARGET_VERSION=\"2.95.1\" -DDEFAULT_TARGET_MACHINE=\"i686-pc-linux-gnu\" -DTOOLDIR_BASE_PREFIX=\"/usr/\" \ -c `echo ../../gcc-2.95.1/gcc/p/gpc.c | sed 's,^\./,,'` -o p/gpc.o make[1]: *** No rule to make target `choose-temp.o', needed by `xgpc'. Stop. make[1]: Leaving directory `/usr/src/gcc/build/gcc' make: *** [all-gcc] Error 2 # -- Alexander Sokolov Network Administrator RosNet, Komsomolsk-na-Amure Tel./Fax: +7-095-737-6260

2 1

make error
by Dmitry S. Luhtionov 05 Sep '99

05 Sep '99

Hello gpc, This message has been displayed when i try build gpc-19990813.tar.gz OS: FreeBSD 3.2 # make `echo gcc | sed 's/gcc/gpc/'` -c -I. -Wall -Wpointer-arith -Wmissing-prototypes -Wmissing-declarations -O2 -DBSD_RTS=0 `if [ x = xyes ] ; then echo -fPIC; fi` --unit-path= --automake files.pas files.pas: In function `Sleepmicroseconds': files.pas:257: argument does not match conformant array formal parameter files.pas:257: incompatible type for argument 1 of `Ioselect' files.pas:257: argument does not match conformant array formal parameter files.pas:257: too few arguments to function `Ioselect' files.pas: In function `Stringtfdd_rewrite': files.pas:310: assignment from incompatible pointer type *** Error code 1 Stop. Best regards, Dmitry mailto:mitya@mg.dp.ua

1 0

DIV bug found in GPC 19990510
by GPC on Ken Linder's Linux Box 05 Sep '99

05 Sep '99

Howdy all... Found an oddity with the DIV operation. The following line correctly produces a compile error (as it should): aninteger := 12.1 div 5.5; However, the following compiles & runs, behaving like a REAL division operation: writeln( 12.1 div 5.5 ); Very strange indeed! Good bug hunting! Ken Linder http:\\kc7rad.lvcm.com\

1 0

I have some problems with GPC.
by Alejandro Villarroel 05 Sep '99

05 Sep '99

Hi everyone. I have the following problems. 1. In pascal program like this ... uses crt; begin ClrScr; .... And it says that there is no reference to crt_clrscr. The same happens when I use C program with #include <conio.h> .... main() ..... clrscr(); .... Where's the problem? 2. When I use a project with a single file *.pas, I have to add these file to the project, do I have to add the units? I metion this because when I add only the *.pas It says that It cannot import the unit. When I close the project and I build all, it works. Thanks in advance.

1 0

Re: I have some problems with GPC.
by Frank Heckenbach 05 Sep '99

05 Sep '99

Alejandro Villarroel wrote: > Hi everyone. I have the following problems. > 1. In pascal program like this > ... > uses crt; > begin > ClrScr; > .... > And it says that there is no reference to crt_clrscr. The same To help, we need a little more details -- which GPC version, which environment, etc. Concluding from your example below, let's assume DJGPP. Automake is broken under DJGPP (see the To-Do list), so try `--autobuild' instead, or removing all *.o and/or *.gpi files before compiling. I hope this situation will get better soon. > happens when I use C program with > #include <conio.h> > .... > main() > ..... > clrscr(); > .... > Where's the problem? You mean you get an undefined reference to crt_clrscr in a C program that doesn't use CRT at all? Hard to believe... If that's really what you mean, please post a *complete* sample code. > 2. When I use a project with a single file *.pas, I have to add > these file to the project, do I have to add the units? I metion this > because when I add only the *.pas It says that It cannot import the > unit. When I close the project and I build all, it works. Is that about RHIDE? In general, you should only have to specify the main program file name if you use --automake. But as I said, under DJGPP try --autobuild or removing compiled units... 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

re; new snapshot
by Russ Whitaker 05 Sep '99

05 Sep '99

Hi Frank ran into two little bugs: 1: Since compiling previous snapshot changed motherboards here so i486 became i586. Ran into the "ar" bug again. While a soft link fixes the problem, changing line 74 of Makefile.in does it nicely: From: AR = ar To: AR = /usr/bin/ar 2. The date in gpc_release doesn't match the snapshot date Thanks, Russ <russwhit(a)mind.net>

1 0

FTP on agnes (was: New GPC snapshot)
by david＠tcs01.demon.co.uk 05 Sep '99

05 Sep '99

In message <38919B7D.19990813155556.FOO-5D74.frank(a)g-n-u.de> Frank Heckenbach writes: > Hello, folks, > > a new GPC snapshot is available: > > ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/gpc-19990813.tar.gz Is there a problem with ftp on agnes or is it just really busy? Whenever I try to collect this new snapshot agnes already has 50 (the maximum number) of anonymous users connected. -- David James mailto:david@tcs01.demon.co.uk Special Stage Rally results archive <URL:http://www.tcs01.demon.co.uk/>

1 0

Re: FTP on agnes (was: New GPC snapshot)
by Frank Heckenbach 05 Sep '99

05 Sep '99

David James wrote: > In message <38919B7D.19990813155556.FOO-5D74.frank(a)g-n-u.de> Frank Heckenbach writes: > > Hello, folks, > > > > a new GPC snapshot is available: > > > > ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/gpc-19990813.tar.gz > > Is there a problem with ftp on agnes or is it just really busy? Whenever > I try to collect this new snapshot agnes already has 50 (the maximum > number) of anonymous users connected. Seems like there was in fact a problem on Agnes. It should have been fixed now, so happy downloading! 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

Re: FTP on agnes (was: New GPC snapshot)
by david＠tcs01.demon.co.uk 05 Sep '99

05 Sep '99

In message <199908182252.AAA14439(a)aruru.mi.uni-erlangen.de> Frank Heckenbach writes: > David James wrote: > > > > Is there a problem with ftp on agnes or is it just really busy? Whenever > > I try to collect this new snapshot agnes already has 50 (the maximum > > number) of anonymous users connected. > > Seems like there was in fact a problem on Agnes. It should have been fixed now, so happy > downloading! Thank you, when I tried a few minutes ago it was reporting 2 anonymous users and I've now succeeded in downloading the latest snapshot. -- David James mailto:david@tcs01.demon.co.uk Special Stage Rally results archive <URL:http://www.tcs01.demon.co.uk/>

1 0

Random Seed
by Ian Thurlbeck 05 Sep '99

05 Sep '99

Dear All Could anyone tell me how to seed the random number generator ? I can do: Randomize; writeln(Random); but I want something like: RandSeed(67); // SeedRandom ?? writeln(Random); Many thanks Ian -- Ian Thurlbeck http://www.stams.strath.ac.uk/ Statistics and Modelling Science, University of Strathclyde Livingstone Tower, 26 Richmond Street, Glasgow, UK, G1 1XH Tel: +44 (0)141 548 3667 Fax: +44 (0)141 552 2079

1 0

Re: Random Seed
by Frank Heckenbach 05 Sep '99

05 Sep '99

Ian Thurlbeck wrote: > Could anyone tell me how to seed the random number generator ? > > I can do: > > Randomize; > writeln(Random); > > but I want something like: > > RandSeed(67); // SeedRandom ?? > writeln(Random); This question comes exactly at the right time. :-) The latest snapshot, released last Friday (19990813) contains a SeddRandom procedure in the GPC unit. With earlier versions, you're out of luck... 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

Unsubscribe
by kevin williams 05 Sep '99

05 Sep '99

Thanks for all the help. Please unsubscribe from this list

1 0

About the paths on rhide.
by Alejandro Villarroel 13 Aug '99

13 Aug '99

I have djgpp and gpc installed in my PC. I run c:\djgpp\rhide, and what paths I have to type and where? Thanks very much for your help,.

1 0

About the paths... Second part...
by Alejandro Villarroel 13 Aug '99

13 Aug '99

I work with the .pas in c:\progs, and I have the following paths by the way: Include: c:\djgpp\include (Can I put here c:\progs ?) Libraries: c:\djgpp\lib Object c:\progs\obj Source c:\progs Standard Headers c:\djgpp\include (I have my doubts on this one, what is the purpose of this path?) Main target c:\progs\whatever.exe Primary file ? what is the purpose of this one? When I compile the files, rhide put the *.o files in the c:\djgpp\bin, so what's the matter with the Object path? Thanks for your patience, and help. Alejandro Villarroel

2 1

New GPC snapshot
by Frank Heckenbach 13 Aug '99

13 Aug '99

Hello, folks, a new GPC snapshot is available: ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/gpc-19990813.tar.gz Source only. Nothing guaranteed. A major new feature is the support for panels (overlapping windows) in the CRT unit. For a complete list of new features and fixed bugs, please see the GPC To-Do list at: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html Have fun, 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

GPC, Restarting.
by Alejandro Villarroel 13 Aug '99

13 Aug '99

Some weeks ago, I installed GPC-DJGPP for DOS, I began to read the text files, but I didn't find where to install the compressed files, so I create the dir gpc\bin \lib \include \unit, obviuosly I had many problems. With the help of Peter, I try to force to work,. I decided to restart, I take all the compressed files, and due the have the "same" directory structure (bin, lib, doc, ...) I decide to mix up all the compressed files. But when I used rhide to compile a file and It ask me for some files, these files are: 1 .lib\gcc-lib\djgpp\2.81 gpc-cpp.exe and gpc1.exe 2. (uses gpc,gmp;) lib\gcc-lib\2.81 gpc.pas and gmp.pas 3. lib\ crt0.o When I copied these files into the bin directory, rhide build the exe file. By the way the compressed files that I mixed up are: RX15B <DIR> 02/07/99 2:03p rx15b README 533 03/05/99 12:01a README RHIDE14B <DIR> 02/07/99 2:03p rhide14b GRX23RME 1ST 3,920 02/05/99 8:02p grx23rme.1st MAK377B <DIR> 02/07/99 2:03p mak377b GRX23FNT <DIR> 02/07/99 2:03p grx23fnt GMP202B <DIR> 02/07/99 2:02p gmp202b GDB416B <DIR> 02/07/99 2:02p gdb416b GCC281B <DIR> 02/07/99 2:01p gcc281b FAQ211B <DIR> 02/07/99 2:01p faq211b DJDEV202 <DIR> 02/07/99 2:01p djdev202 CURSE23B <DIR> 02/07/99 2:00p curse23b BNU281B <DIR> 02/07/99 2:00p bnu281b FILE TXT 0 11/08/99 11:02a file.txt GRX23 <DIR> 02/07/99 2:02p grx23 GPC20BB <DIR> 02/07/99 2:02p gpc20bb DJ202DIF <DIR> 02/07/99 2:01p dj202dif BCCGRX20 <DIR> 02/07/99 2:00p bccgrx20 What I have to do?

2 3

Operator questions
by GPC on Ken Linder's Linux Box 12 Aug '99

12 Aug '99

I came across some operators in the docs that are not specified in either Extended or Standard pascal (if they are, what section?). They are: *< /< *> /> +< -< +> -> What the heck do these do??? Also, am I right with the following: & Resolve a pointer reference @ Return a pointer to a variable, function, etc... TNX Ken Linder http://kc7rad.lvcm.com/

2 1

Compiling
by kevin williams 12 Aug '99

12 Aug '99

Help! every time it try to comile I get this an error message. I am trying to compile one of the demo files. c:\mingw32\doc\gpc\demos>gpc --automake pi.pa -o pi gpc.exe: intallation problem, cannot exec 'as': No such file or directory I am running windows 98. when I do a a trace I get this. INGW32__ -DWINNT -D_X86_=1 -D__STDC__=1 -D__stdcall=__attribute__((__stdcall__ -D__cdecl=__attribute__((__cdecl__)) -D__OS_DOS__=1 -D__i386__ -D_WIN32 -D__W 32__ -D__WIN32__ -D__MINGW32__ -D__WINNT__ -D_X86_=1 -D__STDC__=1 -D__stdcall= attribute__((__stdcall__)) -D__cdecl=__attribute__((__cdecl__)) -D__OS_DOS__=1 D__i386 -D__WIN32 -D__WINNT -Asystem(winnt) -Acpu(i386) -Amachine(i386) -D__BI _LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 -re p -Di386 -Asystem(unix) -Acpu(i386) -Amachine(i386) -D__i386__ -Asystem(unix) cpu(i386) -Amachine(i386) \mingw32\lib\gcc-lib\i386-mingw32\2.8.1\units\gpc.pa -o c:\windows\TEMP\cc587659.exe GNU CPP version 2.8.1 (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: /usr/local/include /mingw32/i386-mingw32/include /mingw32/lib/gcc-lib/i386-mingw32/2.8.1/include /usr/mingw32/include End of search list. GPC AutoMake: done GPC AutoMake: C:\MINGW32\BIN\GPC.EXE --automake -v --amtmpfile=c:\windows\TEMP c582799.gpc -M \mingw32\lib\gcc-lib\i386-mingw32\2.8.1\units\gmp.pas -o c:\win ws\TEMP\cc587659 Reading specs from \mingw32\lib\gcc-lib\i386-mingw32\2.8.1\specs gpc version 19990118, based on gcc-2.8.1 \mingw32\lib\gcc-lib\i386-mingw32\2.8.1\gpc-cpp.exe -lang-pascal -v -nochares pe -D__GNU_PASCAL__ -M -undef -D__GNUC__=2 -D__GNUC_MINOR__=8 -D__GPC__=2 -D__ C_MINOR__=0 -D__GPC_RELEASE__=19990118 -Di386 -D_WIN32 -DWIN32 -D__WIN32__ -D_ INGW32__ -DWINNT -D_X86_=1 -D__STDC__=1 -D__stdcall=__attribute__((__stdcall__ -D__cdecl=__attribute__((__cdecl__)) -D__OS_DOS__=1 -D__i386__ -D_WIN32 -D__W 32__ -D__WIN32__ -D__MINGW32__ -D__WINNT__ -D_X86_=1 -D__STDC__=1 -D__stdcall= attribute__((__stdcall__)) -D__cdecl=__attribute__((__cdecl__)) -D__OS_DOS__=1 D__i386 -D__WIN32 -D__WINNT -Asystem(winnt) -Acpu(i386) -Amachine(i386) -D__BI _LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 -re p -Di386 -Asystem(unix) -Acpu(i386) -Amachine(i386) -D__i386__ -Asystem(unix) cpu(i386) -Amachine(i386) \mingw32\lib\gcc-lib\i386-mingw32\2.8.1\units\gmp.pa -o c:\windows\TEMP\cc587659.exe GNU CPP version 2.8.1 (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: /usr/local/include /mingw32/i386-mingw32/include /mingw32/lib/gcc-lib/i386-mingw32/2.8.1/include /usr/mingw32/include End of search list. GPC AutoMake: done as -o c:\windows\TEMP\cc5827991.o c:\windows\TEMP\cc582799.s GPC.EXE: installation problem, cannot exec `as': No such file or directory Whats all this about 'as' file or directory?? Kevin

3 2

Is -pipe really broken with gpc or it's just me ?
by Khimenko Victor 05 Aug '99

05 Aug '99

I can not recompile with -pipe even most supplied modules ! Is it gpc [mis]feature or I'm messed somewhere ? -- cut -- $ gpc -pipe crt.pas crt.pas:238: pointer domain type `Harattr' undefined crt.pas:238: pointer domain type `Harattrs' undefined crt.pas:382: pointer domain type `Te' undefined crt.pas: In function `Makewin': crt.pas:713: parse error before `End' crt.pas:713: missing `)' crt.pas: In function `Restorewin': crt.pas:733: parse error before `Freemem' crt.pas:733: missing `)' crt.pas:733: parse error before `Freemem' crt.pas: In function `Writebuf': crt.pas:755: parse error before `)' crt.pas:755: extra comma crt.pas:755: too few arguments to function `Crt_write' crt.pas: In function `Readbuf': crt.pas:761: parse error before `)' crt.pas:761: extra comma crt.pas:761: too few arguments to function `Crt_read' $ gpc -v Reading specs from /usr/lib/gcc-lib/i586-ksi-linux/2.95/specs gpc version 19990510, based on 2.95 19990728 (release) -- cut -- Hmm. Version 19990510 even if archive was numbered as 19990607 ... Weird...

2 1

Re: Pascal
by Kevin Williams 05 Aug '99

05 Aug '99

Ok I downloaded the file, unpacked into a directory wingw32. However, you said after that everything would be fine, and I dont think it is. I am still confused as to how to get this program to actually run/compile code that I write in a text editor. Whats a "Comand line compiler?" Markus Gerwinski wrote: > > Hello, Kevin! > > > Would you have any advice for someone like myself to make the > > downloading and installation process I little more manageable. > > First of all choose the distribution you want to download. The current > Windows version of gpc is in > > ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/binary/gpc-19990118-egcs-1+.1.1.i386-pc-mingw32.zip > > Create a directory "mingw32" on C: (or on whatever drive you want to install > gpc), and unpack the archive file into this directory. After that, > everything should be fine. > > > Up to now, there is not a gpc IDE for Windows, so you'll have to work with a > text editor and a command line compiler. But watch out for a new > all-platform IDE named PENG, which soon shall be released. > > If there are still problems, I recommend to post them to the GPC mailing > list (gpc(a)gnu.de). > > Hope this helps > > Markus

2 1

Create DLL
by Danuta Burnicka 04 Aug '99

04 Aug '99

Hello, I have to make 16-bit DLL library under OS/2. The head of the functions in this library must be Pascal-like. Could you help me how to do it. Danuta Burnicka ------------------------------------------ Nicholas Copernicus University Library D.Burnicka(a)bu.uni.torun.pl ul. Gagarina 13, 87-100 Torun, Poland tel: +48 (56) 6114475 http://www.bu.uni.torun.pl ------------------------------------------

3 2

Re: Installation trouble
by Frank Heckenbach 03 Aug '99

03 Aug '99

Dimitrios Bartzos wrote: > I managed to get the mbchar.* files from a newer gcc version and copied > them into the gcc source directory and it looks like we got past that point. > > Well, only to get this: > > ../../xgpc -B../../ -c -Wall -Wpointer-arith -Wmissing-prototypes > -Wmissing-declarations -g -O2 `if [ x@with_shared@ == xyes ] ; then echo -fPIC; > fi` --unit-path=/ece2/eeof/egcs-1.1.2/gcc/p/rts --automake > /ece2/eeof/egcs-1.1.2/gcc/p/rts/files.pas > /bin/sh: ==: A test command parameter is not valid. > /ece2/eeof/egcs-1.1.2/gcc/p/rts/files.pas: In function `Ioselect': > /ece2/eeof/egcs-1.1.2/gcc/p/rts/files.pas:162: internal error--unrecognizable > insn: > (insn 286 283 288 (set (zero_extract:SI (reg:SI 223) > (const_int 32) > (const_int 0)) > (reg:SI 222)) -1 (insn_list 283 (insn_list 285 (nil))) > (expr_list:REG_DEAD (reg:SI 222) > (nil))) > ../../../egcs-1.1.2/gcc/p/../toplev.c:1385: Internal compiler error in function > fatal_insn > make[2]: *** [files.o] Error 1 > make[2]: Leaving directory `/ece2/eeof/gcc/gcc/p/rts' > make[1]: *** [pascal.rts] Error 2 > make[1]: Leaving directory `/ece2/eeof/gcc/gcc' > make: *** [all-gcc] Error 2 > > In fact I get the warning: > > /bin/sh: ==: A test command parameter is not valid. > > for every pascal source file compiled. > > Now, what? :) Replace `==' by `=' in the makefiles, or get a recent version of bash. ;-) This will be fixed in the next release of 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

Installation trouble
by Dimitrios Bartzos 03 Aug '99

03 Aug '99

Hello, I was trying to install GNU Pascal on a 9000/735 running HP-UX 10.20. I got egcs-1.1.2 and gpc-19990409. The trouble starts early when I try to apply the patch (with patch -p1 < p/diffs/gcc-egcs-1.1.2.diff, I get: Hmm... Looks like a new-style context diff to me... The text leading up to this was: -------------------------- |Changes for GCC version egcs-2.93.12 for GNU Pascal 2.1 | |Before applying these diffs, go to the directory gcc-egcs-2.93.12 |and use the command | | patch -p1 | |feeding it the following diffs as input. | |*** gcc-egcs-2.93.12/Makefile.in.orig Wed Mar 17 15:22:18 1999 |--- gcc-egcs-2.93.12/Makefile.in Wed Mar 17 15:24:24 1999 -------------------------- Patching file Makefile.in using Plan A... Hunk #1 failed at 2731. Hunk #2 succeeded at 2637 with fuzz 2 (offset -136 lines). 1 out of 2 hunks failed--saving rejects to Makefile.in.rej Hmm... The next patch looks like a new-style context diff to me... The text leading up to this was: -------------------------- |*** gcc-egcs-2.93.12/convert.c.orig Wed Mar 17 15:22:18 1999 |--- gcc-egcs-2.93.12/convert.c Wed Mar 17 15:24:24 1999 -------------------------- Patching file convert.c using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] y Hunk #1 succeeded at 289 (offset -8 lines). Hunk #2 succeeded at 327 (offset -8 lines). Hmm... The next patch looks like a new-style context diff to me... The text leading up to this was: -------------------------- |*** gcc-egcs-2.93.12/dbxout.c.orig Wed Mar 17 15:22:18 1999 |--- gcc-egcs-2.93.12/dbxout.c Wed Mar 17 15:24:24 1999 -------------------------- Patching file dbxout.c using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] y Hunk #1 succeeded at 986 (offset -2 lines). Hmm... The next patch looks like a new-style context diff to me... The text leading up to this was: -------------------------- |*** gcc-egcs-2.93.12/expr.c.orig Wed Mar 17 15:22:19 1999 |--- gcc-egcs-2.93.12/expr.c Wed Mar 17 15:24:24 1999 -------------------------- Patching file expr.c using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] y Hunk #1 succeeded at 4172 (offset -170 lines). Hunk #2 succeeded at 4839 (offset -21 lines). Hunk #3 succeeded at 4703 (offset -170 lines). Hunk #4 succeeded at 6023 (offset -74 lines). Hunk #5 failed at 6033. Hunk #6 succeeded at 6452 (offset -150 lines). Hunk #7 succeeded at 6635 (offset -72 lines). Hunk #8 succeeded at 7011 (offset -150 lines). Hunk #9 succeeded at 7124 (offset -72 lines). Hunk #10 succeeded at 7171 (offset -150 lines). Hunk #11 succeeded at 7269 (offset -72 lines). Hunk #12 succeeded at 7682 (offset -149 lines). Hunk #13 succeeded at 8038 (offset -120 lines). Hunk #14 succeeded at 11026 (offset -171 lines). 1 out of 14 hunks failed--saving rejects to expr.c.rej Hmm... The next patch looks like a new-style context diff to me... The text leading up to this was: -------------------------- |*** gcc-egcs-2.93.12/fold-const.c.orig Wed Mar 17 15:22:19 1999 |--- gcc-egcs-2.93.12/fold-const.c Wed Mar 17 15:24:24 1999 -------------------------- Patching file fold-const.c using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] y Hunk #1 succeeded at 1230 (offset -231 lines). Hunk #2 succeeded at 4892 (offset -33 lines). Hunk #3 succeeded at 4755 (offset -231 lines). Hunk #4 succeeded at 4960 (offset -33 lines). Hunk #5 succeeded at 4792 (offset -231 lines). Hunk #6 succeeded at 5443 (offset -33 lines). Hunk #7 failed at 6278. 1 out of 7 hunks failed--saving rejects to fold-const.c.rej Hmm... The next patch looks like a new-style context diff to me... The text leading up to this was: -------------------------- |*** gcc-egcs-2.93.12/function.c.orig Wed Mar 17 15:22:20 1999 |--- gcc-egcs-2.93.12/function.c Wed Mar 17 15:24:24 1999 -------------------------- Patching file function.c using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] y Hunk #1 succeeded at 461 (offset -40 lines). Hunk #2 succeeded at 473 (offset -40 lines). Hmm... The next patch looks like a new-style context diff to me... The text leading up to this was: -------------------------- |*** gcc-egcs-2.93.12/optabs.c.orig Wed Mar 17 15:22:20 1999 |--- gcc-egcs-2.93.12/optabs.c Wed Mar 17 15:24:24 1999 -------------------------- Patching file optabs.c using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] y Hunk #1 succeeded at 1383 (offset -8 lines). Hmm... The next patch looks like a new-style context diff to me... The text leading up to this was: -------------------------- |*** gcc-egcs-2.93.12/stor-layout.c.orig Wed Mar 17 15:22:20 1999 |--- gcc-egcs-2.93.12/stor-layout.c Wed Mar 17 15:24:24 1999 -------------------------- Patching file stor-layout.c using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] y Hunk #1 succeeded at 67 (offset 2 lines). Hunk #2 succeeded at 104 (offset 2 lines). Hunk #3 succeeded at 121 (offset 2 lines). Hunk #4 succeeded at 986 (offset -48 lines). Hunk #5 succeeded at 1061 (offset 2 lines). Hunk #6 failed at 1313. 1 out of 6 hunks failed--saving rejects to stor-layout.c.rej Hmm... The next patch looks like a new-style context diff to me... The text leading up to this was: -------------------------- |*** gcc-egcs-2.93.12/toplev.c.orig Wed Mar 17 15:22:20 1999 |--- gcc-egcs-2.93.12/toplev.c Wed Mar 17 15:24:24 1999 -------------------------- Patching file toplev.c using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] y Hunk #1 succeeded at 330 (offset -17 lines). Hunk #2 succeeded at 649 (offset -3 lines). Hunk #3 failed at 965. Hunk #4 succeeded at 1077 (offset -50 lines). Hunk #5 succeeded at 3172 (offset -228 lines). Hunk #6 succeeded at 3367 (offset -50 lines). Hunk #7 succeeded at 4232 (offset -388 lines). Hunk #8 failed at 4520. 2 out of 8 hunks failed--saving rejects to toplev.c.rej Hmm... The next patch looks like a new-style context diff to me... The text leading up to this was: -------------------------- |*** gcc-egcs-2.93.12/tree.c.orig Wed Mar 17 15:22:20 1999 |--- gcc-egcs-2.93.12/tree.c Wed Mar 17 15:24:24 1999 -------------------------- Patching file tree.c using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] y Hunk #1 succeeded at 4965 (offset 12 lines). done And then of course the compilation in unsuccessful with parse (and other) errors in toplevel.c Any idea what might be the trouble? Thanks, Dimitrios. PS. I am not in the list, so please cc me

2 4

Re: Huffman compression comes to GPC!
by Frank Heckenbach 03 Aug '99

03 Aug '99

"Dr A A Olowofoyeku" wrote: > I have just completed work on an Huffman compression unit which now > supports GPC. The unit exports two main (alternative) compression > functions and two decompression functions. The routines are "dead easy" > to use, and the compression ratio compares well with ZIP's "deflate". > > I have tried to make the code portable, and I believe that I have > achieved this (it works fine with TP, BP, Delphi, FreePascal, and GPC). > AFAIK there are no "endian" issues, but I stand corrected. Unfortunately, there seem to be some. Files compressed on a little-endian machine don't uncompress on a big-endian one (or vice versa). Comparing the same file compressed on both kinds of machines shows differences in byte ordering. I don't have the time to study the code throughly enough to say exactly what the problem it, but at first sight, WDBuf might be the problem, since it contains 16-bit words which are written to a file. To solve the problem, of course, you first have to decide if you want the data files to be little or big endian. If they're following some standard, this will be given, otherwise, if you invented the format, it's up to you. Let's assume you want them to be little endian. Convert each element of the buffer to little endian using the ConvertToLittleEndian procedure, e.g.: ConvertToLittleEndian (WdBuf [i], SizeOf (WdBuf [i])) You can do this either immediately after writing the values into the buffer, or before the BlockWrite. You don't need any ifdef for this -- the routine will simply not change the values on a little endian system. Similarly, before reading values from the buffer (e.g. after the BlockRead statements), convert them back using ConvertFromLittleEndian. BTW, if you want to test the changes and don't have access to a big endian system, you might use big endian data files (perhaps only for testing, if you want little endian data files otherwise), i.e. use ConvertToBigEndian and ConvertFromBigEndian instead of ConvertToLittleEndian and ConvertFromLittleEndian, and verify that you can still compress and decompress files correctly. If you need to still compile the code with BP, you can use the following routines which are part of a GPC compatibility unit for BP which will be included in the next GPC release. (Just install the unit below where BP will find it, but GPC won't, then do a `uses GPC' in the code, so BP will use the unit below, and GPC will use its own GPC unit.) Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html unit GPC; interface const Bits_Big_Endian = False; Bytes_Big_Endian = False; Words_Big_Endian = False; Need_Alignment = False; MaxVarSize = $fff0; type SizeType = Word; procedure ReverseBytes (var Buf; Count : SizeType); procedure ConvertFromLittleEndian (var Buf; Count : SizeType); procedure ConvertFromBigEndian (var Buf; Count : SizeType); procedure ConvertToLittleEndian (var Buf; Count : SizeType); procedure ConvertToBigEndian (var Buf; Count : SizeType); function BlockReadLittleEndian (var aFile : File; var Buf; Count : SizeType) : SizeType; function BlockReadBigEndian (var aFile : File; var Buf; Count : SizeType) : SizeType; function BlockWriteLittleEndian (var aFile : File; const Buf; Count : SizeType) : SizeType; function BlockWriteBigEndian (var aFile : File; const Buf; Count : SizeType) : SizeType; implementation procedure ReverseBytes (var Buf; Count : SizeType); var i : SizeType; b : Byte; ByteBuf : array [1 .. MaxVarSize] of Byte absolute Buf; begin for i := 1 to Count div 2 do begin b := ByteBuf [i]; ByteBuf [i] := ByteBuf [Count + 1 - i]; ByteBuf [Count + 1 - i] := b end end; procedure ConvertFromLittleEndian (var Buf; Count : SizeType); begin if Bytes_Big_Endian then ReverseBytes (Buf, Count) end; procedure ConvertFromBigEndian (var Buf; Count : SizeType); begin if not Bytes_Big_Endian then ReverseBytes (Buf, Count) end; procedure ConvertToLittleEndian (var Buf; Count : SizeType); begin if Bytes_Big_Endian then ReverseBytes (Buf, Count) end; procedure ConvertToBigEndian (var Buf; Count : SizeType); begin if not Bytes_Big_Endian then ReverseBytes (Buf, Count) end; function BlockReadLittleEndian (var aFile : File; var Buf; Count : SizeType) : SizeType; var Result : SizeType; begin BlockRead (aFile, Buf, Count, Result); if InOutRes = 0 then ConvertFromLittleEndian (Buf, Count); BlockReadLittleEndian := Result end; function BlockReadBigEndian (var aFile : File; var Buf; Count : SizeType) : SizeType; var Result : SizeType; begin BlockRead (aFile, Buf, Count, Result); if InOutRes = 0 then ConvertFromBigEndian (Buf, Count); BlockReadBigEndian := Result end; function BlockWriteLittleEndian (var aFile : File; const Buf; Count : SizeType) : SizeType; var Result : SizeType; p : Pointer; begin GetMem (p, Count); Move (Buf, p^, Count); ConvertToLittleEndian (p^, Count); BlockWrite (aFile, p^, Count, Result); FreeMem (p, Count); BlockWriteLittleEndian := Result end; function BlockWriteBigEndian (var aFile : File; const Buf; Count : SizeType) : SizeType; var Result : SizeType; p : Pointer; begin GetMem (p, Count); Move (Buf, p^, Count); ConvertToBigEndian (p^, Count); BlockWrite (aFile, p^, Count, Result); FreeMem (p, Count); BlockWriteBigEndian := Result end; end.

3 2

MoreProblems with gpc
by Hernandez Perdomo Juan Carlos 30 Jul '99

30 Jul '99

After of to try "chmod +w *", I continue whith this problem ........ if [ -f libgcc2.ready ] ; then \ true; \ else \ touch libgcc2.ready; \ fi gcc -DGPC -DIN_GCC -DSVR4 -g -DHAVE_CONFIG_H -I. -I. -I./config -c p/mkstemp.c -o p/mkstemp.o p/mkstemp.c:30: system.h: No such file or directory make: *** [p/mkstemp.o] Error 1 And I can't to compile it... bye ---------- Forwarded message ---------- Date: Tue, 8 Jun 1999 18:39:54 +0200 From: Markus Gerwinski <markus(a)gnu.de> Reply-To: markus(a)adrian.gerwinski.de To: Juan Carlos <alu268(a)csi.ull.es> Subject: Re: Problem with gpc Hello, Juan! > patch: 'Makefile.in': Permission denied > ...... Try "chmod +w *". If there are still problems, ask gpc(a)gnu.de. Hope this helps Markus

2 1

Drop C-numbers and multiple compilations per file?
by Peter Gerwinski 29 Jul '99

29 Jul '99

Hello, everybody! Some features of GPC are beginning to cause serious trouble, so I consider to drop them: * Multiple compilations in one file. One source file contains one program and several units, or an interface and an implementation module, or whatever which has more than one `end.' (please note the dot). Hammering this behaviour of GPC into the GCC/EGCS backend is a nontrivial change which I do not expect the GCC steering committee to accept. (They already rejected much less crucial changes.) Thus, removing this feature would probably be necessary for full integration into GCC/EGCS. * C-style numbers. With the --c-numbers switch or the (*$C+*) directive, GPC accepts C-style octal and hexadecimal numbers such as 0755 or 0xdeadbeef. However, this does mess up other parts of the lexical analyzer. Since I do not think that this feature is widely used, I think it is better to remove it rather than "fixing" large parts of the lexical analyzer and thus inviting for more unpleasant errors. * (Other things may follow.) Comments welcome, Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75 *** Vote against SPAM! ********* http://www.politik-digital.de/spam/ ***

3 4

Re: (no subject)
by Frank Heckenbach 29 Jul '99

29 Jul '99

Adam Naumowicz wrote: > Thanks for answering, > I already have quite new version of the compiler taken from the net. > I noticed that if I try to compile my unit file test1.pas I get a warning: > > c:\gpc\lib/crt0.o(.data+0xc2):crt0.s: undefined reference to 'main' > c:\gpc\lib/libc.a(crt1.o)(.text+0x446):crt1.c: undefined reference to > 'main' > > and a .gpi file is created. Oh yes. This warning is harmless. gpc tries to link the unit to an executable, which, of course, doesn't work. To get rid of the warning when compiling a unit, you can use the -c switch. > When I compile a program using test1 the following error occures: > > c:/gpc/tmp\cceaaaaa(.text+0xad):test.pas: undefined reference to 'First' > > where First is an identifier of a function from test1. > But if i compile my program with --automake switch everything goes all > right. > Do I always have to turn on the build mode ? Yes, you should always use --automake which will cause GPC to recompile all units needed. (There's also --autobuild which will always recompile *all* units, but this shouldn't be necessary.) 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

Re: (no subject)
by Frank Heckenbach 29 Jul '99

29 Jul '99

Adam Naumowicz wrote: > Hello, > I hava a primitive question but please don't be mad at me (you know, > I don't know gpc at all). How to prepare a unit file for using in normal > USES declaration. I did it how I used to with BP, but all I got was error > message from GPC that 'undefined refference' to function from my unit > occured. You do it just like you would in BP. For examples, you can look at the included units in the "units" directory. If you still get errors with your code, please post the relevant code and the exact errors messages you get. Oh yes, and in case you're using the (very old) version 2.0, I'd recommend to upgrade to a recent alpha or beta version (already much more stable than 2.0), available from (though I think units did also work in 2.0): ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/ ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/ 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

2 1

None
by Adam Naumowicz 29 Jul '99

29 Jul '99

Hello, I hava a primitive question but please don't be mad at me (you know, I don't know gpc at all). How to prepare a unit file for using in normal USES declaration. I did it how I used to with BP, but all I got was error message from GPC that 'undefined refference' to function from my unit occured. Please help me start with GPC. --------------------------------------- Adam Naumowicz e-mail: adamn(a)math.uwb.edu.pl WWW : http://math.uwb.edu.pl/~adamn/ ---------------------------------------

1 0

Installing GPC.
by Alejandro Villarroel 26 Jul '99

26 Jul '99

Hello, I have installed GPC, reading the Faqs, and everything, but maybe I forgot some files or directories. Can somebody tell me about the directory and file structure?, so I can compare and see what file or directory is missing. And how the djgpp.env looks like. Another thing, in my bin direcotry I put some exe files, but I also put the crt0.o file that was on the lib directory, is that necesary, beacuse is the only way that gpc compile my files, also I have to copy the unit (*.pas) files in the bin directory in order to use the units, and I have to compile twice in order to have the unit in an object file (*.o). Becase of that I think some files are missing and/or I have to modify some files. Thanks in advance.

2 2

GPCC
by Peter Gerwinski 25 Jul '99

25 Jul '99

Hi, everybody, as you know, The African Chief wrote a program `GPCC' that adds Borland-style command syntax to GPC. It works as a wrapper, translates options and then calls `gpc'. Since we got no reports about problems with this utility, we can integrate it into GPC now. What about creating a new directory `utils' in the GPC source directory where GPCC and other development tools especially written for GPC can be stored? Its `Makefile' would (currently) only have to `gpc --automake' each utility and then install it in the `<prefix>/bin' directory. Any comments? Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75 *** Vote against SPAM! ********* http://www.politik-digital.de/spam/ ***

3 2

Re: Drop C-numbers and multiple compilations per file?
by Nick Burrett 25 Jul '99

25 Jul '99

Peter Gerwinski <peter(a)gerwinski.de> writes: > * Multiple compilations in one file. > > One source file contains one program and several units, or > an interface and an implementation module, or whatever which > has more than one `end.' (please note the dot). > > Hammering this behaviour of GPC into the GCC/EGCS backend is > a nontrivial change which I do not expect the GCC steering > committee to accept. (They already rejected much less > crucial changes.) Thus, removing this feature would > probably be necessary for full integration into GCC/EGCS. Can the `program'/`end.', `unit'/`end.' tokens be treated like C #ifdef, #endif pairs such that there must be an equal number of each within a source file otherwise it is flagged as an error. Perhaps the pre-processor should combine a program and it's units in much the same way as you would #include a file in C rather than leaving it up to the compiler. Nick.

1 0

I want to contribute
by Prana 24 Jul '99

24 Jul '99

To whom it may concern, I want to contribute my SVGA graphic library for the development of GNU Pascal. Anyone interested ? It has been made since 1996. Limitation : it will only run on Intel processors, since some functions were made with assembly. You can download the files from http://cyest.hypermart.net, but the version there was outdated. But it's still good. It works much better than Borland BGI engine, without requiring any BGI drivers at all. The compiled executable size is also smaller than that of Borland's with its BGI. It support up to High Color 1024x768 Please e-mail me if you're interested. I'll distribute the FULL source code, with, of course, new license. Prana

2 1

Re: GPC BUG: Problems in subrange definition if exponentiation operator used
by Frank Heckenbach 24 Jul '99

24 Jul '99

pdietrich(a)synstar.de wrote: > The exponentiation operator cannot be used in expressions for lower/upper bound > of subrange definitions. > The compiler issues two different error messages: > If a unary minus is present, the error message is "parse error before **", > otherwise it is "subrange bounds are not of the same type". > There is also a lot "extra semicolon" messages for lines following the "parse > error". The result of the `**' operator is of type real, so it can't be used where an integer is expected. For integer exponentiation, you can use the `pow' operator. (That's like `/' and `div' for real/integer division.) > program test (output); > > type > utriple = 0..2**24-1; > triple = -2**23..2**23-1; > begin > end. > > F:\PROJECTS\ISIDATA\isidef>gpc -c test6.pas > test6.pas:4: subrange bounds are not of the same type > test6.pas:5: parse error before `**' > test6.pas:5: extra semicolon There is a real bug in GPC in that expressions can't be used as lower subrange bounds. We'd like to fix it, but it turns out to be very difficult with the parser we're using, so if anyone has experience with parsers and could help here... As a workaround, you can declare a constant, so the following works: program test (output); const foo = -2 pow 23; type utriple = 0..2 pow 24-1; triple = foo..2 pow 23-1; begin end. 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

GPC BUG: Problems in subrange definition if exponentiation operator used
by pdietrich＠synstar.de 24 Jul '99

24 Jul '99

Hello, I found the following bug(s) in the Beta version of GPC. Best regards, Peter Dietrich -------------------- GPC-Version (gpc -v): Reading specs from C:\usr\local\lib\gcc-lib\i386-mingw32\2.8.1\specs gpc version 19990118, based on gcc-2.8.1 System-Version: Windows NT 4.0 on i386 Problem description: The exponentiation operator cannot be used in expressions for lower/upper bound of subrange definitions. The compiler issues two different error messages: If a unary minus is present, the error message is "parse error before **", otherwise it is "subrange bounds are not of the same type". There is also a lot "extra semicolon" messages for lines following the "parse error". The compiler is happy, if I compute the result of the expression myself, and substitute the computed result. The syntax is ok for the Digital VMS Pascal compiler. program test (output); type utriple = 0..2**24-1; triple = -2**23..2**23-1; begin end. F:\PROJECTS\ISIDATA\isidef>gpc -c test6.pas test6.pas:4: subrange bounds are not of the same type test6.pas:5: parse error before `**' test6.pas:5: extra semicolon

1 0

Re: GPC on BeOS (was: Re: Cool :) GPC on BeOS :)...)
by Frank Heckenbach 23 Jul '99

23 Jul '99

Orlando Llanes wrote: > On Thu, 22 Jul 1999, Frank Heckenbach wrote: > > (OT: Linux also has sound and since version 2.2 also graphics > > built-in if you select them...) > > But the only standard way of accessing sound in Linux costs $$$ :) > (OpenSound, open, cha! Right!). Yes, this naming is misleading, but at least for me, the default (free) drivers work fine. > > So, you could just get the GCC and GPC sources and try to build it. > > Perhaps it will just work, or there will be only minor issues that > > can easily be solved. And if you succeed, you can upload the binary > > to Agnes. :-) > > I'd love to :) I'll post as soon as I have any results. I wish I had a > Mac Performa 6360 (6460? I forget which one), it runs the PowerPC version > of BeOS (BeOS is on a hybrid CD), would be cool to have a PPC GNU Pascal > with assembler and everything :) Good luck! 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

Re: GPC on BeOS (was: Re: Cool :) GPC on BeOS :)...)
by Frank Heckenbach 23 Jul '99

23 Jul '99

Orlando Llanes wrote: > I have BeOS 3.x and 4.5, they are both POSIX compatible far as I > know. To me, BeOS looks like Linux with graphics and sound capabilities > built-in. (OT: Linux also has sound and since version 2.2 also graphics built-in if you select them...) > I don't know about sh (though it uses a "Terminal" program which is > prolly compatible), but it does have a version of GCC with it, so all > tools should be in place (4.5 is better than 3.x because GCC, and its > tools, is in the path). So, you could just get the GCC and GPC sources and try to build it. Perhaps it will just work, or there will be only minor issues that can easily be solved. And if you succeed, you can upload the binary to Agnes. :-) 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

2 1

Re: GPC on BeOS (was: Re: Cool :) GPC on BeOS :)...)
by Frank Heckenbach 22 Jul '99

22 Jul '99

Orlando Llanes wrote: > Maybe someone oughta make a "real" BeOS port of GPC :) I don't know if > it's possible on version 3.x of BeOS since it does not use the COFF format > (but Be is not going to support BeOS 3 for long anyway). But the weird > thing is that BeOS 3 has a GCC compiler. I think that the OS specific > calls use a lib anyway, so it *might* be a simple matter of recompiling > GPC. I don't know if BeOS' GCC is capable of creating GUI apps, if it is, > GPC can easily do so as well. All it takes is a port of the binutils (i.e., as and ld), a GCC backend (the harder part is the processor specific part, and this, of course, exists already for the other OS's), and some standard libraries, in particular a more-or-less POSIX compatible libc. I don't know if BeOS is (or aims to be) POSIX compliant, but even if not, it is possible to write a POSIX layer on top of the system, like e.g. DJGPP which provides a very faithful and extensive POSIX layer on top of Dos which is about as far from POSIX as possible. ;-) If GCC works on BeOS, then there probably are already binutils and the backend, and also the libraries unless the compiler is used only for non-standard programs, so indeed it might be a simple matter of recompiling. (Compiling natively on BeOS requires some more tools like sh, make, sed, etc., but if they don't exist and can't be compiled, it's also possible to cross-compile GPC for BeOS from, say, a Linux host.) 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

2 1

Pascal Bug
by Ricky W. Butler 22 Jul '99

22 Jul '99

The following program: program bug(input,output); var x : real; begin x := 0.5000000000000E+00; writeln(' x = ',x:10:3); end. incorrectly prints out x = 5.000 It should print out x = 0.500 This program was compiled with GNU Pascal version 19990118, based on gcc-2.8.1, compiled Jun 15 1999 09:46:03. gpc --verbose Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/2.8.1/specs gpc version 19990118, based on gcc-2.8.1 ld -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/gcc-lib/i686-pc-linux-gnu/2.8.1/crtbegin.o -L/usr/lib/gcc-lib/i686-pc-linux-gnu/2.8.1 -lgpc -lm -lgcc -lc -lgcc /usr/lib/gcc-lib/i686-pc-linux-gnu/2.8.1/crtend.o /usr/lib/crtn.o /usr/lib/crt1.o(.text+0x36): undefined reference to `main' Rick Butler

2 2

Re: Cool :) GPC on BeOS :)...
by Frank Heckenbach 21 Jul '99

21 Jul '99

Dr A A Olowofoyeku wrote: > > > they have a port of GPC 2.1 :) > > > > 8-) Cool! Since we do not have v2.1 ourselves yet, perhaps we > > should ask them for a copy of their source? ;-) > > They do seem to have a port of GPC v2.1 (or so they claim). Unfortunately, the latter... In src/Read me!, it says: GNU Pascal for BeOS gpc-19980830.tar.gz This is, as you know, of course, not 2.1, but a beta version more or less close to the upcoming 2.1... I suppose we should point out this difference to them, as well as the fact that distributing the binary without the source, as they do, is illegal according to the GPL. I know that Be has violated the GPL in another case, but perhaps some day they'll learn... 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

4 3

Cool :) GPC on BeOS :)...
by Orlando Llanes 21 Jul '99

21 Jul '99

I recently visited BeOS' website, and it seems that on http://www.classic-be.com/beware they have a port of GPC 2.1 :) See ya! Orlando Llanes "Meine Damen und Herren, Elvis hat soeben das Gebaeude verlassen!" "Look out fo' flyeeng feet" O__/ a010111t(a)bc.seflin.org \/|____. O <__. \/\> / \ ____________|___\______ http://ourworld.compuserve.com/homepages/Monkey414

3 4

New
by Adam Naumowicz 20 Jul '99

20 Jul '99

Hello, I've just tried to install gnu pascal compiler (djgpp distribution) on my Windows and I can't compile even a primitive 'hello world' program. The linker throws an error that there is no DJGPP.DJL script. I searched the FAQ and found that there should be no such a file. So please tell me why the error occurs. Adam Naumowicz http://math.uwb.edu.pl/~adamn/

2 3

Structure of GPC.
by Alejandro Villarroel 20 Jul '99

20 Jul '99

Hi Peter, I going to copy all the structure of directories and files. C:\gpc\BIN C:\gpc\info C:\gpc\LIB C:\gpc\libc C:\gpc\Unit C:\gpc\Include C:\gpc\djgpp.env C:\gpc\BIN\exe C:\gpc\BIN\OUT C:\gpc\BIN\PAS C:\gpc\BIN\GO.BAT C:\gpc\BIN\JUA.BAT C:\gpc\BIN\BPC.EXE C:\gpc\BIN\EPC.EXE C:\gpc\BIN\GPC.EXE C:\gpc\BIN\PC.EXE C:\gpc\BIN\as.exe C:\gpc\BIN\GPC-CPP.EXE C:\gpc\BIN\RHIDE.EXE C:\gpc\BIN\gdb.exe C:\gpc\BIN\sal.exe C:\gpc\BIN\GPC1.EXE C:\gpc\BIN\ld.exe C:\gpc\BIN\stubify.exe C:\gpc\BIN\example.exe C:\gpc\BIN\CRT0.O C:\gpc\BIN\gpc.o C:\gpc\BIN\gmp.o C:\gpc\BIN\EXAMPLE.PAS C:\gpc\BIN\GPC.PAS C:\gpc\BIN\GMP.PAS C:\gpc\BIN\LEAME.TXT C:\gpc\Include\_ansi C:\gpc\Include\ar.h C:\gpc\Include\assert.h C:\gpc\Include\bios.h C:\gpc\Include\coff.h C:\gpc\Include\conio.h C:\gpc\Include\crt0.h C:\gpc\Include\ctype.h C:\gpc\Include\dir.h C:\gpc\Include\direct.h C:\gpc\Include\dirent.h C:\gpc\Include\dos.h C:\gpc\Include\dpmi.h C:\gpc\Include\errno.h C:\gpc\Include\fcntl.h C:\gpc\Include\file.h C:\gpc\Include\float.h C:\gpc\Include\fnmatch.h C:\gpc\Include\ftw.h C:\gpc\Include\getpagesize.h C:\gpc\Include\glob.h C:\gpc\Include\go32.h C:\gpc\Include\gppconio.h C:\gpc\Include\grp.h C:\gpc\Include\ieeefp.h C:\gpc\Include\io.h C:\gpc\Include\keys.h C:\gpc\Include\limits.h C:\gpc\Include\locale.h C:\gpc\Include\malloc.h C:\gpc\Include\math.h C:\gpc\Include\mem.h C:\gpc\Include\memory.h C:\gpc\Include\mntent.h C:\gpc\Include\osfcn.h C:\gpc\Include\pc.h C:\gpc\Include\process.h C:\gpc\Include\pwd.h C:\gpc\Include\random.h C:\gpc\Include\regex.h C:\gpc\Include\search.h C:\gpc\Include\setjmp.h C:\gpc\Include\share.h C:\gpc\Include\signal.h C:\gpc\Include\std.h C:\gpc\Include\stdarg.h C:\gpc\Include\stddef.h C:\gpc\Include\stdio.h C:\gpc\Include\stdlib.h C:\gpc\Include\string.h C:\gpc\Include\strings.h C:\gpc\Include\stubinfo.h C:\gpc\Include\termios.h C:\gpc\Include\time.h C:\gpc\Include\tzfile.h C:\gpc\Include\unistd.h C:\gpc\Include\utime.h C:\gpc\Include\values.h C:\gpc\Include\varargs.h C:\gpc\Include\wctype.h C:\gpc\Include\wchar.h C:\gpc\info\dir C:\gpc\info\INFVIEW.ENG C:\gpc\info\INFVIEW.GER C:\gpc\info\gpc.inf C:\gpc\info\EDITOR.INF C:\gpc\info\INFVIEW.INF C:\gpc\info\RHIDE.INF C:\gpc\info\gpc.i1 C:\gpc\info\gpc.i10 C:\gpc\info\gpc.i11 C:\gpc\info\gpc.i12 C:\gpc\info\gpc.i13 C:\gpc\info\gpc.i14 C:\gpc\info\gpc.i15 C:\gpc\info\gpc.i2 C:\gpc\info\gpc.i3 C:\gpc\info\gpc.i4 C:\gpc\info\gpc.i5 C:\gpc\info\gpc.i6 C:\gpc\info\gpc.i7 C:\gpc\info\gpc.i8 C:\gpc\info\gpc.i9 C:\gpc\info\INFVIEW.SPA C:\gpc\LIB\specs C:\gpc\LIB\libgpc.a C:\gpc\LIB\libm.a C:\gpc\LIB\libdbg.a C:\gpc\LIB\libc.a C:\gpc\LIB\libemu.a C:\gpc\LIB\libg.a C:\gpc\LIB\libpc.a C:\gpc\LIB\libgcc.a C:\gpc\LIB\djgpp.djl C:\gpc\LIB\dxe.ld C:\gpc\LIB\crt0.o C:\gpc\LIB\gcrt0.o C:\gpc\libc\specs C:\gpc\libc\libc.a C:\gpc\libc\libdbg.a C:\gpc\libc\libemu.a C:\gpc\libc\libg.a C:\gpc\libc\libm.a C:\gpc\libc\libpc.a C:\gpc\libc\djgpp.djl C:\gpc\libc\dxe.ld C:\gpc\libc\crt0.o C:\gpc\libc\gcrt0.o C:\gpc\Unit\crtc.c C:\gpc\Unit\dosc.c C:\gpc\Unit\getoptc.c C:\gpc\Unit\pexecutc.c C:\gpc\Unit\pipec.c C:\gpc\Unit\regexc.c C:\gpc\Unit\crtx.c C:\gpc\Unit\crtc.h C:\gpc\Unit\crtdospc.h C:\gpc\Unit\crtdummy.h C:\gpc\Unit\crtlinux386.h C:\gpc\Unit\crtunix.h C:\gpc\Unit\crtunix1.h C:\gpc\Unit\getopt.h C:\gpc\Unit\pexecute.h C:\gpc\Unit\crt.inc C:\gpc\Unit\dos.pas C:\gpc\Unit\crt.pas C:\gpc\Unit\dosunix.pas C:\gpc\Unit\getopt.pas C:\gpc\Unit\gmp.pas C:\gpc\Unit\gpc.pas C:\gpc\Unit\gpcutil.pas C:\gpc\Unit\internal.pas C:\gpc\Unit\overlay.pas C:\gpc\Unit\pexecute.pas C:\gpc\Unit\pipe.pas C:\gpc\Unit\ports.pas C:\gpc\Unit\printer.pas C:\gpc\Unit\regex.pas C:\gpc\Unit\strings.pas C:\gpc\Unit\system.pas C:\gpc\Unit\turbo3.pas C:\gpc\Unit\windos.pas Peter Gerwinski wrote: > Alejandro Villarroel wrote: > > command line> gpc -v --automake example.pas -o example > > error> > > Reading specs from c:\gpc\lib\specs > > gpc version 19990503, based on gcc-2.8.1 > > c:\gpc\bin\gpc-cpp.exe [...] > > Okay, this should be in a directory like > c:\djgpp\lib\gcc-lib\djgpp\2.81\ . Obviously something > is wrong with your installation ... > > What else do you have in your c:\gpc directory? A complete > DJGPP installation (with `djgpp.env' etc.)? > > Does your installation come with a `gpc.pas' file? > > It seems as if you are not using a distribution from our main > server ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/ . Where > did you get yours from? I recommend to retry with an archive > from ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/binary/ . > > Peter > > -- > Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ > Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 > PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75 > *** Vote against SPAM! ********* http://www.politik-digital.de/spam/ ***

2 1

Still bothering with the Units.
by Alejandro Villarroel 20 Jul '99

20 Jul '99

Ok. Peter, I'm going to put what the compiler says with those commands you gave me. But first, I think it's related with djgpp.env, I write there the lines the info files said about it. I don't have there the units directory, but the compiler and library paths. Another thing I'll appreciate is if you can tell me the directory and files I need in order to run properly GPC, I guess I have files missing. I read the info files, but finally I build up the directories and put there the files I thought were the proper ones. I guess I had to tell this before. Well to the point. 1. First try. command line> gpc --automake example.pas -o example error> example.pas:3: module/unit `gpc' could not be compiled 2. Second try. command line> gpc -v --automake example.pas -o example error> Reading specs from c:\gpc\lib\specs gpc version 19990503, based on gcc-2.8.1 c:\gpc\bin\gpc-cpp.exe -lang-pascal -v -nocharescape -D__GNU_PASCAL__ -undef -D __GNUC__=2 -D__GNUC_MINOR__=8 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=19 990503 -Dunix -Di386 -DGO32 -DMSDOS -DDJGPP=2 -DDJGPP_MINOR=2 -D__OS_DOS__=1 -D_ _unix__ -D__i386__ -D__GO32__ -D__MSDOS__ -D__DJGPP__=2 -D__DJGPP_MINOR__=2 -D__ OS_DOS__=1 -D__unix -D__i386 -D__GO32 -D__MSDOS -D__DJGPP=2 -D__DJGPP_MINOR=2 -D __BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 example.pas c:/gpc/bin/RHbaaaaa\cccaaaaa GNU CPP version 2.8.1 (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: c:/gpc/lang/pascal c:/gpc/include c:/gpc/contrib/grx20/include /usr/local/include $DJDIR/djgpp/include $DJDIR/lib/gcc-lib/djgpp/2.81/include /usr/include End of search list. c:\gpc\bin\gpc1.exe c:/gpc/bin/RHbaaaaa\cccaaaaa -m486 -malign-jumps=2 -malign- loops=2 -malign-functions=2 -m486 -malign-jumps=2 -malign-loops=2 -malign-functi ons=2 -quiet -dumpbase example.pas -version -famtmpfile=c:/gpc/bin/RHbaaaaa\ccaa aaaa.gpc -fautomake -o c:/gpc/bin/RHbaaaaa\ccdaaaaa GNU Pascal version 2.8.1 (djgpp) compiled by GNU C version 2.8.1. example.pas:3: module/unit `gpc' could not be compiled

2 1

Re: Pascal Bug
by Frank Heckenbach 20 Jul '99

20 Jul '99

Ricky W. Butler wrote: > The following program: > > program bug(input,output); > var > x : real; > > begin > x := 0.5000000000000E+00; > writeln(' x = ',x:10:3); > end. > > incorrectly prints out > > x = 5.000 > > It should print out > > x = 0.500 This seems to be a severe bug. Thanks for pointing it out. It has been added to our test suite (rick1.pas), and will hopefully be fixed soon. As a work-around, you could use `E-00' instead of `E+00' (or no exponent at all)... 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

Re: About Units.
by Alejandro Villarroel 19 Jul '99

19 Jul '99

Peter Gerwinski wrote: > > Hi Peter, thanks a lot for your help. By the wat I'm using Rhide, and I > > put this in the compiler options --automake, and this time it said that it > > can not compile the module/unit gpc > > RHIDE can add `--automake' automatically. Remove it from the > compiler options, and instead define a "Pascal primary file" in > the "Project" menu. In the Project menu, there is a options called primary file, what exactily I have to write there? the name of the *.pas file? because I did that and the it said that It cannot import the Module/unit gpc. > > Peter > > -- > Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ > Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 > PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75 > *** Vote against SPAM! ********* http://www.politik-digital.de/spam/ ***

2 1

About Units.
by Alejandro Villarroel 19 Jul '99

19 Jul '99

I apologize for my questions but I'm just starting to use GNU pascal. I have this problem, I'm using a very small test program like this: program example; uses gpc; var a:integer; Begin a:=1; writeln('Hello'); end. But when I tried to compile this programa it said that It cannot import gpc module/unit, I tried with other units with the same result. { By the way the units (in the unit directory) are *.pas, right? } What I have to do?

2 1

Re: Modules/Units.
by Frank Heckenbach 15 Jul '99

15 Jul '99

Alejandro Villarroel wrote: > Hello. I'm a beginner with Gnu Pascal, so I have the binary file > gpc.exe and the other files like pc.exe, bpc.exe epc.exe I know there > are subtle dirfferences between them, can you tell me wich are. pc compiles Standard Pascal, epc Extended Pascal (both according to the official standards), bpc is as compatible to Borland/Turbo Pascal as possible (which means, less conforming to the standard), and gpc (the default) provides the union of all those standards and dialects plus some extensions. The same can be achived with the command line switches `--standard-pascal', `--extended-pascal', `--borland-pascal' and `--gnu-pascal' (the latter is the default, so it isn't needed normally). The switches should be preferred, because we're thinking about dropping the separate executables in future versions. I can't describe all the features here, of course, but you can find a list of some interesting features of each and some demo programs in http://home.pages.de/~GNU-Pascal/about.html Besides, the GPC info lists all built-in identifiers and reserved words, and mentions to which language versions they belong (at least, for most of them, some may still be missing). In general, it's best to use the default (i.e., all GPC features), unless standard conformant programs have to be written (`--standard-pascal' or `--extended-pascal' then), or BP programs with many "dirty tricks" should be ported with minimal effort (`--borland-pascal' then). > Well, > in Turbo Pascal, there is a directory named units, where all the .tpu > files live. I guess, that I have to compile the source files in the > include directory that came with the gpc files . In the recent GPC releases (e.g. GPC-19990118) the units are in a directory `units', not `inlcude'. > I've tried to compile > and link gpc.pas, but the followwing error message appear: > > In the command line: > gpc -m486 -O gpc.pas -Ic:\gpc\include -Lc:\gpc\lib -o exe\gpc.o Units can't be linked, only programs (and dynamic libraries) can. Therefore, use the `-c' switch (compile only). Besides, the `-m486' switch should be unnecessary as well as the `-I' and `-L' switches if you install GPC into the default directories below your DJGPP directory (assuming you're using the DJGPP version). However, you can also compile any program with the `--automake' switch, and all needed units will be compiled automatically (if you have the units installed in a non-default directory, you can specify the path with `--unit-path=/foo/bar/baz'). So, normally you won't have to care about compiling the units. > By the way, I've used Rhide 1.4 before, with the same result. > Speaking about rhide..., I have only configured the directories, but > what with the rest, is there something important that I have to put in > the other menus? I don't think so, but with a new release of GPC, you should create a file named rhide.env in %DJDIR%/share/rhide/, containing the following line: RHIDE_COMPILE_LINK_PASCAL_AUTOMAKE=$(RHIDE_LD_PASCAL) $(RHIDE_LIBDIRS) $(RHIDE_LDFLAGS) -o $(OUTFILE) --automake $(RHIDE_GPC_FLAGS) $(SOURCE_NAME) $(RHIDE_LDFLAGS) 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

Re: symbol out of scope
by Frank Heckenbach 15 Jul '99

15 Jul '99

Peter Gerwinski wrote: > Other compilers that cannot handle sets with limits outside > 0..255 have the same problem but do not warn. So there is a > lot of existing code with this problem. BP does at least a bit of checking when overflow checking is turned on, but it's a bit buggy... 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

Modules/Units.
by Alejandro Villarroel 15 Jul '99

15 Jul '99

Hello. I'm a beginner with Gnu Pascal, so I have the binary file gpc.exe and the other files like pc.exe, bpc.exe epc.exe I know there are subtle dirfferences between them, can you tell me wich are. Well, in Turbo Pascal, there is a directory named units, where all the .tpu files live. I guess, that I have to compile the source files in the include directory that came with the gpc files . I've tried to compile and link gpc.pas, but the followwing error message appear: In the command line: gpc -m486 -O gpc.pas -Ic:\gpc\include -Lc:\gpc\lib -o exe\gpc.o Message crt0.o(.data+0xc2):crt0.s: undefined referenc c:\gpc\lib/libc.a(crt1.o)(.text+0x446):crt1.c Presione cualquier tecla para continuar . . . By the way, I've used Rhide 1.4 before, with the same result. Speaking about rhide..., I have only configured the directories, but what with the rest, is there something important that I have to put in the other menus? Thanks in Advance, Alejandro Villarroel

1 0

Re: symbol out of scope
by Frank Heckenbach 15 Jul '99

15 Jul '99

Peter Gerwinski wrote: > Leonardo A. Saravia wrote: > > I have just installed gpc-19990118.i386-pc-djgppv201.zip and try to compile > > a program designed for VMS (VAX) or CMS (IBM) operative systems. I will > > appreciate some help, it seems to be a configuration problem, and I am new > > with Pascal and GNU Pascal. > > > > autocor.pas: In function `Add': > > autocor.pas:311: warning: constructing limited integer set `0..255' > > These warnings are coming from sets like "[ i ]" where `i' is a > variable of plain integer type. GPC cannot currently handle > "set of Integer" and warns about the restriction of the valid > scope for `i'. > > Maybe we should take out this warning - it is somewhat too > verbose ... I don't think so, since it can be a real problem, if I understand it correctly. If i is < 0 or > 255, the result will be wrong, right? However, if i is declared as 0 .. 255 rather than Integer, this is safe (modulo GPC's missing range checking :-/), and there is no warning. However^2, GPC will soon know `Include' and `Exclude' (compatible to BP 7) which will be able to handle out of range values correclty (i.e., cause a runtime error or ignore them, but not cause a wrong result). And perhaps, some day, GPC will be able to handle sets of dynamic size, and `[i]' with i : Integer will work without problems... 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

2 1

symbol out of scope
by Leonardo A. Saravia 14 Jul '99

14 Jul '99

Hi, I have just installed gpc-19990118.i386-pc-djgppv201.zip and try to compile a program designed for VMS (VAX) or CMS (IBM) operative systems. I will appreciate some help, it seems to be a configuration problem, and I am new with Pascal and GNU Pascal. autocor.pas: In function `Add': autocor.pas:311: warning: constructing limited integer set `0..255' autocor.pas:313: warning: constructing limited integer set `0..255' autocor.pas: In function `Sub': autocor.pas:320: warning: constructing limited integer set `0..255' autocor.pas:322: warning: constructing limited integer set `0..255' autocor.pas: In function `Ajoute': autocor.pas:329: warning: constructing limited integer set `0..255' autocor.pas: In function `Enleve': autocor.pas:336: warning: constructing limited integer set `0..255' autocor.pas: In function `Initbit': autocor.pas:1602: warning: constructing limited integer set `0..255' c:/djgpp/tmp\ccdaaaaa: Assembler messages: c:/djgpp/tmp\ccdaaaaa:17201: Fatal error: C_EFCN symbol out of scope Thanks Leonardo A. Saravia - Programa de Invest. en Ecologia Matematica Universidad Nacional De Lujan - C.C. 221 - (6700) - Lujan - Argentina Tel: 54 2323 423171/421030 Fax: 54 2323 425975 e-mail: lsaravia(a)mail.retina.ar

2 1

Re: Otherwise
by Peter Gerwinski 13 Jul '99

13 Jul '99

Hi! Jonathan Ashley wrote: > > Well, I get: > > other.pas: In function `program_Testcase': > other.pas:15: parse error before `Otherwise' > [...] Ah - this bug was fixed on 9 Apr 1999, probably after your first posting about this. Please get, compile and install a recent snapshot from ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/ to solve the problem. Hope this helps, Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75 *** Vote against SPAM! ********* http://www.politik-digital.de/spam/ ***

1 0

RE: Otherwise
by Jonathan Ashley 13 Jul '99

13 Jul '99

>What's the problem? For me, this program outputs "value wasn't 1" >as it should be. > >If I change the first assignment to "test := 1" I get "subvalue >was 5", so everything okay here, too. Damn! :-) Well I get: other.pas: In function `program_Testcase': other.pas:15: parse error before `Otherwise' other.pas:15: undeclared identifier `Otherwise' (first use this function) other.pas:15: (Each undeclared identifier is reported only once other.pas:15: for each function it appears in.) other.pas:16: missing `..' other.pas:16: parse error before `End' I'm using gpc 2.8.1 on Solaris. I downloaded a binary distrib. a few weeks ago. Very strange... regards, -- Jon Ashley ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. This email has been swept for the presence of known computer viruses. **********************************************************************

1 0

Otherwise
by Jonathan Ashley 13 Jul '99

13 Jul '99

Hi all, I posted to this list before, but we were in the middle of switching mail systems and I'm not sure my message got out. The gist of my message was: there seems to be a bug in the way GPC handles the 'otherwise' clause of a case statement. If one of the previous cases contains a case statement itself, the compiler falls over. For example: ----------- program TestCase(input, output); var test: integer; subtest: integer; begin test := 3; subtest := 5; case test of 1: case subtest of 5: writeln("subvalue was 5") end otherwise writeln("value wasn't 1") end end. ----------- Has anyone else noticed this or is it my mistake? regards, -- Jon Ashley ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. This email has been swept for the presence of known computer viruses. **********************************************************************

2 1

Re: "<>" operator (was: First question)
by Ken Linder (KC7RAD) 09 Jul '99

09 Jul '99

Hi Hilohi, Yes, GPC strings require single quotes `'` not double quotes. Your assumption is correct... Use the single quotes. And by the way... Don't be ashamed of asking anything on this mailing list. You should see some of the stupid questions I have asked! :-) All the best! Ken Linder ken(a)kc7rad.lvcm.com or pas(a)kc7rad.lvcm.com http://kc7rad.lvcm.com/ At 08:26 PM 7/9/99 +0300, Hilohi Gabriel wrote: >Well ... it's a much simple program .. I'm quite ashame of showing it to >such experienced programmers as i think you are ... >But it was a simple instruction : > >while s <> " " do > >and s was s:string[1000] > >Do i have to say > while s <> ' ' ??? > >

1 0

TEST
by Hilohi Gabriel 09 Jul '99

09 Jul '99

Is this the mailing list ? I subscribed to some gnu-pascal list but it had a different email address ... Please reply as soon as possible ... Thank you

2 5

Re: Support for gcc-2.8.1?
by Frank Heckenbach 08 Jul '99

08 Jul '99

"Russ Whitaker" wrote: > Receintly I purchased the latest distribution of SuSE: 6.1 > It contains: > > GCC 2.7.2.3-36 > GPC 990118-0 > egcs 990315-9 Then obviously Peter's protest has had an effect. The 6.1 shipped in Germany still contained a prehistoric version, AFAIK, but apparently the international version, which might have come out a little later, now contains a current GPC. :-) > Their comment on egcs: > > "This is the present state of the egcs-compiler-develement > Unfortunately it is not advisable to compile a 2.0.x kernel > with this compiler yet." I don't think this is going to change, since the bugs are in the kernel, not the compiler (it relies on undocumented behaviour of GCC-2.7.x) -- except that the 2.0 kernels will fade out, as 2.2 spreads, which is safe to compile with newer GCC versions and EGCS, AFAIK. > Would expect the other distributions to be somewhat simular. > Therefore, why not bundle a cut-down version of gcc-xxx with > gpc? Then YOU control which version of gcc is being used and > all the receiver would have to do ( hopefully ) is unpack and compile I don't think we should include it in the GPC source archive, because that would blow up the download size substantially for those who have it already, but we could (and IMHO should) always put the source of the "correct" GCC version besides the GPC source in the same directory on Agnes (or alternatively, one archive with GPC only and one with GPC and GCC). 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

2 1

Re: Support for gcc-2.8.1?
by Russ Whitaker 08 Jul '99

08 Jul '99

Hi Peter On Wednesday, June 30, 1999 5:34 PM you wrote > > Hello, folks! > > The EGCS is going to release egcs-1.2 as gcc-2.95. > > How much sense does it make to continue support for > (a) gcc-2.8.1 and (b) egcs-1.1.x? > > Since it causes work to continue with (a) and (b), > I'd prefer to switch completely to gcc-2.95. > > Comments? Objections? Receintly I purchased the latest distribution of SuSE: 6.1 It contains: GCC 2.7.2.3-36 GPC 990118-0 egcs 990315-9 Their comment on egcs: "This is the present state of the egcs-compiler-develement Unfortunately it is not advisable to compile a 2.0.x kernel with this compiler yet." According to the file list egcs 990315 is egcs-2.91.66 Would expect the other distributions to be somewhat simular. Therefore, why not bundle a cut-down version of gcc-xxx with gpc? Then YOU control which version of gcc is being used and all the receiver would have to do ( hopefully ) is unpack and compile Thanks, Russ <russwhit(a)mind.net>

2 1

GPC mailing list archive?
by Broadey, Kevin M 07 Jul '99

07 Jul '99

Is this mailing list archived anywhere? The FAQ doesn't say so, and the links from the GPC Home Page only point off to UNIX mailbox files for traffic up to the end of 1998. It would be handy to have the list searchable online. Kevin

3 2

GPC FEATURE REQUEST: STDCALL needed
by pdietrich＠synstar.de 03 Jul '99

03 Jul '99

Hello, the WIN32 API uses the stdcall calling convention, i.e. the stack pointer is adjusted by the called routine on return. This is not supported by GNU Pascal. Borland Pascal uses the keyword "stdcall" to specify this call format. This is needed for GNU Pascal, too. Best regards, Peter Dietrich

2 1

Support for gcc-2.8.1?
by Peter Gerwinski 01 Jul '99

01 Jul '99

Hello, folks! The EGCS is going to release egcs-1.2 as gcc-2.95. How much sense does it make to continue support for (a) gcc-2.8.1 and (b) egcs-1.1.x? Since it causes work to continue with (a) and (b), I'd prefer to switch completely to gcc-2.95. Comments? Objections? Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75 *** Vote against SPAM! ********* http://www.politik-digital.de/spam/ ***

2 1

GNU Pascal.
by Alejandro Villarroel 30 Jun '99

30 Jun '99

Is my first time with this, so I'll apreciate any help. I want to install Pascal in PCs with DOS, I have all the files required, but which are the steps to follow in order to install GNU Pascal. If I want to install it on a Windows platform, what I have to do? and what other files I will need? Thanks in advance Alejandro Villarroel

2 1

Re: compiler problem
by Frank Heckenbach 30 Jun '99

30 Jun '99

Michael Hofmann wrote: > Hi, > > the following little program doesn't run under gpc version 2.0(2.7.2.1)! > > program lesen (infile,output); > > const > n = 100; > > type > text = File of char; > filearray = array[1..n] of real; > > var > i : integer; > infile : text; > filearray1 : filearray; > > begin > reset(infile); > for i:= 1 to n do > begin > read(infile,filearray1[i]); > write(filearray1[i]); > end; > > end. > > I get the compiler message:gpc: Internal compiler error: program gpc1 got > fatal signal 6 > I know that the program runs under a Sun-Compiler! > > when I substitute filearray = array[1..n] of real; by > filearray = array[1..n] of integer; , then compilation is successful. The problem is your declaration: > type > text = File of char; According to the Pascal standards, a `Text' file is similar to a `File of Char', but not the same. In particular, one can read numeric data from `Text' files, but not from `File of Char'. If the Sun compiler allows this, that's non-standard behaviour, which GPC currently does not support. However, if you just remove this declaration, it should work, since `Text' is a predefined type in Pascal. If you then still get problems with GPC, please upgrade to a recent alpha or beta version (already much more stable than 2.0), available from: ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/ ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/ Frank -- Frank Heckenbach, frank(a)fjf.gnu.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

compiler problem
by Michael Hofmann 30 Jun '99

30 Jun '99

Hi, the following little program doesn't run under gpc version 2.0(2.7.2.1)! program lesen (infile,output); const n = 100; type text = File of char; filearray = array[1..n] of real; var i : integer; infile : text; filearray1 : filearray; begin reset(infile); for i:= 1 to n do begin read(infile,filearray1[i]); write(filearray1[i]); end; end. I get the compiler message:gpc: Internal compiler error: program gpc1 got fatal signal 6 I know that the program runs under a Sun-Compiler! when I substitute filearray = array[1..n] of real; by filearray = array[1..n] of integer; , then compilation is successful. Michael. mail:hofmann@ph2.uni-koeln.de

2 1

Installation Trouble (Windows 98)
by Brian M. Begg 28 Jun '99

28 Jun '99

June 26, 1999 Hello: I am having trouble installing all of the MINGW32 based tools that I downloaded as zip files. I am in Windows 98, and I have the WINZIP utility for unzipping. It works with just about all of these (downloaded) zipped based tools except: "gcc-2_8_1" and "gas-980119" An error message keeps coming (up when I unzip) that says: "Error: cannot create C:/MINGW32/bin/c++filt.exe. Please press F1 for help. " Also, for "mingw32-980105" an error msg: "cannot create C:/MINGW32/samples/dlltest/rcs/dll.c,v. Please press F1 for help." What should I do? Please help if u can. Best Regards, Brian Begg --------> brianb(a)ixpres.com p.s. e-mail anytime you like.

2 1

GPCC (BP compatibility compiler front end for GPC)
by Dr A A Olowofoyeku 25 Jun '99

25 Jun '99

Hi all I have just put a copy of the latest incarnation of GPCC (a Borland-Pascal compatibility compiler front end for GPC) on : http://freeweb.digiweb.com/computers/African_Chief/gpcc200.zip Please download for testing and please report all bugs, problems and suggestions to me. This is eventually going to be released as part of the main GPC distribution, so your input will be appreciated at this stage. The main goal of GPCC is to implement some of the main features of the Borland Pascal command line compilers (TPC and BPC), under GPC, by; [a] supporting some of the Borland compiler options and switches [b] reading options and switches from a configuration text file (named by default in the Borland style with a ".cfg" extension) [c] attempting to identify from a basic parsing of the first few lines of a source file whether the source file is a UNIT/MODULE or PROGRAM/UNIT, and supplying appropriate parameters to the linker [d] looking (if no extension is supplied for a filename) for the file, with the following extensions, and in the following order; [a] ".pas" [b] ".p" [c] ".pp" [d] ".dpr" This is really meant to assist those coming to GPC from a BP/TP or Delphi background. It is *not* designed to replace "make" or such tools which unix and linux gurus are accustomed to. The real object is to reduce the numerous GPC compiler switches into something accessible to BP/TP/Delphi people. Therefore it will never do anything really complicated or clever. Please bear these points in mind when making comments or suggestions. One of the main things I am looking to comments about on is whether I have correctly interpreted the BP parameters in converting them to GPC parameters. I do not have a definitive list (with full explanations/descriptions) of all the GPC compiler and linker parameters, so if there are gaps in my implementation, please supply the necessary information to do it correctly. Thanks! Best regards, The Chief -------- Dr. Abimbola A. Olowofoyeku (The African Chief) Email: laa12(a)keele.ac.uk Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ Author of: Chief's Installer Pro v5.10 for Win32 ftp://ftp.demon.co.uk/pub/ibmpc/win95/apps/chief32/chief510.zip

1 0

Latest GPC + Solzris 7 + egcs/gcc
by Jovan Ilic 22 Jun '99

22 Jun '99

Did anybody compile gpc under Solaris 2.7 and egcs 1.1.1->gcc2.95 or gcc-2.8.1? I always get signal 6 when it starts compiling gpc files. Thanks, ilic(a)thetausa.com

2 3

re: snapshot
by Russ Whitaker 22 Jun '99

22 Jun '99

hi Frank As you know and I Just found out moving the tree from /usr/lib to /usr/local/lib doesn't work too well so I recompiled: make dist clean make clean (just in case ) ./configure --prefix=/usr/local then make LANGUAGES=pascal CFLAGS="-O2" until it crashed, then make LANGUAGES=pascal until it crashed, then created 2 directories and a soft link, ar->/usr/bin, then make LANGUAGES=pascal make pascal.install All this gave me a partially optimized gpc installed under /usr/local and working nicely thanks Russ

2 1

GPC BUG: Initializer for tagged variant records does not work
by pdietrich＠synstar.de 18 Jun '99

18 Jun '99

Hello, I found the following bug in the Beta version of GPC. Best regards, Peter Dietrich -------------------- GPC-Version (gpc -v): Reading specs from C:\usr\local\lib\gcc-lib\i386-mingw32\2.8.1\specs gpc version 19990118, based on gcc-2.8.1 System-Version: Windows NT 4.0 on i386 Problem description: Variant records with tag fields cannot be initialized. The following program is not accepted by the compiler: program test (output); type t = record f1 : integer; case tag : integer of 0: (i : integer); 1: (r : real); end; var r : t value (1, 1, 3.14); begin writeln (r.f1, r.tag, r.r); end. The error message is: test3.pas:10: incompatible types in initialization test3.pas:10: initial value is of wrong type If I omit the 3.14 compilation succeeds but only f1 and tag are initialized.

4 3

[Fwd: GPC BUG: Initializer for tagged variant records does not work]
by Maurice Lombardi 17 Jun '99

17 Jun '99

This answer should be directed to the gpc list -- 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

Re: Re: GPC BUG: Initializer for tagged variant records does not work
by pdietrich＠synstar.de 17 Jun '99

17 Jun '99

Hello Peter, the initializer syntax in my example is compatible with the old DEC VMS Pascal style. They have implemented the standard now, which is record-type[field-name:value,...]. I've seen this syntax in parse.y but it seems to be disabled. I can live with either style, because I have written a DEC Pascal to GNU Pascal translator. I just need a working initialization feature. Peter Dietrich Peter Gerwinski <peter(a)gerwinski.de> am 16.06.99 22:01:05 An: Peter Dietrich/SYNSTAR/DE, gpc(a)gnu.de Kopie: Thema: Re: GPC BUG: Initializer for tagged variant records does not work Hallo, Peter! > I found the following bug in the Beta version of GPC. Thanks for the detailed bug reports. They really help us getting rid of the bugs. > Variant records with tag fields cannot be initialized. The following > program is not accepted by the compiler: > > program test (output); > > type t = record > f1 : integer; > case tag : integer of > 0: (i : integer); > 1: (r : real); > end; > > var r : t value (1, 1, 3.14); Is this syntax compatible to any other compiler, or are we free to define this? Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75 *** Vote against SPAM! ********* http://www.politik-digital.de/spam/ ***

1 0

Re: GPC BUG: Initializer for tagged variant records does not work
by richard.kerry＠quantel.com 17 Jun '99

17 Jun '99

Oregon Pascal doesn't have initializers as such, but it does have structured constants. The syntax for assigning structured constants would be : type t = record f1 : integer; case tag : integer of 0: (i : integer); 1: (r : real); end; var r_int, r_real : t; begin r_int := (1, 0, (42)); r_real := (1, 1, (3.14)); end. Ie. The variant part looks like another record nested within the main one and the tag appears as a normal field. Helpfully, Richard. PS. type t = record f1 : integer; case 0 .. 1 of 0: (i : integer); 1: (r : real); end; Would also work using the same assignment syntax, and saves space in the record as there's no actual tag field.

1 0

GPC BUG: Enum type not accepted as conformant array bounds
by pdietrich＠synstar.de 16 Jun '99

16 Jun '99

Hello, I found the following bug in the Beta version of GPC. Best regards, Peter Dietrich -------------------- GPC-Version (gpc -v): Reading specs from C:\usr\local\lib\gcc-lib\i386-mingw32\2.8.1\specs gpc version 19990118, based on gcc-2.8.1 System-Version: Windows NT 4.0 on i386 Problem description: GPC does not accept conformant array bounds of enum types. The following program results in the compiler error message: test1.pas: In function `program_Test': test1.pas:13: incompatible type for argument 1 of `P' test1.pas:13: incompatible type for argument 2 of `P' program test (output); type t = (red,green,blue); procedure p (a : array[lb..ub:t] of char); begin end; var a : array[t] of char; begin p (a); end.

2 1

Re: Huffman compression comes to GPC!
by Frank Heckenbach 16 Jun '99

16 Jun '99

"Dr A A Olowofoyeku" wrote: > Indeed, the problem was with WdBuf. I have now added the endian > conversion stuff, and I have tested it on mingw32 and Solaris. The data > files are now compatible. Thanks. > > There is a new version of the ZIP file on agnes (lhsix110.zip). Works fine. > BTW: some of your endian conversion functions declare a local variable > called "Result". "Result" is predefined in all functions under Delphi > and Virtual Pascal, and so the code breaks under those platforms. It > is only a small matter, but you might want to address it now rather > than later, if the code is supposed to be used by Delphi as well as BP > people. Well, GPC predefines `Result', and still lets you redefine it. :-) Anyway, I've changed the identifiers now. Thanks for pointing it out. Frank -- Frank Heckenbach, frank(a)fjf.gnu.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

GPC BUG: Enum variable cannot be used in set iteration for loop
by pdietrich＠synstar.de 16 Jun '99

16 Jun '99

Hello, I found the following bug in the Beta version of GPC. Best regards, Peter Dietrich -------------------- GPC-Version (gpc -v): Reading specs from C:\usr\local\lib\gcc-lib\i386-mingw32\2.8.1\specs gpc version 19990118, based on gcc-2.8.1 System-Version: Windows NT 4.0 on i386 Problem description: A variable of enum type cannot be used in a "for var in" statement. The following program results in compiler error message: test2.pas: In function `program_Test': test2.pas:7: incompatible types in assignment program test (output); type t = (red,green,blue); var e : t; begin for e in [red,green] do writeln (integer(e)); end.

2 1

question on generate stabs for type definition
by Richard Sharman 16 Jun '99

16 Jun '99

This is using gpc version 19990118, based on gcc-2.8.1, on a sun. I am wondering why for a type definition "1..10" get 2 type numbers (39 and 40) defined in the stabs file. When I run gpc -g -S demo.pas on this file ------------------------------------------------------------------------ program demo(input, output) ; type small = 1 .. 10 ; var a : small ; begin a := 2 ; end . ------------------------------------------------------------------------ demo.s contains this definition of Small: .stabs "Small:t(0,39)=(0,40)=r(0,1);1;10;",128,0,3,0 Why the spurous (0,40) defintion? Why not .stabs "Small:t(0,39)=r(0,1);1;10;",128,0,3,0 Can anyone shed some light on this please? It seems to be causing gdb (as well as me) some confusion. Thanks. Richard

2 1

bug in Make-lang.in causes install error
by Jim O'Dell 16 Jun '99

16 Jun '99

Hello, I'm not a regular subscriber to this list. I'm just following the suggestion in the README. Please excuse me if this bug has already been hashed to death. I ran into a problem installing GPC(gpc-19990118) after the compile. I am running Solaris 2.7 (sparc) with gcc 2.8.1. I copied the "p" directory to the gcc-2.8.1 source directory. Installed the patches. Compiled C/C++/GPC without a problem. The problem started when I tried to "make install". Particularly, in the "pascal.install-info" section. Anyway, I tracked it down to a problem in the "Make-lang.in" file. Basicly, in the "Make-lang.in", whenever you had a "cd" before a call to ($INSTALL_DATA) the Makefile couldn't find "./install.sh -c". Also, I had to remove the "$$f" (files) from the Target-Dir option to "install.sh" I hope this helps, __Jim O'Dell Here's the Make-lang.in I used to install GPC ********************************************************************** # -*- mode: makefile-mode -*- # Top level makefile fragment for GNU Pascal. # Copyright (C) 1994, 1995 Free Software Foundation, Inc. #This file is part of GNU Pascal. #GNU Pascal is free software; you can redistribute it and/or modify #it under the terms of the GNU General Public License as published by #the Free Software Foundation; either version 2, or (at your option) #any later version. #GNU Pascal is distributed in the hope that it will be useful, #but WITHOUT ANY WARRANTY; without even the implied warranty of #MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the #GNU General Public License for more details. #You should have received a copy of the GNU General Public License #along with GNU Pascal; see the file COPYING. If not, write to #the Free Software Foundation, 59 Temple Place - Suite 330, #Boston, MA 02111-1307, USA. # This file provides the language dependent support in the main Makefile. # Each language makefile fragment must provide the following targets: # # foo.all.build, foo.all.cross, foo.start.encap, foo.rest.encap, # foo.info, foo.dvi, # foo.install-normal, foo.install-common, foo.install-info, foo.install-man, # foo.uninstall, foo.distdir, # foo.mostlyclean, foo.clean, foo.distclean, foo.extraclean, # foo.maintainer-clean, foo.stage1, foo.stage2, foo.stage3, foo.stage4 # # where `foo' is the name of the language. # # It should also provide rules for: # # - making any compiler driver (eg: gpc) # - the compiler proper (eg: gpc1) # - define the names for selecting the language in LANGUAGES. # Can be overwritten for DJGPP host HARDLINK=ln # Where to install the demos (relative to the prefix) DEMO_DIR=doc/gpc/demos demodir=$(prefix)/$(DEMO_DIR) # Analogous to objext interfaceext=.gpi # Version numbers gpc_major=2 gpc_minor=0 gpc_release=19990118 gpc_version=$(gpc_release) rts_version=$(gpc_release) # Extra flags to pass to recursive makes. GPC_FLAGS_TO_PASS = \ "CROSS=$(CROSS)" \ "X_CFLAGS=$(X_CFLAGS)" \ "GPC_EGCS_FLAG=$(GPC_EGCS_FLAG)" \ "EXTRA_LIBS=$(EXTRA_LIBS)" \ "MAYBE_TARGET_DEFAULT=$(MAYBE_TARGET_DEFAULT)" \ "MAYBE_USE_COLLECT2=$(MAYBE_USE_COLLECT2)" \ "SCHED_CFLAGS=$(SCHED_CFLAGS)" \ "includedir=`echo '$(includedir)'|sed -e 's/\\$$/\\\\&&/g'`" \ "libsubdir=`echo '$(libsubdir)'|sed -e 's/\\$$/\\\\&&/g'`" \ "target_alias=$(target_alias)" \ "gpc_version=$(gpc_version)" \ "rts_version=$(rts_version)" \ "version=$(version)" # "LIBS=`echo \"$(LIBS)\"|sed -e 's,\.\./libiberty/libiberty\.a,../../libiberty/libiberty.a,g' -e 's,obstack.o,../obstack.o,g'`" \ # Extra flags to pass when building the RTS. RTS_FLAGS_TO_PASS = \ CROSS="$(CROSS)" \ AR_FLAGS="$(AR_FLAGS)" \ AR_FOR_TARGET="$(AR_FOR_TARGET)" \ BISON="$(BISON)" \ BISONFLAGS="$(BISONFLAGS)" \ CFLAGS="$(CFLAGS)" \ X_CFLAGS="$(X_CFLAGS)" \ LDFLAGS="$(LDFLAGS)" \ RANLIB="$(RANLIB)" \ RANLIB_TEST="$(RANLIB_TEST)" \ RANLIB_FOR_TARGET="$(RANLIB_FOR_TARGET)" \ RANLIB_TEST_FOR_TARGET="$(RANLIB_TEST_FOR_TARGET)" \ SHELL="$(SHELL)" # Actual names to use when installing a native compiler. GPC_INSTALL_NAME = `t='$(program_transform_name)'; echo gpc | sed $$t` # Additional driver aliases. PC_INSTALL_NAME = `t='$(program_transform_name)'; echo pc | sed $$t` EPC_INSTALL_NAME = `t='$(program_transform_name)'; echo epc | sed $$t` BPC_INSTALL_NAME = `t='$(program_transform_name)'; echo bpc | sed $$t` # Actual names to use when installing a cross-compiler. GPC_CROSS_NAME = `t='$(program_transform_cross_name)'; echo gpc | sed $$t` # Additional cross driver aliases. PC_CROSS_NAME = `t='$(program_transform_cross_name)'; echo pc | sed $$t` EPC_CROSS_NAME = `t='$(program_transform_cross_name)'; echo epc | sed $$t` BPC_CROSS_NAME = `t='$(program_transform_cross_name)'; echo bpc | sed $$t` # The GPC to use for compiling libgpc.a # Usually the one we just built. GPC_FOR_TARGET = ./xgpc -B./ # Define the names for selecting Pascal in LANGUAGES. Pascal pascal: xgpc$(exeext) gpc1$(exeext) gpc-cpp$(exeext) pascal.rts specs # Tell GNU make to ignore these if they exist. .PHONY: Pascal pascal GPC_SRCS = \ $(srcdir)/c-aux-info.c \ $(srcdir)/c-iterate.c \ $(srcdir)/c-pragma.c \ $(srcdir)/convert.c \ $(srcdir)/dbxout.c \ $(srcdir)/expr.c \ $(srcdir)/fold-const.c \ $(srcdir)/function.c \ $(srcdir)/optabs.c \ $(srcdir)/stor-layout.c \ $(srcdir)/toplev.c \ $(srcdir)/tree.c \ $(srcdir)/p/assert_.h \ $(srcdir)/p/circle-buf.c \ $(srcdir)/p/circle-buf.h \ $(srcdir)/p/gbe.h \ $(srcdir)/p/gpc-common.c \ $(srcdir)/p/gpc-convert.c \ $(srcdir)/p/gpc-decl.c \ $(srcdir)/p/gpc-defs.h \ $(srcdir)/p/gpc-lang.c \ $(srcdir)/p/gpc-lang.h \ $(srcdir)/p/gpc-lex.c \ $(srcdir)/p/gpc-typeck.c \ $(srcdir)/p/gpi-hash.c \ $(srcdir)/p/gpi-hash.h \ $(srcdir)/p/lang-options.h \ $(srcdir)/p/lang-specs.h \ $(srcdir)/p/mkstemp.c \ $(srcdir)/p/module.c \ $(srcdir)/p/module.h \ $(srcdir)/p/objects.c \ $(srcdir)/p/objects.h \ $(srcdir)/p/parse.y \ $(srcdir)/p/setop.c \ $(srcdir)/p/setop.h \ $(srcdir)/p/rts.c \ $(srcdir)/p/rts.h \ $(srcdir)/p/types.c \ $(srcdir)/p/types.h \ $(srcdir)/p/util.c \ $(srcdir)/p/util.h \ $(srcdir)/p/version.c GPC_TEXI = $(srcdir)/p/doc/gpc.texi \ $(srcdir)/p/doc/copying.texi \ $(srcdir)/p/doc/funding.texi \ $(srcdir)/p/doc/lookfeel.texi \ $(srcdir)/p/doc/gnu.texi \ $(srcdir)/p/doc/contributors.texi \ $(srcdir)/p/doc/welcome.texi \ $(srcdir)/p/doc/install.texi \ $(srcdir)/p/doc/invoke.texi \ $(srcdir)/p/doc/programming.texi \ $(srcdir)/p/doc/reference.texi \ $(srcdir)/p/doc/keywords.texi \ $(srcdir)/p/doc/builtin.texi \ $(srcdir)/p/doc/extend.texi \ $(srcdir)/p/doc/borland2ep.texi \ $(srcdir)/p/doc/bpqstart.texi \ $(srcdir)/p/doc/bugs.texi \ $(srcdir)/p/doc/support.texi \ $(srcdir)/p/doc/how-to-contrib.texi \ $(srcdir)/p/doc/gpc-source.texi \ $(srcdir)/p/doc/notes.texi \ $(srcdir)/p/doc/pvs.texi \ $(srcdir)/p/doc/sets.texi p/gpc.o: $(srcdir)/p/gpc.c $(CONFIG_H) gansidecl.h multilib.h Makefile $(lang_specs_files) $(CC) -DGPC $(GPC_EGCS_FLAG) $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \ -DGPC_MAJOR="\"$(gpc_major)\"" \ -DGPC_MINOR="\"$(gpc_minor)\"" \ -DGPC_RELEASE="\"$(gpc_release)\"" \ $(DRIVER_DEFINES) \ -c `echo $(srcdir)/p/gpc.c | sed 's,^\./,,'` -o $@ p/gpc_date: date '+%h %e %Y' > $@ p/gpc_time: date '+%H:%M:%S' > $@ p/version.o: p/gpc_date p/gpc_time $(srcdir)/p/version.c config.status $(CC) -DGPC $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \ -DGPC_TIME="\"`cat p/gpc_time`\"" \ -DGPC_DATE="\"`cat p/gpc_date`\"" \ -DGCC_VERSION="\"$(version)\"" \ -DGPC_VERSION="\"$(gpc_version)\"" \ -c `echo $(srcdir)/p/version.c | sed 's,^\./,,'` -o $@ p/mkstemp.o: p/mkstemp.c $(CC) -DGPC $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) -c $< -o $@ # We call this executable `xgpc' rather than `gpc' # to avoid confusion if the current directory is in the path # and PC is `gpc'. It is renamed to `gpc' when it is installed. xgpc$(exeext): p/gpc.o version.o choose-temp.o pexecute.o prefix.o p/version.o \ p/mkstemp.o $(LIBDEPS) $(EXTRA_GCC_OBJS) $(CC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ p/gpc.o prefix.o p/version.o \ choose-temp.o pexecute.o p/mkstemp.o $(EXTRA_GCC_OBJS) $(LIBS) $(EXTRA_LIBS) # Also create gpc-cross, so that pascal.install-common will install properly. gpc-cross$(exeext): xgpc$(exeext) cp xgpc$(exeext) gpc-cross$(exeext) gpc1$(exeext): $(P) $(GPC_SRCS) $(LIBDEPS) stamp-objlist c-aux-info.o \ c-iterate.o c-pragma.o choose-temp.o pexecute.o p/mkstemp.o p/version.c cd p; $(MAKE) $(FLAGS_TO_PASS) $(GPC_FLAGS_TO_PASS) ../gpc1$(exeext) gpc-cpp$(exeext): $(P) mbchar.o cexp.o $(srcdir)/p/gpc-cccp.c $(srcdir)/p/version.c cd p; $(MAKE) $(FLAGS_TO_PASS) $(GPC_FLAGS_TO_PASS) ../gpc-cpp$(exeext) pascal.rts: p/rts/Makefile case "$(LANGUAGES)" in \ *pascal*) cd p/rts && $(MAKE) \ GCC_FOR_TARGET="`case '$(GCC_FOR_TARGET)' in \ './xgcc -B./'*) echo ../../xgcc -B../../;; \ *) echo '$(GCC_FOR_TARGET)';; esac`" \ GPC_FOR_TARGET="`case '$(GPC_FOR_TARGET)' in \ './xgpc -B./'*) echo ../../xgpc -B../../;; \ *) echo '$(GPC_FOR_TARGET)';; esac`" \ GCC_FLAGS="$(GCC_FLAGS)" $(RTS_FLAGS_TO_PASS) \ all ;; \ esac # The configuration of the runtime system relies on an autoconf-type # configure, not a Cygnus-type one. It needs to be run *after* the # appropriate (cross-)compiler has been built, thus depend on GCC_PARTS. # `stmp-headers' ensures that float.h has been built. # dj: Depending on $(GCC_PARTS) here is bad news - very bad news. # mk: but it needs $(EXTRA_OBJS) and $(LIBGCC), what to do? p/rts/Makefile: $(srcdir)/p/rts/Makefile.in $(srcdir)/p/rts/configure \ $(GCC_PARTS) stmp-headers if [ -d p/rts ]; then true; else mkdir p/rts; fi src=`cd $(srcdir); pwd`; \ cd p/rts; \ CC="`case '$(GCC_FOR_TARGET)' in \ './xgcc -B./'*) echo ../../xgcc -B../../;; \ *) echo '$(GCC_FOR_TARGET)';; esac`" \ PC="`case '$(GPC_FOR_TARGET)' in \ './xgpc -B./'*) echo ../../xgpc -B../../;; \ *) echo '$(GPC_FOR_TARGET)';; esac`" \ $(RTS_FLAGS_TO_PASS) CONFIG_SITE=nonexisting-file $(SHELL) \ $${src}/p/rts/configure --srcdir=$${src}/p/rts # Derive parts of the documentation of the run time library directly # from the source. p/doc/gpcpas.texi: $(srcdir)/p/rts/gpc.pas if [ -d p/doc ]; then true; else mkdir p/doc; fi sed -e 's/[@{}]/@&/g' < $(srcdir)/p/rts/gpc.pas > p/doc/gpcpas.texi # Build hooks: pascal.all.build: xgpc$(exeext) pascal.all.cross: gpc-cross$(exeext) pascal.start.encap: pascal.rest.encap: pascal.info: p/doc/gpc.info pascal.dvi: p/doc/gpc.dvi p/doc/gpc.info: $(GPC_TEXI) p/doc/gpcpas.texi if [ -d p/doc ]; then true; else mkdir p/doc; fi src=`cd $(srcdir); pwd`; \ cd p/doc; $(MAKEINFO) -I$${src}/p/doc -o gpc.info $${src}/p/doc/gpc.texi p/doc/gpc.dvi: $(GPC_TEXI) p/doc/gpcpas.texi if [ -d p/doc ]; then true; else mkdir p/doc; fi $(TEXI2DVI) -I$(srcdir)/p -o p/doc/gpc.dvi $(srcdir)/p/doc/gpc.texi $(srcdir)/p/INSTALL: $(srcdir)/p/doc/install.texi cd $(srcdir)/p; $(MAKEINFO) -DINSTALLONLY --no-header \ --no-split doc/install.texi -o INSTALL # Install hooks: # gpc1 is installed elsewhere as part of $(COMPILERS). unitsubdir=$(libsubdir)/units pascal.install-normal: install-gpc-cpp install-libgpc pascal.install-units pascal.install-demos install-gpc-cpp: gpc-cpp$(exeext) -rm -f $(libsubdir)/gpc-cpp$(exeext) $(INSTALL_PROGRAM) gpc-cpp$(exeext) $(libsubdir)/gpc-cpp$(exeext) install-libgpc: pascal.install-dir pascal.rts -if [ -f libgpc.a ] ; then \ rm -f $(libsubdir)/libgpc.a; \ $(INSTALL_DATA) libgpc.a $(libsubdir)/libgpc.a; \ if $(RANLIB_TEST_FOR_TARGET) ; then \ (cd $(libsubdir); $(RANLIB_FOR_TARGET) libgpc.a); else true; fi; \ chmod a-x $(libsubdir)/libgpc.a; \ else true; fi $(srcdir)/p/units/crtc.h: $(srcdir)/p/units/crt.inc (echo '/* Automatically generated from crt.inc'; \ echo ' DO NOT CHANGE THIS FILE MANUALLY! */'; \ sed -e '1,/^const/d;s/^$[^=]*$= #\?$[^;]*$;$.*;$\?$$/#define \1 \2/' \ -e '/^.\$$/d' < $(srcdir)/p/units/crt.inc) > $(srcdir)/p/units//crtc.h pascal.install-units: pascal.install-dir $(srcdir)/p/units/crtc.h $(INSTALL_DATA) $(srcdir)/p/rts/gpc.pas $(unitsubdir)/gpc.pas; \ chmod a-x $(unitsubdir)/gpc.pas; \ $(INSTALL_DATA) $(srcdir)/p/rts/internal.pas $(unitsubdir)/internal.pas; \ chmod a-x $(unitsubdir)/internal.pas; \ $(INSTALL_DATA) $(srcdir)/p/rts/getopt.h $(unitsubdir)/getopt.h; \ chmod a-x $(unitsubdir)/getopt.h; \ $(INSTALL_DATA) $(srcdir)/p/rts/pexecute.h $(unitsubdir)/pexecute.h; \ chmod a-x $(unitsubdir)/pexecute.h; \ cd $(srcdir)/p/units; \ for file in *.pas *.inc *.c *.h; do \ ../../$(INSTALL_DATA) $$file $(unitsubdir); \ chmod a-x $(unitsubdir)/$$file; \ done pascal.install-demos: pascal.install-dir cd $(srcdir)/p/demos; \ for file in *; do \ ../../$(INSTALL_DATA) $$file $(demodir); \ chmod a-x $(demodir)/$$file; \ done # Install the driver program as $(target)-gpc # and also as either gpc (if native) or $(tooldir)/bin/gpc. pascal.install-common: -if [ -f gpc1$(exeext) ] ; then \ if [ -f gpc-cross$(exeext) ] ; then \ rm -f $(bindir)/$(GPC_CROSS_NAME)$(exeext); \ $(INSTALL_PROGRAM) gpc-cross$(exeext) $(bindir)/$(GPC_CROSS_NAME)$(exeext); \ chmod a+x $(bindir)/$(GPC_CROSS_NAME)$(exeext); \ rm -f $(bindir)/$(PC_CROSS_NAME)$(exeext); \ $(HARDLINK) $(bindir)/$(GPC_CROSS_NAME)$(exeext) $(bindir)/$(PC_CROSS_NAME)$(exeext) \ > /dev/null 2>&1 \ || cp $(bindir)/$(GPC_CROSS_NAME)$(exeext) $(bindir)/$(PC_CROSS_NAME)$(exeext) ; \ rm -f $(bindir)/$(EPC_CROSS_NAME)$(exeext); \ $(HARDLINK) $(bindir)/$(GPC_CROSS_NAME)$(exeext) $(bindir)/$(EPC_CROSS_NAME)$(exeext) \ > /dev/null 2>&1 \ || cp $(bindir)/$(GPC_CROSS_NAME)$(exeext) $(bindir)/$(EPC_CROSS_NAME)$(exeext) ; \ rm -f $(bindir)/$(BPC_CROSS_NAME)$(exeext); \ $(HARDLINK) $(bindir)/$(GPC_CROSS_NAME)$(exeext) $(bindir)/$(BPC_CROSS_NAME)$(exeext) \ > /dev/null 2>&1 \ || cp $(bindir)/$(GPC_CROSS_NAME)$(exeext) $(bindir)/$(BPC_CROSS_NAME)$(exeext) ; \ else \ rm -f $(bindir)/$(GPC_INSTALL_NAME)$(exeext); \ $(INSTALL_PROGRAM) xgpc$(exeext) $(bindir)/$(GPC_INSTALL_NAME)$(exeext); \ chmod a+x $(bindir)/$(GPC_INSTALL_NAME)$(exeext); \ rm -f $(bindir)/$(PC_INSTALL_NAME)$(exeext); \ $(HARDLINK) $(bindir)/$(GPC_INSTALL_NAME)$(exeext) $(bindir)/$(PC_INSTALL_NAME)$(exeext) \ > /dev/null 2>&1 \ || cp $(bindir)/$(GPC_INSTALL_NAME)$(exeext) $(bindir)/$(PC_INSTALL_NAME)$(exeext) ; \ rm -f $(bindir)/$(EPC_INSTALL_NAME)$(exeext); \ $(HARDLINK) $(bindir)/$(GPC_INSTALL_NAME)$(exeext) $(bindir)/$(EPC_INSTALL_NAME)$(exeext) \ > /dev/null 2>&1 \ || cp $(bindir)/$(GPC_INSTALL_NAME)$(exeext) $(bindir)/$(EPC_INSTALL_NAME)$(exeext) ; \ rm -f $(bindir)/$(BPC_INSTALL_NAME)$(exeext); \ $(HARDLINK) $(bindir)/$(GPC_INSTALL_NAME)$(exeext) $(bindir)/$(BPC_INSTALL_NAME)$(exeext) \ > /dev/null 2>&1 \ || cp $(bindir)/$(GPC_INSTALL_NAME)$(exeext) $(bindir)/$(BPC_INSTALL_NAME)$(exeext) ; \ fi ; \ fi pascal.install-info: pascal.info -rm -f $(infodir)/gpc.info* ; if [ -f p/doc/gpc.info ]; then \ cd p/doc; \ else \ cd $(srcdir)/p/doc; \ fi; \ for f in gpc.info*; do \ ../../$(INSTALL_DATA) $$f $(infodir); \ done -chmod a-x $(infodir)/gpc.info* pascal.install-man: $(srcdir)/p/gpc.1 -if [ -f gpc1$(exeext) ] ; then \ if [ -f gpc-cross$(exeext) ] ; then \ rm -f $(mandir)/$(GPC_CROSS_NAME)$(manext); \ $(INSTALL_DATA) $(srcdir)/p/gpc.1 $(mandir)/$(GPC_CROSS_NAME)$(manext); \ chmod a-x $(mandir)/$(GPC_CROSS_NAME)$(manext); \ for f in $(PC_CROSS_NAME) $(EPC_CROSS_NAME) $(BPC_CROSS_NAME); do \ rm -f $(mandir)/$$f$(manext); \ ln -s $(GPC_CROSS_NAME)$(manext) $(mandir)/$$f$(manext); \ done; \ else \ rm -f $(mandir)/$(GPC_INSTALL_NAME)$(manext); \ $(INSTALL_DATA) $(srcdir)/p/gpc.1 $(mandir)/$(GPC_INSTALL_NAME)$(manext); \ chmod a-x $(mandir)/$(GPC_INSTALL_NAME)$(manext); \ for f in $(PC_INSTALL_NAME) $(EPC_INSTALL_NAME) $(BPC_INSTALL_NAME); do \ rm -f $(mandir)/$$f$(manext); \ ln -s $(GPC_INSTALL_NAME)$(manext) $(mandir)/$$f$(manext); \ done; \ fi; \ else true; fi pascal.install-dir: -for directory in $(bindir) $(libsubdir) $(unitsubdir) $(demodir) $(infodir) $(mandir); do \ if [ -d $$directory ]; then \ true; \ else \ mkdir -p $$directory; \ fi; \ done # Install gpc1 et.al. # Do *not* overwrite files if they exist. pascal.install-compiler: pascal for file in gpc1$(exeext); do \ if [ -f $$file ] ; then \ rm -f $(libsubdir)/$$file; \ $(INSTALL_PROGRAM) $$file $(libsubdir)/$$file; \ else true; \ fi; \ done for file in $(EXTRA_PASSES) $(EXTRA_PROGRAMS) $(USE_COLLECT2) ..; do \ if [ x"$$file" != x.. ]; then \ if ! [ -f $(libsubdir)/$$file ]; then \ $(INSTALL_PROGRAM) $$file $(libsubdir)/$$file; else true; fi; \ else true; fi; \ done for file in $(EXTRA_PARTS) ..; do \ if [ x"$$file" != x.. ]; then \ if ! [ -f $(libsubdir)/$$file ]; then \ $(INSTALL_DATA) $$file $(libsubdir); else true; fi; \ else true; fi; \ done # Don't mess with specs if it doesn't exist yet. -if [ -f specs ] ; then \ if ! [ -f $(libsubdir)/specs ]; then \ $(INSTALL_DATA) specs $(libsubdir)/specs; fi; \ fi # Install libgcc.a FIXME: doesn't handle multilib (multiple libgcc.a) -if [ -f libgcc.a ] ; then \ if ! [ -f $(libsubdir)/libgcc.a ]; then \ $(INSTALL_DATA) libgcc.a $(libsubdir)/libgcc.a; \ if $(RANLIB_TEST_FOR_TARGET) ; then \ (cd $(libsubdir); $(RANLIB_FOR_TARGET) libgcc.a); else true; fi; \ chmod a-x $(libsubdir)/libgcc.a; fi; \ else true; fi # This target will install GPC into an existing GCC installation, # without overwriting existing files. # The semicolon is to prevent the install.sh -> install default rule # from doing anything. Having it run true helps avoid problems and # noise from versions of make which don't like to have null commands. pascal.install: pascal.install-dir pascal.install-compiler pascal.install-common \ pascal.install-normal pascal.install-info pascal.install-man ; @true pascal.uninstall: -rm -rf $(bindir)/$(GPC_INSTALL_NAME)$(exeext) -rm -rf $(bindir)/$(GPC_CROSS_NAME)$(exeext) -rm -rf $(bindir)/$(PC_INSTALL_NAME)$(exeext) -rm -rf $(bindir)/$(PC_CROSS_NAME)$(exeext) -rm -rf $(bindir)/$(EPC_INSTALL_NAME)$(exeext) -rm -rf $(bindir)/$(EPC_CROSS_NAME)$(exeext) -rm -rf $(bindir)/$(BPC_INSTALL_NAME)$(exeext) -rm -rf $(bindir)/$(BPC_CROSS_NAME)$(exeext) -rm -rf $(mandir)/$(GPC_INSTALL_NAME)$(manext) -rm -rf $(mandir)/$(GPC_CROSS_NAME)$(manext) pascal.bindist: pascal tmp_base=`pwd`/tmp ; \ tmp_prefix=$${tmp_base}/$(prefix) ; \ if [ -d "$${tmp_prefix}" ]; \ then true; \ else mkdir -p "$${tmp_prefix}"; \ fi; \ $(MAKE) pascal.install prefix=$${tmp_prefix} exeext=$(exeext) HARDLINK=$(HARDLINK) && \ cd $${tmp_base} && tar cvzf ../gpc-$(gpc_version).$(target).tar.gz * && \ rm -rf $${tmp_base} # Clean hooks: # A lot of the ancillary files are deleted by the main makefile. # We just have to delete files specific to us. pascal.mostlyclean: -rm -f p/*$(objext) -cd p/rts; $(MAKE) -f ../../$(srcdir)/p/rts/Makefile.in mostlyclean pascal.clean: -rm -f xgpc -cd p/rts; $(MAKE) -f ../../$(srcdir)/p/rts/Makefile.in clean -if [ -d p/test ]; then cd p/test; $(MAKE) clean; fi pascal.distclean: -cd p/rts; $(MAKE) -f ../../$(srcdir)/p/rts/Makefile.in distclean -if [ -d p/test ]; then cd p/test; $(MAKE) clean; fi -rm -f p/Makefile p/gpc-config.h p/site.exp p/site.bak units/crtc.h -rm -f p/config.cache p/config.log p/config.status -rm -f p/testsuite/gpc.log p/testsuite/gpc.sum -rm -f p/parse.output -rm -f p/gpc_date p/gpc_time -rm -f gcc-version.h # like gcc's extraclean, which does clean p/ for us, but not p/rts. pascal.extraclean: -if [ -d p/test ]; then cd p/test; $(MAKE) clean; fi -if [ -d p/test/knownbugs ]; then -cd p/test/knownbugs; $(MAKE) -f ../Makefile clean; fi -rm -f p/*/=* p/*/"#"* p/*/*~* -rm -f p/*/patch* p/*/*.orig p/*/*.rej -rm -f p/*/*.dvi p/*/*.oaux p/*/*.d p/*/*.[zZ] p/*/*.gz -rm -f p/*/*.tar p/*/*.xtar p/*/*.tar.* p/*/*.xtar.* -rm -f p/*/*lose p/*/*.s p/*/*.s[0-9] p/*/*.i pascal.maintainer-clean: -cd p/rts; $(MAKE) -f ../../$(srcdir)/p/rts/Makefile.in maintainer-clean -if [ -d p/test ]; then cd p/test; $(MAKE) clean; fi -rm -f p/doc/gpc.info* p/gpc.*aux p/TAGS p/INSTALL p/NEWS -rm -f p/parse.c p/parse.h # Stage hooks: # The main makefile has already created stage?/p. GPCSTAGESTUFF = p/*$(objext) p/stamp-gbe p/stamp-gpc1 RTSSTAGESTUFF = p/rts/*$(objext) p/rts/*$(interfaceext) p/rts/config.cache p/rts/config.log \ p/rts/config.status p/rts/Makefile p/rts/rts-config.h UNITSSTAGESTUFF = p/units/*$(objext) p/units/*$(interfaceext) pascal.stage1: -if [ -d stage1/p/rts ] ; then true ; else mkdir stage1/p/rts ; fi -if [ -d stage1/p/units ] ; then true ; else mkdir stage1/p/units ; fi -mv $(GPCSTAGESTUFF) stage1/p -mv $(RTSSTAGESTUFF) stage1/p/rts -mv $(UNITSSTAGESTUFF) stage1/p/units pascal.stage2: -if [ -d stage2/p/rts ] ; then true ; else mkdir stage2/p/rts ; fi -if [ -d stage2/p/units ] ; then true ; else mkdir stage2/p/units ; fi -mv $(GPCSTAGESTUFF) stage2/p -mv $(RTSSTAGESTUFF) stage2/p/rts -mv $(UNITSSTAGESTUFF) stage2/p/units pascal.stage3: -if [ -d stage3/p/rts ] ; then true ; else mkdir stage3/p/rts ; fi -if [ -d stage3/p/units ] ; then true ; else mkdir stage3/p/units ; fi -mv $(GPCSTAGESTUFF) stage3/p -mv $(RTSSTAGESTUFF) stage3/p/rts -mv $(UNITSSTAGESTUFF) stage3/p/units pascal.stage4: -if [ -d stage4/p/rts ] ; then true ; else mkdir stage4/p/rts ; fi -if [ -d stage4/p/units ] ; then true ; else mkdir stage4/p/units ; fi -mv $(GPCSTAGESTUFF) stage4/p -mv $(RTSSTAGESTUFF) stage4/p/rts -mv $(UNITSSTAGESTUFF) stage4/p/units # Maintenance hooks: # This target creates the files that can be rebuilt, but go in the # distribution anyway. It then copies the files to the distdir directory. pascal.distdir: mkdir tmp/p cd p ; $(MAKE) $(FLAGS_TO_PASS) $(GPC_FLAGS_TO_PASS) parse.c hash.h cd p/doc ; $(MAKE) $(FLAGS_TO_PASS) $(GPC_FLAGS_TO_PASS) info cd p; \ for file in *[0-9a-zA-Z+]; do \ ln $$file ../tmp/p >/dev/null 2>&1 || p $$file ../tmp/p; \ done

2 1

New GPC snapshot
by Peter Gerwinski 16 Jun '99

16 Jun '99

Hello, folks, a new GPC snapshot is available: ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/gpc-19990607.tar.gz Source only. Nothing guaranteed. Have fun, Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75 *** Vote against SPAM! ********* http://www.politik-digital.de/spam/ ***

2 2

GPC BUG: FExpand does not always expand .. correctly
by pdietrich＠synstar.de 15 Jun '99

15 Jun '99

Hello, I found the following bug in the Beta version of GPC. Best regards, Peter Dietrich -------------------- GPC-Version (gpc -v): Reading specs from C:\usr\local\lib\gcc-lib\i386-mingw32\2.8.1\specs gpc version 19990118, based on gcc-2.8.1 System-Version: Windows NT 4.0 on i386 Problem description: The following program shows that FExpand does not reliably expand pathnames containing ..: program test (output); uses GPC; begin writeln ('Current working directory: ', GetCurrentDirectory); writeln ('Expanding ..\sort : ', FExpand ('..\sort')); end. The program output: F:\PROJECTS\ISIDATA\isidef>gpc --automake test4.pas F:\PROJECTS\ISIDATA\isidef>a.exe Current working directory: F:\PROJECTS\ISIDATA\isidef Expanding ..\sort : F:\PROJECTS\ISIDATA\sort F:\PROJECTS\ISIDATA\isidef>cd ..\uvw F:\PROJECTS\ISIDATA\uvw>..\isidef\a.exe Current working directory: F:\PROJECTS\ISIDATA\uvw Expanding ..\sort : F:\sort F:\PROJECTS\ISIDATA\uvw>cd ..\lib F:\PROJECTS\ISIDATA\lib>..\isidef\a.exe Current working directory: F:\PROJECTS\ISIDATA\lib Expanding ..\sort : F:\sort F:\PROJECTS\ISIDATA\lib>cd ..\uvw_in F:\PROJECTS\ISIDATA\uvw_in>..\isidef\a.exe Current working directory: F:\PROJECTS\ISIDATA\uvw_in Expanding ..\sort : F:\PROJECTS\ISIDATA\sort The output of dir ..: F:\PROJECTS\ISIDATA\uvw_in>dir .. Datenträger in Laufwerk F: ist NT4 Datenträgernummer: 2586-5521 Verzeichnis von F:\PROJECTS\ISIDATA 18.05.99 14:20 <DIR> . 18.05.99 14:20 <DIR> .. 18.05.99 14:20 <DIR> isicom 18.05.99 14:20 <DIR> isidef 18.05.99 14:21 <DIR> lib 18.05.99 14:21 <DIR> ppp 18.05.99 14:21 <DIR> save 18.05.99 14:21 <DIR> sort 18.05.99 14:21 <DIR> ssv 18.05.99 14:21 <DIR> uvw 18.05.99 14:21 <DIR> uvw_env 18.05.99 14:21 <DIR> uvw_in 18.05.99 14:21 <DIR> uvw_out 18.05.99 14:21 <DIR> uvw_test 18.05.99 14:30 <DIR> gpc

1 0

help Newbi...`Gpc' could not be imported
by Oliver George 14 Jun '99

14 Jun '99

Hi, I installed gpc-19990118-1.i386-pc-linux-gnu.rpm and gpc-extras-19990118-1.i386-pc-linux-gnu.rpm and even recompiled from gpc-19990118-1.src.rpm and I am having the same troubles. Compiling a hello world works fine (only uses writeln) but compiler can't find GPC library... an example ------------ > gpc demoproc.pas demoproc.pas:25: module/unit interface `Gpc' could not be imported ------------ any suggestions, thanks Oliver.

2 1

Re: Huffman compression comes to GPC!
by Frank Heckenbach 13 Jun '99

13 Jun '99

"Dr A A Olowofoyeku" wrote: > I have just completed work on an Huffman compression unit which now > supports GPC. The unit exports two main (alternative) compression > functions and two decompression functions. The routines are "dead easy" > to use, and the compression ratio compares well with ZIP's "deflate". > > The file can be downloaded from the "contrib" directory on agnes: > ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/contrib/lhsix.zip One little comment: the characters you use in EncodeCallBack and DecodeCallBack are probably some graphics characters under Dos, but look a bit strange in the standard character set (a paragraph sign and an accented `u'). To avois this problem, it might be better to use ASCII characters (i.e., #32 .. #126), e.g. the hash (`#') that many programs use. I realise that this is only a demo program, but it gives a strange appearance at first sight... Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

re: snapshot
by Russ Whitaker 12 Jun '99

12 Jun '99

oops: that's ar->/usr/bin/ar

1 0

Huffman compression comes to GPC!
by Dr A A Olowofoyeku 10 Jun '99

10 Jun '99

Hi folks! I have just completed work on an Huffman compression unit which now supports GPC. The unit exports two main (alternative) compression functions and two decompression functions. The routines are "dead easy" to use, and the compression ratio compares well with ZIP's "deflate". I have tried to make the code portable, and I believe that I have achieved this (it works fine with TP, BP, Delphi, FreePascal, and GPC). AFAIK there are no "endian" issues, but I stand corrected. Please report any bugs or portability problems to me. If you can fix any such problems, please send me a copy of the fix, so that I can merge it with the main distribution. The file can be downloaded from the "contrib" directory on agnes: ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/contrib/lhsix.zip The unit deals with the compression of single files. Happy hacking! Best regards, The Chief -------- Dr. Abimbola A. Olowofoyeku (The African Chief) Email: laa12(a)keele.ac.uk Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ Author of: Chief's Installer Pro v5.00 for Win32 ftp://ftp.simtel.net/pub/simtelnet/win95/install/chief500.zip

1 0

new snapshot
by Russ Whitaker 10 Jun '99

10 Jun '99

Hi peter downloaded the snapshot & cleaned out the old files here's the minor bugs ran into: 1. using CFLAGS="O2" the compile crashed in the same place as the previous snapshot: cc1 got fatal signal 6 [maths.o]Error1 while in the RTS subdirectory. compile ok without the CFLAGS 2. make looked for "ar" in wrong place: instead of /usr/bin looked at /usr/i586-pc-linux-gnu/bin/ar so put in a soft link to point to /usr/bin/ar and it worked 3. Didn't include --prefix=/usr/local so the install ended up in /usr/lib instead of /usr/local/lib moved i5* to /usr/local/lib/gcc* 4. either location gpc couldn't find the include files so moved /usr/local/lib/gcc*/i5*/2*/include/* to /usr/local/include and now works fine hope this helps thanks, Russ

1 0

Re: Unité crt.
by Frank Heckenbach 09 Jun '99

09 Jun '99

Olivier PECHEUX wrote: > Dimitri, tu dis :Ã§a marche. Chez Maurice, Ã§a marche. (unitÃ© crt). > > Chez moi, Ã§a ne marche que la premiÃ¨re fois. Ce que j'ai fait: > - j'ai chargÃ© le curse23.zip (indiquÃ© par Maurice). > - j'ai supprimÃ© le specs et le djgpp.djl > - j'ai modifiÃ© le djgpp.env (indiquÃ© par Olivier = moi) > _ j'ai tapÃ© le programme: > > program efface; > uses crt; > begin > clrscr; > readln > end. > > Quand je compile la premiÃ¨re fois, tout se passe bien, et le programme > fonctionne. > Si je compile une deuxiÃ¨me fois, je retrouve le messsage undefined > reference to crt_clrscr. Dans mon rÃ©pertoire de travail, j'ai les > fichiers gpc.o gpc.gpi crt.o crt.gpi et crtc.o . le fichier crtc.o > contient bien la procÃ©dure crt_clrscr (vue par nm -O crtc.o >crtc.lst). > Si je supprime lun des trois fichiers crt.gpi gpc.gpi ou crt.o , la > compilation fonctionne Ã nouveau. I must admit that I don't really speak French, but as far as I can understand, you can compile a program that uses CRT once succesfully, but not twice. Yes, this is a known problem with GPC's `automake' under DJGPP, and it affects all units, not just CRT. We'll try to fix it soon, but until then, you'll probably have to delete crt*.o before each compilation, or use the `--autobuild' switch. Both will force CRT to be recompiled, and then the problem does not appear. > Dans le fichier crtdummy.c (dans units), il est dit: > > - add a statement to #include that file, together with suitable #ifdefs > in crtc.c This statement only refers to those who want to port CRT to a new system (say, mingw). If you just want to use CRT under DJGPP, you don't need to worry about it. > The link to the last djgpp version of gpc in the directory > gnu-pascal/djgpp on agnes is not correct: > instead of > gpc20bb -> ../binary/gpc-19990530-i386-pc-djgppv202.zip > it should be > gpc20bb -> ../beta/binary/gpc-19990530-i386-pc-djgppv202.zip > > Quel est le nom exact complet? Dans > ftp://agnes.dida.physik.uni-essen.de/gnu-pascal je ne vois pas de djgpp. > le gpc20bb.zip que j'ai pris est tirÃ© de : > ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/current/binary/gpc-19990430-i386-pc-djgppv202.zip > . Ai-je pris le mauvais fichier? The `19990530' was a typo. 19990430 is the correct name of the last binary release for DJGPP. > To overwrite such a builtin specs, provide a new one in a rhide.env file > (either > the global one in %DJDIR%/share/rhide/ or a local one in the current > directory). > In you specific task you should place a line like the following: > > RHIDE_COMPILE_LINK_GPC_AUTOMAKE=$(RHIDE_LD_PASCAL) > $(RHIDE_LIBDIRS) -o $(OUTFILE) -automake $(RHIDE_GPC_FLAGS) > $(SOURCE_NAME) $(LIBRARIES) $(LDFLAGS) $(RHIDE_LDFLAGS) $(RHIDE_LIBS) > > (NOTE here, this should be all ONE long line!!!) > > > J'ai effectivement bien la spec indiquÃ©e. Je ne commprends pas bien ce > que je dois faire avec la fameuse ligne. Je l'ai mise seule dans un > fichier rhide.env mis dans les deux rÃ©pertoires indiquÃ©s sans aucun > changements. I'm not sure if I understand you correctly here, but if your problem is that there is no rhide.env file, then just create it in one of the directories mentioned, and put just this one line into it. I just tried it under Linux with the following line (note: the `$(LIBRARIES)' and `$(RHIDE_LIBS)' are also omitted because GPC cares about the libraries itself), and it seemed to work: RHIDE_COMPILE_LINK_PASCAL_AUTOMAKE=$(RHIDE_LD_PASCAL) $(RHIDE_LIBDIRS) $(RHIDE_LDFLAGS) -o $(OUTFILE) --automake $(RHIDE_GPC_FLAGS) $(SOURCE_NAME) $(RHIDE_LDFLAGS) Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 2

Unité crt.
by Olivier PECHEUX 08 Jun '99

08 Jun '99

Dimitri, tu dis :Ã§a marche. Chez Maurice, Ã§a marche. (unitÃ© crt). Chez moi, Ã§a ne marche que la premiÃ¨re fois. Ce que j'ai fait: - j'ai chargÃ© le curse23.zip (indiquÃ© par Maurice). - j'ai supprimÃ© le specs et le djgpp.djl - j'ai modifiÃ© le djgpp.env (indiquÃ© par Olivier = moi) _ j'ai tapÃ© le programme: program efface; uses crt; begin clrscr; readln end. Quand je compile la premiÃ¨re fois, tout se passe bien, et le programme fonctionne. Si je compile une deuxiÃ¨me fois, je retrouve le messsage undefined reference to crt_clrscr. Dans mon rÃ©pertoire de travail, j'ai les fichiers gpc.o gpc.gpi crt.o crt.gpi et crtc.o . le fichier crtc.o contient bien la procÃ©dure crt_clrscr (vue par nm -O crtc.o >crtc.lst). Si je supprime lun des trois fichiers crt.gpi gpc.gpi ou crt.o , la compilation fonctionne Ã nouveau. Une idÃ©e? Merci. ----------------------------------------------------------------------- Dans le fichier crtdummy.c (dans units), il est dit: - add a statement to #include that file, together with suitable #ifdefs in crtc.c Alors la c'est la catastrophe! Qu'avez-vous compris? ------------------------------------------------------------------------ Maurice a Ã©crit: The link to the last djgpp version of gpc in the directory gnu-pascal/djgpp on agnes is not correct: instead of gpc20bb -> ../binary/gpc-19990530-i386-pc-djgppv202.zip it should be gpc20bb -> ../beta/binary/gpc-19990530-i386-pc-djgppv202.zip Quel est le nom exact complet? Dans ftp://agnes.dida.physik.uni-essen.de/gnu-pascal je ne vois pas de djgpp. le gpc20bb.zip que j'ai pris est tirÃ© de : ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/current/binary/gpc-19990430-i386-pc-djgppv202.zip . Ai-je pris le mauvais fichier? ------------------------------------------------------------------ Quand je compile avec rhide, j'ai un message "ignoring -g". J'ai contactÃ© Robert (auteur de rhide) qui m'a rÃ©pondu: To modify the calling sequences for external programs, you don't need to modify RHIDE itself. All is done via so called specs. You can see all the builtin specs by running redir -e specs rhide -E If you look at the file specs after this, you will find for instance a line like RHIDE_COMPILE_LINK_GPC_AUTOMAKE=$(RHIDE_LD_PASCAL) $(RHIDE_LIBDIRS) -o\ $(OUTFILE) --automake="$(strip $(RHIDE_GPC_FLAGS))"\ $(RHIDE_GPC_FLAGS) $(SOURCE_NAME) $(LIBRARIES) $(LDFLAGS)\ $(RHIDE_LDFLAGS) $(RHIDE_LIBS) To overwrite such a builtin specs, provide a new one in a rhide.env file (either the global one in %DJDIR%/share/rhide/ or a local one in the current directory). In you specific task you should place a line like the following: RHIDE_COMPILE_LINK_GPC_AUTOMAKE=$(RHIDE_LD_PASCAL) $(RHIDE_LIBDIRS) -o $(OUTFILE) -automake $(RHIDE_GPC_FLAGS) $(SOURCE_NAME) $(LIBRARIES) $(LDFLAGS) $(RHIDE_LDFLAGS) $(RHIDE_LIBS) (NOTE here, this should be all ONE long line!!!) J'ai effectivement bien la spec indiquÃ©e. Je ne commprends pas bien ce que je dois faire avec la fameuse ligne. Je l'ai mise seule dans un fichier rhide.env mis dans les deux rÃ©pertoires indiquÃ©s sans aucun changements. Heu... Au secours! --------------------------------------------------------------------- Ca fait quoi chez vous? A+ Olivier -- --------Publicite--personnelle--------------------------------------- ........ABC de la Programmation: ................http://www.multimania.com/opecheux Abonnez-vous aux listes francaises: - Assembleur: http://www.onelist.com/subscribe/prog_nasm - C : http://www.onelist.com/subscribe/prog_c_gnu - Pascal : http://www.onelist.com/subscribe/prog_pascal_gnu --

1 0

gpc-19990118 RPMs on Agnes
by Peter Gerwinski 04 Jun '99

04 Jun '99

Hello, the latest GPC beta gpc-19990118 is now available at `ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/' as RPM packages for the source and binaries (subdirectory `binary') for i386-pc-linux-gnu. Thanks to Jose Romildo Malaquias for building these packages. Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75 *** Vote against SPAM! ********* http://www.politik-digital.de/spam/ ***

1 0

Relationship between GPC and GCC on Linux (Compiling)
by Jose Romildo Malaquias 04 Jun '99

04 Jun '99

Hello. I am new to this list and to GPC. I have just downloaded latest GPC beta sources. I am going to build RPM packages from it (I was not able to find one) for RedHat Linux 6.0, which comes with EGCS 1.1.2 (egcs-2.91.66). 1. As there is not a patch for this version of EGCS in the GPC distribution, I decided to compile with the latest GCC (2.8.1). There is or will be patches for EGCS 1.1.2? 2. The compilation goes smoothly. Installation too. But should I keep the files /usr/lib/gcc-lib/i386-redhat-linux/2.8.1/{libgcc.a,spec} or they can be safely removed (and then GPC uses the ones from the EGCS installation)? Thanks. Prof. JosÃ© Romildo Malaquias <romildo(a)urano.iceb.ufop.br>

2 5

Incompatibility with gcc
by root 04 Jun '99

04 Jun '99

I install rh 6.0 that comes with the egcs-2.91.66 and my gpc 2.0 don't work now, and i don't know any site to dowload a pakage with gpc that work with this compiler. Can anybody help me, i need put the practics 9-6-99. please helpme.......

3 2

Problemn with gpc
by root 04 Jun '99

04 Jun '99

I ported some code to gpc 2.0, i make the test in home with a linux rh 5.2, whit this piece of code, all works fine: program test; procedure test( s: string); begin writeln('String:',s); end; begin test('Esto es de prueba'); end. But when i put the procedure prueba in a unit, it crash: <<modulo.p>> unit modulo; interface procedure prueba( s: string); implementation procedure prueba( s: string); begin writeln('Cadena:',s); end; end. <<prueba.p>> program Prueba; uses modulo; begin prueba('Esto es de prueba'); end. And this is the output: Cadena:E Segmentation fault (core dumped) And this with xxgdb: (xxgdb) list modulo.p:1 (xxgdb) tbreak 11 Breakpoint 1 at 0x8048d93: file modulo.p, line 11. (xxgdb) run Prueba (S={Capacity = 0, length = 17, string = 0xbffffd88}) at modulo.p:11 The diference is te Capacity = 0, with the first code its run fine??? What can i do???? I need this work in gpc 2.0 because is the compiler that have the machine, in that i must drop the practics

2 1

Re: Another runtime question
by Frank Heckenbach 04 Jun '99

04 Jun '99

Jo Dillon wrote: > More runtime porting issues - I notice that the macro WRITE_VARIOUS_TYPES > in write.c has lots of cases where if FIX_WIDTH_MASK is true an extra > argument is popped off the arglist (presumably the width), otherwise > it's ignored. When is FIX_WIDTH_MASK set? Is it on by default for stdout? It's set (by the code generated by the compiler in rts.c: rts_write()) when a width is specified in the Write[ln] statement, i.e. `Write (foo : 42)'. In this case, the width (42) is pushed automatically by the compiler generated code. It's got nothing to do with stdout vs. other files. However, a little warning: as I said in my last posting about `Re: Writeln(real)', we plan to change the calling mechanism substantially (though not in the nearest future, but sometime). When that happens, you'll have to make according changes in your runtime. That's why it seems preferable to keep as much as possible of the RTS and to only replace the low-level functions (e.g. write()) as far as needed... Frank -- Frank Heckenbach, frank(a)fjf.gnu.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

Another runtime question
by Jo Dillon 04 Jun '99

04 Jun '99

More runtime porting issues - I notice that the macro WRITE_VARIOUS_TYPES in write.c has lots of cases where if FIX_WIDTH_MASK is true an extra argument is popped off the arglist (presumably the width), otherwise it's ignored. When is FIX_WIDTH_MASK set? Is it on by default for stdout? -- Jo

1 0

Re: Writeln(real)
by Frank Heckenbach 04 Jun '99

04 Jun '99

Oliver Puetz wrote: > outputs > > 0.000 0.000 > > but it should be > > 10.000 10.000 > > gpc without any parameters reports > > Integers and strings will be written correctly. I've tested other sizes of > floating-point-vars, but nothing helps. That's the GCC (and EGCS) bug under IRIX that Miklos mentioned. It's a bug with real numbers as varargs which breaks Write[ln] of real numbers in GPC. There are plans to do Write[ln] without varargs in GPC, but since there are many other things to do, don't hold your breath... So, the better thing to do is to report the problem to the EGCS maintainers and let them fix the bug. Here's a demo C program that shows this bug (writes 0 (or perhaps some random number) instead of 8 under IRIX) which you can send them to report the bug. #include <varargs.h> #include <stdio.h> void foo (va_alist) va_dcl { va_list p; double q; va_start (p); q=va_arg (p, double); printf ("%i\n", (int) q); } int main () { double q = 8.0; foo (q); return 0; } Frank -- Frank Heckenbach, frank(a)fjf.gnu.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

Writeln(real)
by Oliver Puetz 04 Jun '99

04 Jun '99

Hi, following program Test Program Test; var a :double; begin a:=10.0; Writeln(a :10:3, 10.0 :10:3); end. outputs 0.000 0.000 but it should be 10.000 10.000 gpc without any parameters reports ld32: WARNING 84: /usr/lib32/libm.so is not used for resolving any symbol. ld32: WARNING 85: definition of opterr in /tmp/puetzobq/usr/local/lib/gcc-lib/mi ps-sgi-irix6.2/2.8.1/libgpc.a(getopt.o) preempts that definition in /usr/lib32/m ips3/libc.so. ld32: WARNING 85: definition of optind in /tmp/puetzobq/usr/local/lib/gcc-lib/mi ps-sgi-irix6.2/2.8.1/libgpc.a(getopt.o) preempts that definition in /usr/lib32/m ips3/libc.so. ld32: WARNING 85: definition of optopt in /tmp/puetzobq/usr/local/lib/gcc-lib/mi ps-sgi-irix6.2/2.8.1/libgpc.a(getopt.o) preempts that definition in /usr/lib32/m ips3/libc.so. ld32: WARNING 85: definition of optarg in /tmp/puetzobq/usr/local/lib/gcc-lib/mi ps-sgi-irix6.2/2.8.1/libgpc.a(getopt.o) preempts that definition in /usr/lib32/m ips3/libc.so. Integers and strings will be written correctly. I've tested other sizes of floating-point-vars, but nothing helps. Regards Oliver -- Oliver Puetz Tel.: 0234-700-2982 Lehrstuhl fuer Fluidenergiemaschinen Fax.: 0234-7094-358 Ruhr-Universitaet Bochum, Universitaetsstr. 150, 44801 Bochum opuetz(a)fem.ruhr-uni-bochum.de Gebaeude IB 4/141 www.ruhr-uni-bochum.de/www-public/volgmwbr/mitarb/puetz.htm

1 0

Re: GNU Binary for SGI
by Oliver Puetz 04 Jun '99

04 Jun '99

On Fri, 4 Jun 1999 11:33:15 +0200, Peter Gerwinski wrote: > uses > GPC; (* `MaxLongInt' is defined here *) with the environmental settings, gpc will now be compiled. Thanks! Regards Oliver -- Oliver Puetz Tel.: 0234-700-2982 Lehrstuhl fuer Fluidenergiemaschinen Fax.: 0234-7094-358 Ruhr-Universitaet Bochum, Universitaetsstr. 150, 44801 Bochum opuetz(a)fem.ruhr-uni-bochum.de Gebaeude IB 4/141 www.ruhr-uni-bochum.de/www-public/volgmwbr/mitarb/puetz.htm

1 0

Re: GNU Binary for SGI
by Oliver Puetz 04 Jun '99

04 Jun '99

On Fri, 4 Jun 1999 11:33:15 +0200, Peter Gerwinski wrote: Hi Peter, > Program Test; > > uses > GPC; (* `MaxLongInt' is defined here *) while compiling gpc.pas gpc reports gpc.pas:73: type name expected, identifier `Cstring' given gpc: Internal compiler error: program gpc1 got fatal signal 11 gpc1: gpc exited with status 1 parameters was gpc -B ... -L ... --automake I had to copy gpc.pas into my local dir, otherwise it wouldn't be found. adding -I /tmp/puetzobq/usr/local/lib/gcc-lib/mips-sgi-irix6.2/2.8.1/units/ as gpc.pas its directory didn't help. Could it be that all errors occur, because setting the environmental variables like GPC_EXEC_PREFIX didn't seem to work? Regards Oliver -- Oliver Puetz Tel.: 0234-700-2982 Lehrstuhl fuer Fluidenergiemaschinen Fax.: 0234-7094-358 Ruhr-Universitaet Bochum, Universitaetsstr. 150, 44801 Bochum opuetz(a)fem.ruhr-uni-bochum.de Gebaeude IB 4/141 www.ruhr-uni-bochum.de/www-public/volgmwbr/mitarb/puetz.htm

2 1

Re: GNU Binary for SGI
by Klaus Espenlaub 04 Jun '99

04 Jun '99

Oliver Puetz wrote: > It seems not to work. I've made the settings like you wrote in my .cshrc > setenv reports this: > > GPC_EXEC_PREFIX=/net/sgi249/share/mips/gnu/lib/gcc-lib/mips-sgi-irix6.2/2.8.1/ > CC_LIBRARY_PATH=/tmp/puetzobq/usr/local/lib/gcc-lib/mips-sgi-irix6.2/2.8.1/ [somehow the first character of the two variable names got lost. I assume they were there...] Reading the docs and doing a "strings gpc" it turns out that the env variable name is wrong: it's still GCC_EXEC_PREFIX. Maybe this should be fixed or documented. And the libraries are searched at LIBRARY_PATH. The value for LIBRARY_PATH looks correct for me, but GCC_EXEC_PREFIX should be set to net/sgi249/share/mips/gnu/lib/gcc-lib/ in your case. Try gpc -print-search-dirs to check if the settings are now accepted. And don't forget that these settings will affect the GNU C compiler as well! I'd expect gcc to break if these settings are in place. One last word about LIBRARY_PATH: I'd use -L if I am planning to use a hacked version of the library, as it seems the case in your settings. Klaus

2 1

GNU Binary for SGI
by Oliver Puetz 04 Jun '99

04 Jun '99

Hi Peter, >Sanity check: Did you export or perhaps only set the environment >variable? With `bash', the difference is > > GPC_EXEC_PREFIX=/gpc/usr/local/lib/gcc-lib/mips-sgi-irix6.2/2.8.1 # wrong > >vs. > export GPC_EXEC_PREFIX=/gpc/usr/local/lib/gcc-lib/mips-sgi-irix6.2/2.8.1 # correct First I've set them only via ...=..., but under a cshell, where no export works. with bash, I can export them (export shows the correct values), but only with gpc -B ... -L ... test.pas it runs now :-))) Thank you very much I've got some problems with porting programs from borland to gpc. E.g. in the online-manual http://agnes.dida.physik.uni-essen.de/~gnu-pascal/gpc_5.html#SEC71 is listed, that with gpc --borland-pascal maxint and maxlongint will be predefined. But they aren't. What's wrong? Thanks in advance Oliver -- Oliver Puetz Tel.: 0234-700-2982 Lehrstuhl fuer Fluidenergiemaschinen Fax.: 0234-7094-358 Ruhr-Universitaet Bochum, Universitaetsstr. 150, 44801 Bochum opuetz(a)fem.ruhr-uni-bochum.de Gebaeude IB 4/141 www.ruhr-uni-bochum.de/www-public/volgmwbr/mitarb/puetz.htm

3 2

Re: GNU Binary for SGI
by Klaus Espenlaub 04 Jun '99

04 Jun '99

Oliver Puetz wrote: > > export GPC_EXEC_PREFIX=/gpc/usr/local/lib/gcc-lib/mips-sgi-irix6.2/2.8.1 > # correct > > First I've set them only via ...=..., but under a cshell, where no export > works. with bash, I can export them (export shows the correct values), but > only with > > gpc -B ... -L ... test.pas > > it runs now :-))) Thank you very much if you're using csh then the setting of an environment variable (csh uses a different construct for local shell variables) looks like setenv GPC_EXEC_PREFIX /gpc/usr/local/lib/gcc-lib/mips-sgi-irix6.2/2.8.1 Important: no "=" between the env variable name and its value. Klaus

1 0

2025

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