Gpc

gpc@gnu.de

5400 discussions

SYSV vs BSD signal blues :-(
by J.J. van der Heijden 11 Sep '96

11 Sep '96

Hello, We've seen some signal related troubles when building the RTS lately. This is about what's happening: * GPC's RTS installs a signal handler to give pretty error messages when a signal is caught. This is ONLY implemented for BSD like systems, probably because Juki didn't have access to a SYSV style box. * SYSV and BSD differ in the number of signals and their meaning. * Some BSD boxes don't implement all signals > 16. (SIGXCPU etc.) * Some SYSV boxes implement (a range of) BSD-only signals, making it hard to dectect a true BSD box. I'm getting tired of writing ever more clever system identification routines that break on the next system I encounter. I think I'll just rewrite the signal related stuff in rts-rt0.c, implement some BSD/SYSV independant routines that ONLY mask signals that are actually present on the target system. How 'bout it? JanJaap --- The latest & greatest in software, hardware and manswear. Bono Vox (U2)

2 1

I don't unterstand __byte__ :-(
by Sven＠rufus.central.de 11 Sep '96

11 Sep '96

Hi all, the following example I've used to test the __byte__ and __short__ types. There was some trouble while using the GRX20-library (I'm working on a interface-unit) with conversion of different structures. Look at my sample and say me why I can't get the correct value from Bytes. program ByteTest; const arHex : array[0..$0f] of char = '0123456789abcdef'; max = 15; type WrkStr = String(255); var a32 : array[0..max] of Integer; a16 : array[0..max] of __short__ Integer absolute a32; a8 : array[0..max] of __byte__ Integer absolute a32; a_c : array[0..max] of char absolute a32; i : Integer; function hexa(number: Integer): WrkStr; var i : Integer; s : WrkStr; begin s := ''; for i := 1 to 8 do begin s := arHex[number and $0f] + s; number := number shr 4; end; hexa := ' $'+s; end; begin for i := 0 to max do a_c[i] := chr(i); for i := 0 to max do begin write(i: 3); write(ord(a_c[i]): 5); write(a8[i]: 10); if i mod 2 = 0 then write(a16[i div 2]: 10); if i mod 4 = 0 then write(a32[i div 4]: 16); writeln; end; for i := 0 to max do begin write(i: 3); write(hexa(ord(a_c[i]))); write(hexa(a8[i])); if i mod 2 = 0 then write(hexa(a16[i div 2])); if i mod 4 = 0 then write(hexa(a32[i div 4])); writeln; end; end. I'm using the DJGPP-GPC on MS-DOS and that's the output: 0 0 34560 256 50462976 1 1 34561 2 2 34562 770 3 3 34563 4 4 34564 1284 117835012 5 5 34565 6 6 34566 1798 7 7 34567 8 8 34568 2312 185207048 9 9 34569 10 10 34570 2826 11 11 34571 12 12 34572 3340 252579084 13 13 34573 14 14 34574 3854 15 15 34575 0 $00000000 $00000000 $00000100 $03020100 1 $00000001 $00000001 2 $00000002 $00000002 $00000302 3 $00000003 $00000003 4 $00000004 $00000004 $00000504 $07060504 5 $00000005 $00000005 6 $00000006 $00000006 $00000706 7 $00000007 $00000007 8 $00000008 $00000008 $00000908 $0b0a0908 9 $00000009 $00000009 10 $0000000a $0000000a $00000b0a 11 $0000000b $0000000b 12 $0000000c $0000000c $00000d0c $0f0e0d0c 13 $0000000d $0000000d 14 $0000000e $0000000e $00000f0e 15 $0000000f $0000000f Please don't quote the whole text !!! ___, ((__ o ,____)) V E N I

1 0

Re: External, C, AsmName, ...
by Peter Gerwinski 11 Sep '96

11 Sep '96

Hi everybody, According to Berend de Boer: > There is a translator for BP, mabe it's easy to adapt this one? Where is it? Since GPC is essentially BP-compatible now, perhaps we can just use it? Peter e-mail: peter.gerwinski(a)uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/

1 0

Re: External, C, AsmName, ...
by Berend de Boer 11 Sep '96

11 Sep '96

> But it would be a good idea to write a C->pas header converter. Right now, > you have to translate all headers before you can use them. There is a translator for BP, mabe it's easy to adapt this one? Groetjes, Berend.

1 0

Re: gpc for Solaris 2.5.1
by J.J. van der Heijden 10 Sep '96

10 Sep '96

