- Gpc - gnu.de

Re: threads status in GPC
by Paul Davidson 07 Jun '04

07 Jun '04

However, I'm currently working on a (pthread-based) standard unit for GPC multithreading, so if you aren't in a hurry, maybe I can offer you a solution within a few weeks. :-) Please!

1 0

--language=Pascal
by Adriaan van Os 03 Jun '04

03 Jun '04

The question rises whether Pascal is written with an uppercase "p" or not [G4:~/gnu/testgpc/adriaan] adriaan% gpc -c --language=Pascal hello.pas [G4:~/gnu/testgpc/adriaan] adriaan% gpc -c --language=pascal hello.pas gpc: language pascal not recognized So, gpc expects an uppercase "p". On the other hand: - ada, fortran and c are written in all lowercase (see the man pages for gcc) - gdb writes Pascal lowercase - gp writes "--pascal=OPTION" lowercase. Because of this, it came to a surprise to me that --language=pascal didn't work (and it took me some time to find out that --language=Pascal did). (can't remember if I reported this before) Regards, Adriaan van Os

3 3

Version information
by Frank Thomas Braun 03 Jun '04

03 Jun '04

Could anybody kindly uodate the Webpage http://www.gnu-pascal.de/gpc/Current-version.html#Current%20version Frank BraunFrank Braun Rechenzentrum Universitaetsstrasse 31 D-93053 Regensburg Germany Tel.: +49-941-943-4891 email: frank.braun(a)rz.uni-regensburg.de

2 1

GP
by Frank Heckenbach 03 Jun '04

03 Jun '04

I've put a new version of GP with the minor changes discussed here at <http://gnu-pascal.de/contrib/frank/misc/gp-0.55.tar.gz>. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

13 45

Installation problem with gpc (djgpp, Windows XP)
by Frank Thomas Braun 01 Jun '04

01 Jun '04

