Gpc May 1999

gpc@gnu.de

25 participants
69 discussions

GPC for AIX 4.3.1
by Marina Markus 19 May '99

19 May '99

Hello GPC users ! I need a binary GPC distribution for AIX 4.3.1 operating system. It is absent in collection of binary distributions at GPC site; maybe it exists anywhere else ? Thank you in advance, Marina Markus Ben-Gurion University Computer Center Beer-Sheva, Israel ====================== mary(a)bgumail.bgu.ac.il

2 8

Re: prior parameter's size depends on `foo'
by david＠tcs01.demon.co.uk 19 May '99

19 May '99

In message <19990512012516.B1546(a)esmeralda.gerwinski.de> Peter Gerwinski writes: > > > The problem is at compile-time, attached is a small module which > > exhibits this behaviour. My system is Red Hat Linux release 5.2 (Apollo) > > running kernel 2.0.36 on an i586. I've built gcc-2.8.1 and gpc > > 19990118. > > > > gpc -v gives the following output > > ----------------------------------------------------------------- > > Reading specs from /usr/lib/gcc-lib/i586-pc-linux-gnu/2.8.1/specs > > gpc version 19990118, based on gcc-2.8.1 > > ----------------------------------------------------------------- > > Thanks for the detailed information. :-) > > Below is a version of your test program that is ready for our > test suite. > > To work around the bug, you can drop the first `protected'. I now have a significantly bigger module (which also imports from several other modules) which is exhibiting the same behaviour "prior parameter's size depends on `foo'" where `foo' is a protected string parameter in the function/procedure declaration. In this case if I drop all the `protected' in the procedure/function declarations in the interface, I get "gpc: Internal compiler error: program gpc1 got fatal signal 6". Any suggestions about more general work-arounds for this problem with string parameters in extended Pascal modules? Converting the extended Pascal module to a unit seems to be a work-around, but having to do that is going to make this migration much more difficult than staying with the extended Pascal modules that the system currently uses. -- David James mailto:david@tcs01.demon.co.uk

2 2

Re: environ
by Frank Heckenbach 17 May '99

17 May '99

Nick Burrett wrote: > > Now, `environ', as the name suggests, contains the current > > environment variables, i.e. the ones that were set when the process > > started plus the ones the process set itself (by setenv() or > > putenv()). > > The `environ' variable only contains the array of strings of the environment > at process startup. It does not change with calls to setenv or putenv. According to my tests, it does change!? > > Another way to get at the environment is the third parameter to > > `main' (which GPC could access internally, that's not a problem). > > However, this variable only contains the environment at the start of > > the process. When the process does some putenv()s, the pointer gets > > invalid (DJGPP), or the environment pointed to just seems to be > > unmodified (the other systems I tested). Perhaps the DJGPP behaviour > > is a bug, I don't know, but in any case the parameter is not useful > > to get the current environment at a later time. > > The third argument to main is equivalent to the `environ' variable and > should point to the same place. Well, not on the systems I tried. The third argument became invalid after putenv (DJGPP), or did not change (other systems). > > So, does anybody know what's the matter with `environ'? Can one just > > declare it as `extern char **environ;' even if it's not declared in > > any header? Or is there another way to get at the current > > environment? > > Yes you can just declare it as `extern char **environ'. There's no > guarantee that `environ' actually exists so just declaring it extern > and using it could give you linker errors. You'd have to find a > solution to this, perhaps using autoconf to check for it's existence > and declaring your own version if it doesn't. I think if I have to write my own version, anyway, I can just as well use it on all systems. I think it would be more consistent then than using a (partially undocumented) libc declaration on some systems and my own version on others. > > If not, in the worst case, this would mean that the GPC RTS has do > > to its own environment handling, i.e. get the initial environment > > for the `main' parameter, and provide its own versions of getenv() > > and putenv() which work on a copy of that. Though it would not be > > terribly much work, I hope to avoid it... > > I don't see why the GPC RTS would need to do it's own environment > handling. Unless you are thinking of the extreme case where the > `getenv', `setenv' and `putenv' functions are missing. Or are you > thinking that a Pascal character array pointer should always point > to an up-to-date environment list ? Yes, I think it should. E.g., in a program of mine, I do some `putenv's, and then I want to pass the up-to-date environment to a child process (started by execve() in the Pipe unit). But I also want to read the (new and old) environment variables via `getenv' in the program itself. So, if `environ' doesn't point to an up-to-date environment, I'd have to do each `putenv' twice, once for the (hidden?) environment that `getenv' uses, and once for my own environment that is given to execve(). I'd consider this quite ugly, and rather than doing this, I'd prefer to write my own versions of putenv, getenv. etc. 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

Re: environ
by Nick Burrett 17 May '99

17 May '99

Frank Heckenbach <frank(a)tim.gerwinski.de> writes: > a bug report of a GPC user drew my attention to a possible problem > with the `environ' libc variable (which is currently declared for > Pascal as `Environment' in gpc.pas). > > Now, `environ', as the name suggests, contains the current > environment variables, i.e. the ones that were set when the process > started plus the ones the process set itself (by setenv() or > putenv()). The `environ' variable only contains the array of strings of the environment at process startup. It does not change with calls to setenv or putenv. > Another way to get at the environment is the third parameter to > `main' (which GPC could access internally, that's not a problem). > However, this variable only contains the environment at the start of > the process. When the process does some putenv()s, the pointer gets > invalid (DJGPP), or the environment pointed to just seems to be > unmodified (the other systems I tested). Perhaps the DJGPP behaviour > is a bug, I don't know, but in any case the parameter is not useful > to get the current environment at a later time. The third argument to main is equivalent to the `environ' variable and should point to the same place. > So, does anybody know what's the matter with `environ'? Can one just > declare it as `extern char **environ;' even if it's not declared in > any header? Or is there another way to get at the current > environment? Yes you can just declare it as `extern char **environ'. There's no guarantee that `environ' actually exists so just declaring it extern and using it could give you linker errors. You'd have to find a solution to this, perhaps using autoconf to check for it's existence and declaring your own version if it doesn't. There isn't anything wrong with `environ', you have just misunderstood it slightly. > If not, in the worst case, this would mean that the GPC RTS has do > to its own environment handling, i.e. get the initial environment > for the `main' parameter, and provide its own versions of getenv() > and putenv() which work on a copy of that. Though it would not be > terribly much work, I hope to avoid it... I don't see why the GPC RTS would need to do it's own environment handling. Unless you are thinking of the extreme case where the `getenv', `setenv' and `putenv' functions are missing. Or are you thinking that a Pascal character array pointer should always point to an up-to-date environment list ? Nick.