On Tue, 10 Sep 1996 11:12:16 -0400 (EDT), M BAILEY <mbailey(a)cc.cst.cmich.edu> wrote: > >If someone sends me a merged source tree of GCC and GPC i would be happy to >compile them into a finished binary product and possible build solaris pkg's >out the resulting answers to that you can install them with out needing any >other utilities... > If you can build a ready-to-run compiler we would be happy to distribute it. There is no merged source tree: you put gpc and gcc in their own directory. Because I have not updated the INSTALL file for a while, I shall shortly explain what to do: (I assume solaris is properly supported bu GCC) If you extract gcc-2.7.2.tar.gz and gpc-1.2-2.7.2.tar.gz from the same location, you get gcc-2.7.2 and gpc-1.2-2.7.2 subdirs, which is just fine. 1) configure and build gcc: ./configure make CFLAGS=-O2 LDFLAGS=-s LANGUAGS=c If this fails, build gcc with -O0 and build a stage2 compiler with this the stage1 gcc, then go on (this is all explained in GCC manuals) 2) configure gpc: ./configure configure should be able to find the gcc directory if it is reasonably "close". If not, run configure --help and see what options you must give it. 3) build gpc: make CFLAGS=-O2 LDFLAGS=-s Read earlier notes about what to do if VPATH troubles strike (below). BSD/SYSV signal confusion (RTS won't build) *may* be avoided by using a newer configure (message posted this list a few minutes ago) If not, I would like to know whether configure decides you have SYSV or BSD (and if you know if this is incorrect, possibly see your <signal.h> and <sys/signal.h>. 4) A binary distribution can be created with the "make bindist" command. I'm not familiar with the habbits of solaris pkgtools, so you may have to tweak it by hand (you should know this). Hope this helps, JanJaap >Matthew S. Bailey > > >On Tue, 10 Sep 1996, J.J. van der Heijden wrote: > >> On Mon, 9 Sep 1996 21:44:50 +0200 (MET DST), >> Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> wrote: >> >> >Hi Phil, Brad, and Jan Jaap, >> > >> > stor-layout & friends ARE BACK ... >> > >> >> I wish that was true. Here is the results on my machine. >> >> maybe_find_function_data gpc-parse.o >> >> [...] >> >> dbxout_set_type_status gpc-decl.o >> > >> >I know that problem. It is a bug in make, Jan Jaap and I had >> >hoped to have worked around. The problem is that there are >> >language independend source files which exist in the GPC source >> >as well as in the GCC source. In Makefile, look out for >> >stor-layout.o, dbxout.o, ..., toplev.o. For some reason, >> >they are not recompiled correctly. >> > >> >> What happens precisely is that "make" has a VPATH: it looks for object code >> in the gcc object directory too. When your gcc object directory is >> identical to your gcc source directory, make thinks $gccbin/foo.o is >> uptodate because it depends $gccbin/foo.o on $gccsrc/foo.c (which it can >> see because $gccsrc=$gccbin) Then it doesn't build ./foo.o based on >> $gpcsrc/foo.c (mind $gpcsrc vs $gccsrc) >> >> To make it more complicated, VPATH behaviour of various "make" programs >> is different and some versions of GNU make have VPATH bugs. >> >> >To work around, you can create these *.o files and copy them >> >into the gcc directory, so "make gpc" will find and use them. >> > >> >> Use different directories for $gccsrc and $gccbin. >> Or delete the ones in $gccbin to force make to rebuild them. >> >> /janjaap >> --- The latest & greatest in software, hardware and manswear. Bono Vox (U2)

1 0

SYSV vs BSD confusion
by J.J. van der Heijden 10 Sep '96

10 Sep '96

Hello, There has been some confusion about detecting BSD style signals versus SYSV style. I have updated the configure script to be less fascist about BSD and hopefully this fixes the problems. Get it from: ftp://agnes.dida.physik.uni-essen.de/home/janjaap/updates/ Now, hopefully, FreeBSD is considered BSD again (Peter?) I think SunOS and Solaris are BSD variants too, right? If this still doesn't work, I would like to see your <signal.h> and <sys/signal.h> header files. The problem is that some SYSV systems #define these BSD signals but don't support them unless you link -lbsd, so I made BSD detection more strict (so strict in fact that FreeBSD was no longer considered BSD ;-) Hope this helps, JanJaap --- The latest & greatest in software, hardware and manswear. Bono Vox (U2)

1 0

Re: gpc for Solaris 2.5.1
by J.J. van der Heijden 10 Sep '96

10 Sep '96

