- Gpc - gnu.de

Problem exporting enumerated type from Extended Pascal module
by david＠tcs01.demon.co.uk 23 May '99

23 May '99

I think I'm seeing a problem in exporting an enumerated type from an Extended Pascal module. My system is RedHat Linux release 5.2 (Apollo) running kernel 2.0.36 on an i586. gpc -v reports as follows: ---------------------------------------------------------------------- Reading specs from /usr/lib/gcc-lib/i586-pc-linux-gnu/2.8.1/specs gpc version 19990118, based on gcc-2.8.1 -------------------------------------------------------------------- Below is a small module (dajmod2.p) and a program (daj2.p) which imports it. These have been cut down from a much bigger piece of code. When compiling daj2.p the compiler reports: -------------------------------------------------------------------- daj2.p: In function `program_Daj2': daj2.p:7: incompatible types in assignment daj2.p:8: invalid operands to binary = -------------------------------------------------------------------- 8<---- daj2.p ------------------------------------------------------ program daj2; import progtypes in 'dajmod2.p'; globalvars in 'dajmod2.p'; begin pgmtype:=prog_press; if (pgmtype=prog_press) then writeln('OK') else writeln('Error'); end. 8<--- dajmod2.p ----------------------------------------------------- module dajmod2 interface; export progtypes =(tprogtype, prog_none..prog_last); globalvars =(pgmtype); TYPE TPROGTYPE=(prog_none, prog_press, prog_last); VAR pgmtype:tprogtype; end. {of module header} module dajmod2 implementation; end. {of module implentation} -------------------------------------------------------------------- If I embed just the TYPE and VAR declarations from dajmod2 within daj2, the program compiles and runs correctly. -- David James mailto:david@tcs01.demon.co.uk

3 3

Re: Rhide and gpc
by Frank Heckenbach 22 May '99

22 May '99

