Gpc September 1999

gpc@gnu.de

44 participants
93 discussions

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

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

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