Gpc December 1999

gpc@gnu.de

26 participants
45 discussions

Help for gpc install
by Marc SERRAU 20 Dec '99

20 Dec '99

Hello, My name is Marc SERRAU and I discovered the GNU Pascal Compiler few days ago. I installed it on my linux based PC from the binary package. (rpm) The installation worked well but I always become the following message after compiler even with a trivial Hello.pas program : [marc@altair hisix]$ gpc hello.pas ld: cannot open -lgcc: Aucun fichier ou rÃ©pertoire de ce type The linker cannot find some stuff, but what ? The gcc compiler was installed from an RH 6.0 distrib. Who can help me ? Thank you for your effort. Marc SERRAU Visit http://www.astrosurf.org/noctambule Marc SERRAU Visitez http://www.astrosurf.org/noctambule In Linux we trust, more and more...

4 7

_dos_ds
by Opie Pecheux 20 Dec '99

20 Dec '99

Hi, I use gpc 19990430 for dos with rhide. I want to access to the video memory. In C I use _farsetsel without problems, but in Pascal I have a problem with the selector _dos_ds. For _farsetsel, I write: Procedure FarSetSel(Selecteur:integer); AsmName '_farsetsel'; But I don't know how to use _dos_ds, of course FarSetSel(_dos_ds); don't work. Thanks for help. -- A+ Opie --------Publicite--personnelle--------------------------------------- ........ ABC de la Programmation (Assembleur, C, Pascal) ................ http://www.multimania.com/opecheux ................ Pour Ãªtre averti des nouvelles Ã©tapes, abonnez vous --

2 1

Re: Strings problem
by Frank Heckenbach 20 Dec '99

20 Dec '99

"Dr A Olowofoyeku" wrote: > On 19 Dec 99, at 21:06, Maurice Lombardi wrote: > > > LUJOP a Ã©crit : > > > The output generated is: > > > Bye<Hello > > > Bye>Hello > > > > Strange ! I find the correct result > > > > Hello>Bye > > Bye<Hello > > > > But I use the last alpha version of gpc. > > Is this a corrected bug ? > > IIRC, the answer is "Yes". Indeed. The bug was fixed Jan 26 which was after the release of the last beta version, but before the release of the subsequent alphas. (And, IIRC, the bug was "created" shortly before, so it only affects that one beta version.) A real solution to this problem would require an update of the compiler, or at least the runtime library (libgpc.a). As a work-around, you could possibly use the compiler directive `{$no-exact-compare-strings}' at the beginning of your code or pass the option `--no-exact-compare-strings' on the command line. This will cause spaces at the end of strings to be ignored in the comparison (like ISO 10206 demands). The operators that compare that way were not affected by the bug, but of course, the bevahiour is a little different, so this might not be an option to you... 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

Strings problem
by LUJOP 20 Dec '99

20 Dec '99

