Gpc September 1996

gpc@gnu.de

12 participants
49 discussions

Re: SYSV vs BSD signal blues :-(
by Berend de Boer 11 Sep '96

11 Sep '96

> 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. I don't have handson experience with signals, but it seems to me that POSIX already did this. I suggest using signals according to the POSIX standard. And every unix box should come with some decent posix library these days. Groetjes, Berend.

1 0

Re: New win32 binaries almost done. please read.
by Berend de Boer 11 Sep '96

11 Sep '96

> So, shall I wrap these components in a seperate ZIP (windev.zip or > whatever) and upload them too? Great idea. Groetjes, Berend.

1 0

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

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 1996