I am working successfully with a gpc installation from 2002 and wanted to update to the current version. So I downloaded from "GNU Pascal download area: Current" / binaries / DJGPP (http://www.gnu-pascal.de/binary/djgpp/) all files. After unzipping and a successful installation (gpc -v is working) a try to compile even simple files results in: D:\xxy>gpc HALLO.PAS gpc.exe: Internal GPC problem: internal option `--amtmpfile' not given I read and followed any instructions of http://www.gnu- pascal.de/gpc/Installing-GPC-on-DJGPP.html set DJGPP=c:\gpc\djgpp.env Additions to djgpp are entered and correct. (My first installation of gpc together with djgpp was very problematic too and I succeeded to install a working compiler only after help from the mailing list. That is the reason, that I didn't update the compiler). Frank Braun Frank Braun Rechenzentrum Universitaetsstrasse 31 D-93053 Regensburg Germany Tel.: +49-941-943-4891 email: frank.braun(a)rz.uni-regensburg.de

3 7

Re: gpascal (was: cgp? (was: GP ;-))
by Tom Verhoeff 01 Jun '04

01 Jun '04

And what about gpascal This is slightly longer, but leaves (almost) nothing to the imagination. We don't need a c in the name for compiler, do we? Tom

1 0

GNU Modula 2 binary for MinGW searched
by Gerrit P. Haase 31 May '04

31 May '04

Hello, I'm looking for a binary package of GNU Modula 2 for MinGW, is there one available? Gerrit -- =^..^=

1 0

Module madness
by Neil Santos 31 May '04

31 May '04

Hi guys. I've been scratching my head for about two hours now, trying to figure out what kind of incantation I need to do in order to compile a module whose interface and implementation sections reside in different files. -STOP- Okay, I've composed two other mails before this (with the first couple of paragraphs being part of the second), and I've finally found what I needed. It turns out that, in order to compile a module that has its interface and implementation sections in two different files, one has to compile them this way: gpc -c --interface-only TAttributes.int.pas gpc -c --implementation-only TAttributes.imp.pas --include TAttributes.int.pas Now, my question is, why do we need to include the interface part with the implementation part manually? Can't we tell gpc where to look, to find what it needs? The --unit-path command-line option did not help, and gpc warned about using --auto[make/build]. Also, --unit-destination-path doesn't work for me; I have compile from inside the directory where I want the .gpi and .o files to be placed. Using (as per gpc -v): gpc version 20040516, based on gcc-3.3.3 Also tried with 20030830 (both with gcc 3.2.2). Anyway, back to those unit tests. :D -- Political Dissident Neil Santos Free Software Advocate Jabber: nsantos(a)jabber.org Please avoid sending me attachments encoded in secret formatting. See http://www.fsf.org/philosophy/no-word-attachments.html

5 9

gp-0.54 released
by Frank Heckenbach 29 May '04

29 May '04

I have uploaded the first public beta version of GP to <http://gnu-pascal.de/contrib/frank/misc/gp-0.54.tar.gz>. GP is a utility to automate the building of Pascal programs using the GPC compiler. It is the intended replacement for GNU Pascal's problematic automake feature. If you have been using automake, please try building with GP instead. When GP works sufficiently, it will be included with GPC in one of the next releases, and automake support will later be dropped from GPC. If you only ever used GPC without automake (e.g., using self-written Makefiles or otherwise manually) and do not plan otherwise, you probably do not need GP. Please read the included files REAMD and INSTALL, as usual. The GP Manual is contained in `gp.info' which you can read with any info reader. You can also make a printable documentation with `make dvi' if you have texi2dvi installed or `make pdf' using texi2pdf. Quick start: * Use `gp' instead of `gpc --automake --executable-file-name'. Most other GPC options can be used the same way with GP. * If the source file given on the command line is a unit or module, GP recognizes this automatically and does not try to link it, so you don't have to give the option `-c'. * If your compilers are not called `gpc' and `gcc' you can set `PC' and `CC' wither on the command line or as environment variables. This is mostly the same you would do when using `make'. * Note the new `.gpd' files, e.g. if you want to clean a build directory. (But you might want to consider using `gp --clean' or `gp --clean-objects' for this purpose.) The main features of GP are: * Automatically finds all dependencies, units used and include files as well as C, assembler and object files and libraries referenced in `{$L}' and `{$R}' directives. * Recompiles everything when necessary (no need to give `--automake'). * Avoids unnecessary recompilations if only the implementation of a unit used has changed since the last compilation, by comparing a MD5 value of the interfaces of units. Recompilation is even avoided if only comments in the interface have changed, but not when they influence line numbers - since the GNU tools store line number information in object and other files, this does constitute a small difference. * Supports `--autobuild' to recompile everything. * Does not use GPC's buggy automake feature, so it should work also on systems where automake doesn't. Also, in many cases, it will use less total memory than GPC's automake because it calls the compiler iteratively rather than recursively. * Recognizes and supports transparently cyclic unit dependencies (where, naturally, at least one dependency in each cycle must be in the implementation rather than the interface). * Uses the base name of the main program's file name as the executable name by default, rather than `a.out' (no need to give `--executable-file-name' or `-o foo', but these options are also supported). In the strange case that you want your output file to be called `a.out', you can use `-o a.out'. * Does not try to link a unit given on the command line (no need to give `-c' for units, but `-c' is also supported in case you want to compile, but not link, a program). * Tries appending a `.pas', `.p', `.pp' or `.dpr' suffix (in this order) to the file name given on the command line when necessary, i.e. you can invoke it as `gp foo.pas' or just `gp foo'. * Calls `gcc' rather than `cc1' (which GPC would call) to compile C files, so it also works if the versions of the installed GCC compiler and the backend the installed GPC is based on don't match. * Supports GPC's path options (`--unit-path', `--object-path', `--unit-destination-path', `--object-destination-path', `--executable-path') transparently, also for units given on the command line (where GPC ignores `--unit-destination-path'). * Supports `--include-path' and `--library-path' which work the same way as `-I' and `-L', respectively, but can be given multiple directories at once. * Uses all unit and object paths as include paths automatically, to simplify using units or C files with includes in other directories. * Stores the compiler version, target platform and options given (together with other dependency information) in files with suffix `.gpd' ("GNU Pascal Dependencies") and recompiles files when the compiler version, platform or options differ from those they were compiled with. * Compiles the main program to an object file before linking, so it does not have to be recompiled when only a unit's implementation changes, and you have it available in case you want to link it explicitly. * The options `--progress-messages' and `--progress-bar' are extended to give information on the progress of the compilation of the whole project (not only of a single source file as when calling `gpc' directly). Some limitations: * The handling of default options and simpler usage of dialect options (as discussed on the mailing list) is not yet included. This will be added in a later revision. However, this does not have any influence on the main functionality of building Pascal programs (you just have to give your options explicitly, as you do when calling `gpc'). * Extended Pascal module support is experimental. * More than one unit/module/program in one source file is not supported. * Modules with interface and implementation parts in separate source files are not supported. This seems to be difficult to do at all, since the information where to find the implementation module is simply missing from the source. If you have any good ideas on this topic, please send them to the GPC list. * Other more or less strange things may not be supported. If you find anything, let me know, so I can decide whether to support it or to document that it's not supported. GP is Copyright (C) 2000-2004 Free Software Foundation, Inc. It was written by Frank Heckenbach <frank(a)pascal.gnu.de>. It is distributed under the terms of the GNU General Public License, version 2. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

8 25

`MacTypes' could not be imported
by Adriaan van Os 28 May '04

28 May '04

Arnaud Gautier wrote: > HI, > I think I have all installed ok on my mac (osX 10,2): > jack:~/gpc-332d1-build arnaudgautier$ gpc -v > Reading specs from > /Developer/Pascal/gpc332d1/lib/gcc-lib/powerpc-apple-darwin/3.3.2/> specs > Configured with: ../gpc-332d1/configure --enable-languages=pascal,c > --prefix=/Developer/Pascal/gpc332d1 --enable-threads=posix > --target=powerpc-apple-darwin > Thread model: posix > gpc version 20030830, based on gcc-3.3.2 > > > But when I make: (t is my file) > jack:~/gpc-332d1-build arnaudgautier$ gpc t.pas > > I get: > t.pas:1: error: module/unit interface `MacTypes' could not be imported > > should be a simple stuff, but I just start gnu 1. Specify --automake (see <http://www.microbizz.nl/gpcfaq.html>) 2. Download and install Apple’s Universal PInterfaces, as ported to GNU Pascal (see <http://www.microbizz.nl/gpc.html>) 3. Specify --unit-path=/Developer/Pascal/GPCPInterfaces/ Hope this helps. Please direct further questions to the gpc mailing list. Regards, Adriaan van Os

1 0