First of all excusme for my little english. I'm new and I haven't experience with GPC, in fact I don't like Pascal very much. But I need to do a work for the university. The version I run is: Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/2.8.1/specs gpc version 19990118, based on gcc-2.8.1 And I have some problems comparing strings. If I compile and run the next program: Program test; var a,b:string(20); begin a:='Hello'; b:='Bye'; if(a<b) then writeln('Hello<Bye'); if(a>b) then writeln('Hello>Bye'); if(b<a) then writeln('Bye<Hello'); if(b>a) then writeln('Bye>Hello'); end. The output generated is: Bye<Hello Bye>Hello And, logically it isn't very nice :-) My question is simple: why the program don't function as desired? Or, if the error is mine, What I do bad? Postdate: I need to compile the program in the metionated version, and I can't update to a newer (university's administrators are not very servicial) Thus, if we can give a solution for the above version I'll be very happy. Otherwise I will be to codify strings with arrays of chars. Please , if someone reply to this message can send a copy to jpujo012(a)correu.udg.es Thanks And, another time excusme for me english.

3 2

Strings problem
by LUJOP 20 Dec '99

20 Dec '99

1 0

Re: Modules/units, separate compilation, minimal re-compilations
by Frank Heckenbach 15 Dec '99

15 Dec '99

David James wrote: I have several applications which I'm porting to GPC on Linux from another (almost) ISO-10206 extended Pascal. > The application is structured in several layers, in this sort of > scheme: > > modules A, B, C export constants, types, variables, procedures and > functions which are used by modules D, E, F which in turn export > constants, types, variables, procedures and functions which are > imported by modules G, H, I which in turn ... are imported by > programs X, Y, Z. > > The previous compiler allowed (as GPC does) the interface and > implementation parts of each module to be in separate files (usually > .h for the interface and .p for the implementation). > > When deciding what needed re-building when re-compiling program X, > it only checked for updates since the last re-build to the *interface* > parts of the modules imported by X (and, recursively, the modules it > imported). > > This lead to a major reduction in the amount of compilation needed > when re-building one of the applications, for example, if a change > was made to the implementation part of module A, rebuilding program X > would result in module A being re-compiled and then program X being > re-linked. > > So, finally my question: is it possible to do this with GPC? Not currently, but one of the next releases will probably contain a feature to do this. 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 and Red Hat 6.0
by Ken_A_Munro＠keane.com 15 Dec '99

15 Dec '99

Hi. Sorry if I missed something in the documentation, but I think I've read it all over. I have installed the binaries for GPC on my Red Hat 6.0 system. I can get Pascal programs to compile, but when they execute, they core dump. (I have attached the output from a verbose gpc compile of the pi.pas demo program.) The Red Hat 6.0 compiler is egcs-1.1.2, but the GPC binary (from gpc-19990118-egcs-1_1_1_i386-linux-glibc2.tar) was compiled with egcs-1.1.1. Is that why the executables are core dumping? I have also tried compiling GPC, but when I "make LANGUAGES=pascal", I get a lot of "assignment makes pointer from integer without a cast" errors when gcc is compiling gpc.c. Why should that be happening, and how can I remedy it? Also, is this mailing list archived anywhere? Thanks in advance. Any help would be greatly appreciated. Ken Munro **************************** versions of gcc and gpc *************************************************** [root@client11 demos]# egcs -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) [root@client11 demos]# gpc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/specs gpc version 19990118, based on egcs-2.91.60 19981201 (egcs-1.1.1 release) ******************* verbose ouput of pascal compile of sample pi.pas program ****************** [root@client11 demos]# gpc --automake pi.pas -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/specs gpc version 19990118, based on egcs-2.91.60 19981201 (egcs-1.1.1 release) /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/gpc-cpp -lang-pascal -v -nocharescape -D__GNU_PASCAL__ -undef -D__GNUC__=2 -D__GNUC_MINOR__=91 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=19990118 -D__ELF__ -Dunix -Di386 -D__i386__ -Dlinux -D__ELF__ -D__unix__ -D__i386__ -D__i386__ -D__linux__ -D__unix -D__i386 -D__linux -Asystem(posix) -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 -Asystem(unix) -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ pi.pas /tmp/cceao36i.i GNU CPP version egcs-2.91.60 19981201 (egcs-1.1.1 release) (i386 Linux/ELF) #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/i386-redhat-linux/include /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/include /usr/include End of search list. /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/gpc1 /tmp/cceao36i.i -quiet -dumpbase pi.pas -version -famtmpfile=/tmp/cc2OLhLJ.gpc -fautomake -o /tmp/cceao36i.s GNU Pascal version egcs-2.91.60 19981201 (egcs-1.1.1 release) (i386-redhat-linux) compiled by GNU C version egcs-2.91.60 19981201 (egcs-1.1.1 release). GPC AutoMake: gpc --automake -v --amtmpfile=/tmp/cc2OLhLJ.gpc -M /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/units/gpc.pas -o /tmp/cc0clDMX Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/specs gpc version 19990118, based on egcs-2.91.60 19981201 (egcs-1.1.1 release) /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/gpc-cpp -lang-pascal -v -nocharescape -D__GNU_PASCAL__ -M -undef -D__GNUC__=2 -D__GNUC_MINOR__=91 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=19990118 -D__ELF__ -Dunix -Di386 -D__i386__ -Dlinux -D__ELF__ -D__unix__ -D__i386__ -D__i386__ -D__linux__ -D__unix -D__i386 -D__linux -Asystem(posix) -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 -Asystem(unix) -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/units/gpc.pas -o /tmp/cc0clDMX GNU CPP version egcs-2.91.60 19981201 (egcs-1.1.1 release) (i386 Linux/ELF) #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/i386-redhat-linux/include /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/include /usr/include End of search list. GPC AutoMake: done GPC AutoMake: gpc --automake -v --amtmpfile=/tmp/cc2OLhLJ.gpc -M /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/units/gmp.pas -o /tmp/cceFAqbP Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/specs gpc version 19990118, based on egcs-2.91.60 19981201 (egcs-1.1.1 release) /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/gpc-cpp -lang-pascal -v -nochar escape -D__GNU_PASCAL__ -M -undef -D__GNUC__=2 -D__GNUC_MINOR__=91 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=19990118 -D__ELF__ -Dunix -Di386 -D__i386__ -Dlinux -D__ELF__ -D__unix__ -D__i386__ -D__i386__ -D__linux__ -D__unix -D__i386 -D__linux -Asystem(posix) -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 -Asystem(unix) -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/units/gmp.pas -o /tmp/cceFAqbP GNU CPP version egcs-2.91.60 19981201 (egcs-1.1.1 release) (i386 Linux/ELF) #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/i386-redhat-linux/include /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/include /usr/include End of search list. GPC AutoMake: done as -V -Qy -o /tmp/cceao36i1.o /tmp/cceao36i.s GNU assembler version 2.9.1 (i386-redhat-linux), using BFD version 2.9.1.0.23 ld -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/crtbegin.o -L/usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60 -L/usr/i386-redhat-linux/lib gmp.o gpc.o /tmp/cceao36i1.o -lgpc -lm -lgmp -lgcc -lc -lgcc /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/crtend.o /usr/lib/crtn.o [root@client11 demos]#

1 0

Re: Behaviour of reset and extend on text file
by david＠tcs01.demon.co.uk 12 Dec '99

12 Dec '99

In message <199912112317.SAA26060(a)mail.bcpl.net> "J. David Bryan" writes: > On 11 Dec 99, at 13:31, David James wrote: > > > I'm still not sure what my example should do. Looking at the copy of > > Extended Pascal ISO/TEC 10206:1990(E) that I found on (I think) a > > DEC site somewhere, I *think* it is saying (in section 6.7.5.2) that > > after the call to 'extend' the file should be in 'Generation' mode. > > Right. There is no precondition for "extend" that the file be closed. In > fact, there is no "close" predefined function in EP. That explains why I cannot find 'close' in the standard :-). So how should one 'close' a file in EP - would that be 'unbind'? [snip] > > I make no claim to expertise with the EP standard, and the prose in the > standard is nearly impenetrable :-), I think you have an extraneous word there - it's the "nearly" :-) > but as far as I can see, "extend" > following a "reset" is perfectly OK. -- David James mailto:david@tcs01.demon.co.uk Special Stage Rally results archive <URL:http://www.tcs01.demon.co.uk/>