Olivier PECHEUX wrote: > I have loaded the gpc (5/99). I use rhide and windoze. And I have > troubles: > When I compile, Rhide call > "gpc -o etape.exe --automake="-g" -g etape.pas -lm -lgpc" > > First, --automake="-g" aren't in the documentation and I have the > message > "ignoring AutoMake option -g"; This was changed in the last release of GPC. Instead of `--automake="-g" -g', you should now simply say `--automake -g' (i.e., no need to repeat the options for automake). > Is it possible to change the call? If you have the RHIDE source and can compile it, it should be easy to change the GPC invocation. Otherwise you'd have to ask Robert, the RHIDE author, to do it. > Second: with the -lgpc the program dosn't reconize the gpc librairie > (GPC_randomize is't reconize at all). But if I put "uses gpc" it does. > Why? > > Third: What does mean -lm? Is there an m librarie? There is a difference between libraries and units/modules. Libraries are originally a C concept -- they consist only of object code without any interface declarations (these are in header files in C), while Pascal units/modules consist of code and declarations. GNU Pascal can use libraries with `-l' switches, but this only provides the object code, not the interface declarations. E.g., the GPC Run Time System is in libgpc.a which is linked with the `-lgpc' switch. However, to make available the declarations, you have to use the unit GPC (which is in gpc.pas), as you noticed. (BTW, don't use GPC_Randomize in your programs. It's an internal routine. The compiler knows `Randomize' which will ultimately call GPC_Randomize, but is more portable. For `Randomize', you don't even have to use GPC, but for other declarations, you do.) Similarly, there's a math libarary (libm.a, -lm) which contains routines like sin and cos. For them, you don't need to use any unit, because the compiler knows about them. Actually, GPC knows already that it needs -lgpc and -lm, so one doesn't have to specify those two libraries explicitly (and this has been so for a few years at least). I don't know why RHIDE adds them, but that's unnecessary. To put it shortly, don't worry about libraries (i.e., `-lfoo' options). Just use the units you want, and you should be fine. This also holds for units like CRT which need additional libraries (curses), because they take care of the libraries automatically. > When I compile a librairie, I have an "undefinied reference to main" > message. For now I ignore it because it's work. What is your position? > What I have to do? I suppose you mean a unit. Indeed, it doesn't cause any problems except this error message, but you can give the `-c' option, and the message will disappear. (Perhaps in the future, you won't need `-c', but currently, you do.) 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

info
by GPC Pascal on Linux User 22 May '99

22 May '99

info

1 0

Rhide and gpc
by Olivier PECHEUX 21 May '99

21 May '99

Hi, ----------------------- I have loaded the gpc (5/99). I use rhide and windoze. And I have troubles: When I compile, Rhide call "gpc -o etape.exe --automake="-g" -g etape.pas -lm -lgpc" First, --automake="-g" aren't in the documentation and I have the message "ignoring AutoMake option -g"; Is it possible to change the call? Second: with the -lgpc the program dosn't reconize the gpc librairie (GPC_randomize is't reconize at all). But if I put "uses gpc" it does. Why? Third: What does mean -lm? Is there an m librarie? ------------------- When I compile a librairie, I have an "undefinied reference to main" message. For now I ignore it because it's work. What is your position? What I have to do? ------------------- I inform also that there is a french maling list on the Pascal and on the gnu: http://www.onelist.com/subscribe/prog_pascal_gnu --------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

Re: Restricting posting to the GPC list? (was: SNN - Star Wars - WCLT)
by Nick Burrett 20 May '99

20 May '99

Frank Heckenbach <frank(a)tim.gerwinski.de> writes: > Peter Gerwinski wrote: > > > David James wrote: > > > I take it from this that the GPC list doesn't restrict posting to > > > members only. Since the SPAM/UCE merchants seem to be everywhere > > > would it be a good idea to do this - I believe Majordomo has such a > > > capability. > > > > This would have the drawback that the GPC mailing list could > > no more serve as a place to call for help with GPC without > > subscribing in the first place. > > > > Majordomo has some more capabilities that allow to check for > > keywords first, so suscipious mails get sorted out and must be > > approved by a moderator before further submission. > > Would it be possible to forward mails that are not from subscribers > (and perhaps don't contain clear keywords like `GPC') to a > moderator? Since most of the mails are from subscribers, this should > eliminate all spam, without causing very much work for a > moderator... One solution, that is used by the egcs.cygnus.com mail server, is to modify the mail delivery agent to check addresses against MAPS RBL and ORBS. This is quite easy if your MDA is sendmail 8.9. Nick.

1 0

Re: SNN - Star Wars - WCLT
by david＠tcs01.demon.co.uk 19 May '99

19 May '99

In message <359DFE77.4AC9(a)erols.com> oho87(a)jboy.com writes: > StockNetworking News > [etc., etc., etc] I take it from this that the GPC list doesn't restrict posting to members only. Since the SPAM/UCE merchants seem to be everywhere would it be a good idea to do this - I believe Majordomo has such a capability. -- David James mailto:david@tcs01.demon.co.uk Special Stage Rally results archive <URL:http://www.tcs01.demon.co.uk/>

2 1

Re: GPC for AIX 4.3.1
by Frank Heckenbach 19 May '99

19 May '99

Marina Markus wrote: > stage1/xgcc -Bstage1/ -c -Wall -Wpointer-arith -Wmissing-prototypes > -Wmissing-declarations -O2 -g -O2 -I. -I../.. -I/usr/local/src/egcs-1.1.2/ > gcc/p/rts/../.. -I/usr/local/src/egcs-1.1.2/gcc/p/rts/../../config /usr/loc > al/src/egcs-1.1.2/gcc/p/rts/pexecute.c > In file included from /usr/local/lib/gcc-lib/powerpc-ibm-aix4.2.1.0/egcs-2. > 91.66/include/sys/wait.h:49, > from /usr/local/src/egcs-1.1.2/gcc/p/rts/pexecute.c:38: > /usr/local/lib/gcc-lib/powerpc-ibm-aix4.2.1.0/egcs-2.91.66/include/sys/sign > al.h:121: warning: `SIGEMT' redefined > rts-config.h:182: warning: this is the location of the previous definition > /usr/local/lib/gcc-lib/powerpc-ibm-aix4.2.1.0/egcs-2.91.66/include/sys/sign > al.h:126: warning: `SIGSYS' redefined > rts-config.h:178: warning: this is the location of the previous definition > /usr/local/lib/gcc-lib/powerpc-ibm-aix4.2.1.0/egcs-2.91.66/include/sys/sign > al.h:130: warning: `SIGURG' redefined > rts-config.h:186: warning: this is the location of the previous definition > /usr/local/lib/gcc-lib/powerpc-ibm-aix4.2.1.0/egcs-2.91.66/include/sys/sign > al.h:164: warning: `SIGIOT' redefined > rts-config.h:190: warning: this is the location of the previous definition To get rid of the warnings, you can insert #include <signal.h> into rts/pexecute.c, before the line #include "rts-config.h" > make: Cannot find a rule to create target heap.o from dependencies. > Stop. I think the problem is that the RTS makefile uses "pattern rules" which your version of make does not understand. So you can either use GNU make, or replace %.o:%.pas by .SUFFIXES: .pas .pas.o: This should fix the problem. Both things will be fixed in the next snapshot. 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 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