According to richard.kerry@quantel.com:
Hello, Could somebody please either :
- Direct me to -
info -f gpc -n "Source structures" info -f gpc -n "Extensions"
or : 2. Send me - a comprehensive explanation of separate compilation using gpc, including examples that clearly show which bits are in different files and how the other bits pick up their definitions. And also including any alternate/non-standard/old-fashioned techniques that are still usable. I am working on a very large project, developed using Oregon Pascal. The separate compilation is done by each module (eg fred.pas) having a header file (eg fred.def) containing all the procedures, functions, types and constants it wishes the rest of the world to know about. All the routines in the header are 'external'. The modules all contain their own global variables; if any need to share, this is done by access procedures, or records shared via pointers. There is no module/unit/import/export/interface/implementation system involved. The modules are compiled individually, using #include (%include in Oregon) to
You can also use (*$i Foo *) or (*$include "foo.pas" *) or (*$include <foo.pas> *).
pick up any external definitions and references required, and then
linked.
I want to mechanically translate all these modules to gpc, so I'd prefer
a
mechanism, if there is more than one available, that uses a structure as similar as possible to the one we are currently using.
The closest approximation to Oregon Pascal (as you describe it) which is currently possible with GNU Pascal is to use the "somewhat simpler GPC modules" described in `info -f gpc -n Extensions'. will have the desired effect ... uh - sh** (sorry!) it does not work! :-( :-( While implementing other things I threw away this one. The reason is that this feature turned into a bug when using Extended Pascal Modules or UCSD/Borland Pascal Units. Okay, this "GPC specific module" is very close to yet another type of Module defined in the PXSC standard. The only difference is that PXSC wants the reserved word `global' in front of each declaration that is to be exported. That's certainly more reasonable than to export just everything (like GPC did until February 1997 or so). It is planned to implement these PXSC modules into GPC. So you can either wait until GPC will have PXSC modules or use UCSD/Borland-style Units or Extended Pascal Modules.
---------------------
Would it be possible to have a patch to re-enable the 'somewhat simpler' format, perhaps on a compiler switch ?
The formatter program I am modifying to do our Oregon-to-GPC conversion doesn't have a symbol table that can be used to determine which routines are internal or external, so I prefer the syntaxes (is that a word ?) that don't need only the externals to be marked (global), or all to be bunched together or the definitions to be duplicated again (interface, implementation). That is to say I'd prefer to be able to use such a syntax at this stage so I can pass over three hundred modules through the conversion and not require every one of them to be hand-tweaked. I'd consider this a first stage of conversion, and expect to gradually convert them all to proper (Extended) syntax over a period of time.
----------------------- When is PXSC syntax likely to be available ? -----------------------
What's fatal signal 11 ?
I've been changing my program to use separate compilation, rather than just $including all the bits of source it needs. I'm changing it to UCSD/Borland unit form, as I understand it from the Info and Peter's reply, and I get : 'gpc: Internal compiler error: program gpc1 got fatal signal 11' when I try to compile the unit.
'gpc fred.pas -o fred.o -v' gives :
Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux/2.7.2.3/specs gpc version 971001(2.7.2.3) /usr/local/lib/gcc-lib/i586-pc-linux/2.7.2.3/gpc-cpp -lang-pascal -v -nocharescape -undef -D__GNUC__=2 -D__GPC__=2 -D__GNUC_MINOR__=7 -D__ELF__ -Dunix -Di386 -Dlinux -D__ELF__ -D__unix__ -D__i386__ -D__linux__ -D__unix -D__i386 -D__linux -Asystem(unix) -Asystem(posix) -Acpu(i386) -Amachine(i386) fred.pas /tmp/cca13174.i GNU CPP version 971001(2.7.2.3) (i386 Linux/ELF) #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/local/i586-pc-linux/include /usr/local/lib/gcc-lib/i586-pc-linux/2.7.2.3/include /usr/include End of search list. /usr/local/lib/gcc-lib/i586-pc-linux/2.7.2.3/gpc1 /tmp/cca13174.i -quiet -dumpbase fred.pas -version -famtmpfile=fred.gpc -o /tmp/cca13174.s GNU Pascal version 971001(2.7.2.3) (i386 Linux/ELF) compiled by GNU C version 2.7.2.3. gpc: Internal compiler error: program gpc1 got fatal signal 11
I hope you can help.
Richard.