1 0

Re: Word or Cardinal
by Frank Heckenbach 16 May '99

16 May '99

Olivier PECHEUX wrote: > I want to use the unsigned integers in GPC. If I compile: > > Program Unsigned; > Var i:Word; > Begin > For i:=1 To 10 Do Writeln(i) > End. > > I have the error: > Error:type name expected, identifier 'Word' given > > If I replace Word by Integer, that's OK. I try Cardinal insted of Word, > it does'n work. I'm using the GPC of gpc20b.zip and rhide on a windows > machine Please upgrade to a newer GPC, version 2.0 is very old. The last beta version (19990118) can be found at ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/current/ It supports both Word and Cardinal. They're equivalent -- which one you use is up to your preference. 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

Word or Cardinal
by Olivier PECHEUX 16 May '99

16 May '99

Hi, I want to use the unsigned integers in GPC. If I compile: Program Unsigned; Var i:Word; Begin For i:=1 To 10 Do Writeln(i) End. I have the error: Error:type name expected, identifier 'Word' given If I replace Word by Integer, that's OK. I try Cardinal insted of Word, it does'n work. I'm using the GPC of gpc20b.zip and rhide on a windows machine What's wrong? Olivier. -- --------Publicite--personnelle--------------------------------------- ........ABC de la Programmation: ................http://www.multimania.com/opecheux

1 0

Re: help...
by Russ Whitaker 15 May '99

15 May '99

Qyrano writes: > Subject: help... > Date: Friday, May 14, 1999 3:25 PM > > $ gpc factorial.pas > > ld> cannot open -lgmp: No such file or directory > > (demo program factorial.pas uses units gpc and gmp....) > > Can someone help me to solve this trouble?..... > > Roberto you can download gmp from ftp://metalab.unc.edu/pub/gnu/gmp thanks Russ

1 0

Re: help...
by Frank Heckenbach 15 May '99

15 May '99

Qyrano wrote: > $ gpc factorial.pas > > ld> cannot open -lgmp: No such file or directory > > (demo program factorial.pas uses units gpc and gmp....) > > Can someone help me to solve this trouble?..... You need the GMP library, available from ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/libs/ You'll also need the rx library for the RegEx unit and the ncurses (Unix/terminal) or `curse' (Unix/X11, DJGPP) library for the CRT unit. There are sources and binaries for some systems. If you're using a system for which there are no binaries yet, and you compile the libraries, we'd appreciate if you upload a binary. 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

help...
by Qyrano 15 May '99

15 May '99

$ gpc factorial.pas ld> cannot open -lgmp: No such file or directory (demo program factorial.pas uses units gpc and gmp....) Can someone help me to solve this trouble?..... Roberto

1 0

Re: Relationship between GPC and GCC on Linux (Compiling)
by Frank Heckenbach 14 May '99

14 May '99

Jose Romildo Malaquias wrote: > 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)? I think they can safely be removed -- for now. Currently, as you correctly noted, it is necessary to have the same version of GCC as of GPC. In the future, we hope to relax this restriction so GPC will work with any GCC version installed. If that's a different version, there won't be libgcc.a and specs in GPC's directory, so the files from GPC should be kept. But if it's the same version, the files from GCC should probably be used. This might be a problem. Does RPM provide a way to handle such situations? > I have worked out rpm packages for the latest GPC beta. As I am not > an experienced GPC user, would somebody take a look at the spec file > and comment it. I'm not familiar with RPM specs, so I won't comment on them. Just two points: : Copyright: GPL If you want to be very precise, you could add LGPL (which holds for the run time system) here. : Url: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/ http://home.pages.de/~GNU-Pascal/ is preferable. Currently, it points to the same URL, but if the former should ever change, the latter will remain the same. 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

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