Gpc

gpc@gnu.de

5400 discussions

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

Jump to page:

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