On Mon, 9 Sep 1996 21:44:50 +0200 (MET DST), Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> wrote: >Hi Phil, Brad, and Jan Jaap, > > stor-layout & friends ARE BACK ... > >> I wish that was true. Here is the results on my machine. >> maybe_find_function_data gpc-parse.o >> [...] >> dbxout_set_type_status gpc-decl.o > >I know that problem. It is a bug in make, Jan Jaap and I had >hoped to have worked around. The problem is that there are >language independend source files which exist in the GPC source >as well as in the GCC source. In Makefile, look out for >stor-layout.o, dbxout.o, ..., toplev.o. For some reason, >they are not recompiled correctly. > What happens precisely is that "make" has a VPATH: it looks for object code in the gcc object directory too. When your gcc object directory is identical to your gcc source directory, make thinks $gccbin/foo.o is uptodate because it depends $gccbin/foo.o on $gccsrc/foo.c (which it can see because $gccsrc=$gccbin) Then it doesn't build ./foo.o based on $gpcsrc/foo.c (mind $gpcsrc vs $gccsrc) To make it more complicated, VPATH behaviour of various "make" programs is different and some versions of GNU make have VPATH bugs. >To work around, you can create these *.o files and copy them >into the gcc directory, so "make gpc" will find and use them. > Use different directories for $gccsrc and $gccbin. Or delete the ones in $gccbin to force make to rebuild them. /janjaap --- The latest & greatest in software, hardware and manswear. Bono Vox (U2)

2 1

Re: External, C, AsmName, ...
by J.J. van der Heijden 09 Sep '96

09 Sep '96

On Sun, 8 Sep 1996 00:34:02 +0200 (MET DST), Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> wrote: >According to Berend de Boer: >> Can we not simply see a C .h file as an interface-only module? I mean I can >> simply import a c .h file which gpc parses and all symbols defined in that >> header file are exported symbols? > >This would mean that GPC would have to parse C source. > >Remember that #include "foo.h" or (*$include "foo.h" *) just means >that GPC treads the file `foo.h' just if its contents were written >in our source file. A Pascal program using this mechanism would >in fact look like the following: > > Program Test; > > extern int foo; > > extern void ioctl (int fildes, int cmd, ...); > > begin > [...] > end. > >You don't actually want this. ;-) > No, I don't :) But it would be a good idea to write a C->pas header converter. Right now, you have to translate all headers before you can use them. janjaap --- The latest & greatest in software, hardware and manswear. Bono Vox (U2)

1 0

External, C, AsmName, ...
by Peter Gerwinski 08 Sep '96

08 Sep '96

Hello folks, (* This mail is somehow long. In short: I want to take the directives `Extern', `C', and `AsmName' *out* of GPC and extend the syntax of `External' instead. Okay? :*) as you know (?;-), we have the directives `External', `Extern' (same as `External'), `C', and `AsmName' in GPC for specifying external procedures. This is especially useful when using libraries written in C, for example: Procedure Foo; External; (* yields "Foo" *) Procedure ioCtl ( FilDes, Cmd: Integer; ... ); C; (* yields "ioctl" *) Procedure XOpenDisplay ( Name: __CString__ ); AsmName 'XOpenDisplay'; This turned out not to be enough; we need the same for variables. Actually we already have Var Foo: __external__ Integer; (* yields "foo", not "Foo"! *) but this does not cover cases where the external variable needs a name with a capital letter. As an intermediate solution, I implemented Var Foo: __asmname__ 'foO' Integer; (patched source is available on demand), but I think it is not the best way to implement these things. Now I am looking out for reasonable ideas. Does somebody know what the ISO/ANSI Standards say about this? My own thoughts follow. I would suggest to define as few directives as possible and to drop everything but `External' but extend its syntax to meet our requirements. A first approach could be Procedure foo; external; (* yields "Foo" *) Var x: Integer; external; (* yields "X" *) and Procedure foo; external 'foO'; Var x: Integer; external 'my_x'; but it would crash with Borland Pascal's use of `External' where the latter declaration would mean that Procedure foo is contained in a shared library named `foO'. Okay, so let's stay for the moment at Borland's syntax. In the same context they also define Procedure foo; external 'MySharedLib' index 42; and Procedure foo; external 'MySharedLib' name 'foO'; where `foO' would be the external name as defined in the shared library. My current idea now would be to define Procedure foo; external; (* yields "Foo" *) Var x: Integer; external; (* yields "X" *) plus Procedure foo; external name 'foO'; Var x: Integer; external name 'my_x'; to replace "AsmName 'foO'". Later we can extend this to allow a name of a shared library between `external' and `name'. Once doing this, it could also be nice to make directives out of the other C-style storage qualifiers, too. I mean I'd like to replace Var x: __static__ Integer; by x: Integer; static; y: __volatile__ Integer; by y: Integer; volatile; etc.. My plan is to do it in a way that things like Var static: Integer; would still work. I think it would *not* be a good idea to make Procedure foO; external; yield "foO", because (i) it would be difficult to implement and (ii) Pascal is a case-insensitive language, so everything outside string constants *must not* depend on casing at all. Please tell me your opinion about this. Yours, Peter e-mail: peter.gerwinski(a)uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter

2 1

gpc for Solaris 2.5.1
by brad＠shiloh.nimh.nih.gov 08 Sep '96

08 Sep '96

Hi, Is there a version of gpc built for Solaris 2.5? Or do you have any hints on getting the lastest source to compile under Solaris 2.5? Thanks Brad Zoltick NIH Email: brad(a)codon.nih.gov

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