2 1

Re: Behaviour of reset and extend on text file
by david＠tcs01.demon.co.uk 11 Dec '99

11 Dec '99

In message <19991211124359.A4186(a)esmeralda.gerwinski.de> Peter Gerwinski writes: > David James wrote: > > [...] > > The previous compiler allowed one to write to a text file that had been > > opened with 'reset' and then 'extend'ed. GPC says: > > > > ./daj13: cannot write to read only file `daj13.pas' (error #422) > > > > ===== > > program daj13(input,output); > > > > var f:text; > > > > begin > > reset(f,'daj13.pas'); > > extend(f); > > writeln(f,'extra text'); > > end. > > If you `close' the file before the `extend', it works. I'm still not sure what my example should do. Looking at the copy of Extended Pascal ISO/TEC 10206:1990(E) that I found on (I think) a DEC site somewhere, I *think* it is saying (in section 6.7.5.2) that after the call to 'extend' the file should be in 'Generation' mode. I think the run-time error on the 'writeln' is incorrect. However, it is possible that there should be an error on the call to 'extend' (it's not clear to me whether calling 'extend' on a file that has already been 'reset' is allowed). > > Do you happen to know what Extended Pascal thinks about how > `close' should work? No, I'm afraid I don't. I cannot find any reference to 'close' in the index of ISO 10206, and I cannot see anything referring to 'close' in section 6.7.5.2 'File Handling procedures'. -- David James mailto:david@tcs01.demon.co.uk Special Stage Rally results archive <URL:http://www.tcs01.demon.co.uk/>

3 2

Behaviour of reset and extend on text file
by david＠tcs01.demon.co.uk 11 Dec '99

11 Dec '99

I'm not sure what the correct behaviour should be in the attached program, but GPC's behaviour is different from the previous extended Pascal compiler I used (I'm not saying that the previous compiler was right). The previous compiler allowed one to write to a text file that had been opened with 'reset' and then 'extend'ed. GPC says: ./daj13: cannot write to read only file `daj13.pas' (error #422) ===== program daj13(input,output); var f:text; begin reset(f,'daj13.pas'); extend(f); writeln(f,'extra text'); end. -- David James mailto:david@tcs01.demon.co.uk Special Stage Rally results archive <URL:http://www.tcs01.demon.co.uk/>

3 3

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 December 1999