- Gpc - gnu.de

gpc on Mac OS X notes
by Adriaan van Os 07 Aug '04

07 Aug '04

The following relates to using gpc on Mac OS X with the tools that come with "Xcode 1.5" ------------------------------------------------------------------------ --- 1. There was a report that gpc issues the following error message: 'gpc: installation problem, cannot exec `c++filt3': No such file or directory" The Xcode installer doesn't install c++filt3, I reported this as a bug to Apple. The obvious solution is to type the following on the terminal command line: [G4:~] adriaan% sudo ln -s -f /usr/bin/c++filt /usr/bin/c++filt3 2, I noticed that "otool" crashes with a signal 11 when doing disassemblies. Of course, this doesn't influence gpc compilations as such. 3. The new "as" assembler and "ld" linker provide support for "smart-linking" (dead-code stripping), which results in smaller executables. This is a very exciting feature and I am doing my best to make this work with gpc. 4. For reasons of "higher policy" the new tools cannot be installed on Mac OS X 10.2.x. If you don't want to buy Mac OS 10.3, I suggest you download the latest Apple assembler and linker from <ftp://gcc.gnu.org/pub/gcc/infrastructure>. Ironically, the tools are more up-to-date than the ones in the "Xcode 1.5" download. Installer package <ftp://gcc.gnu.org/pub/gcc/infrastructure/cctools-528.dmg> Source code <ftp://gcc.gnu.org/pub/gcc/infrastructure/cctools-528.tar.bz2>. 5. The "Xcode 1.5" tools download is 372 MB, which is not nice with a slow modem. The "Europe" mirror is so slow that the download will take at least 5 days (...). The "USA 2" mirror is reasonably fast. Regards, Adriaan van Os

1 0

position independent code generation
by Igor Marnat 03 Aug '04

03 Aug '04

Hello dear List! I use GPC for ARM7TDMI processor working under uCLinux of 2.26 version. I would like to use -fpic option to decrease memory usage (my filesystem lies in SDRAM so load program to RAM is just memory waste), but when I start program built with -fpic, it tells me "undefined instruction". I searched via the mail list but it seems to me that there is no great interest to this problem (I mean -fpic usage). I use arm-elf-gcc (2.95.3) and arm-elf-gpc (20021111) built together. It's a bit old but it's the only version I've managed to build for arm-elf- platform. Anyway, the problem is: when I build hello-world-program written on C using arm-elf-gcc with "-fpic -msingle-pic-base", it works fine. When I try to build hello-world-program written on Pascal using arm-elf-gpc and the same flags, it doesn't work and tell me "undefined instruction". I looked into map file, created by linker, and there is strange issue: when I use -fpic options, C linker uses libgcc.a located in /usr/local/bin/../lib/gcc-lib/arm-elf/2.95.3/fpic/msingle-pic-base/, but Pascal linker always uses /usr/local/bin/../lib/gcc-lib/arm-elf/2.95.3/ whether the program was built with -fpic option or not. So I've thought that the problem is in libgpc.a and tried to rebuild it (and all GPC). I didn't find any options about -fpic in Pascal configuration files. I tried do add "-fPIC -msingle-pic-base" to the CFLAGS and GPC_FLAGS variables in the Makefile in p/rts directory of Pascal sources and rebuild GPC, but the program still doesn't work. What may be the problem, is the -fpic option supported now in Pascal? Perhaps, I should use newer version of GPC or configure it in other way than I did? Best regards, Igor Marnat mailto:marny@rambler.ru

1 0

gpc-20040516 released
by Frank Heckenbach 23 Jul '04

23 Jul '04

I have uploaded a new beta version of GPC to <http://www.gnu-pascal.de/beta/>. This version contains mostly bugfixes and only few and smaller new features. Therefore, if no serious bugs will be found in the next fews days, it can be recommended for production work. Waldek Hebisch and I are currently working on some larger changes, including qualified identifiers, range checking and support for gcc-3.4.0. An alpha version with these changes, which might be less stable, will probably be released in a few weeks. BUILD NOTE: If you modify the GPC sources, you now need bison-1.875c and flex-2.5.27 (<http://lex.sourceforge.net>) to rebuild. These versions must be matched exactly. Newer flex versions, in particular 2.5.31, might work as well, but contain a known unportability, so I did not test them, and I recommend 2.5.27. (Other programs such as yacc and lex instead of bison and flex also will not do.) I have included the files generated by bison and flex in the distribution (also in the "minimal" distribution), so you should not need these tools when you only want to build GPC. NOTE: The `Pipe' unit was renamed to `Pipes' because of a name conflict. Unfortunately, this requires a small change to all programs that use this unit. New features: * arithmetic expressions now work as lower array/subrange bounds (fjf248.pas, fjf293.pas, fjf336.pas, fjf346a.pas, fjf622.pas) * records/objects with many fields are processed faster * parameters of procedural types now support Standard Pascal procedural parameters, conformant/open arrays and `type of' inquiries (fjf939*.pas) * empty parameter lists can be written as `()' (chief54*.pas, delphi6*.pas) (D) * GMP unit: `mpf_sin', `mpf_cos' * the test suite output is now by default stored in DejaGnu compatible files `gpc.log' and `gpc.sum' in the `p/test/' directory; other available test targets are `pascal.check-short' and `pascal.check-long' (@) * new options `-W[no-]dynamic-arrays' (fjf931*.pas) * new argument to `_p_initialize' (@) * new function `UMask' * new option `--no-debug-source' * new lexer (no directly user-visible difference, but should allow for better handling of lexer-based problems in the future) Fixed bugs: * `pow' and `**' are really EP conformant now (in particular `x pow y' and `x ** y' are an error if x = 0 and y <= 0) (emil27*.pas) * `protected var' parameters must only accept references (unlike `const' parameters) (gale5*.pas) * `pack' must not pack the component type of arrays (fjf940[b-e].pas) * in some circumstances packed fields were allowed as `var' parameters (fjf940a.pas) * bugs with nonlocal gotos out of routines declaring file variables (nonloc*.pas) (fix involved a change in the internal representation of file variables) * 'foo'#42 must not be rejected in `--borland-pascal' (chief53.pas) * `--implementation-only' didn't work correctly (bo4-19.pas) * messages referring to object methods now point to the method declaration rather than the end of the object type declaration * initializers for types containing nested schemata now work (fjf914*.pas) * various smaller bugs 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

11 50

Re: problem building GPC 20040516 on AIX - continued
by Gert Doering 21 Jul '04

21 Jul '04

Hi, On Wed, Jun 16, 2004 at 08:30:38PM +0200, Frank Heckenbach wrote: > Gert Doering wrote: > > > I'm trying to build the gpc-20040516 "beta" snapshopt with GCC-3.3.x on > > AIX 5.1. GCC-3.x itself supports AIX 5, I have a working version on > > the system (binary install, not compiled-it-myself). [..] > > the line 511 is this one: > > > > TARGET_CPU_CPP_BUILTINS (); > > > > ...which fully escapes me as for why it might not compile...!?? [..] > Unless you need very particular system conditionals (Pascal programs > usually don't), just insert the line > > #define rs6000_cpu_cpp_builtins(foo) > > in lang.c. Thanks for your quick reply. Unfortunately, I didn't see it before today because my spam filter didn't know about the GNU Pascal list yet (all e-mails with unknown To:/CC: headers are quarantained as "maybe spam". Stupid me.) I will try this approach over the weekend. In the meantime, I tried something else - gcc-3.2.3 with gpc-20040516, again on AIX 5.1 and additionally on AIX 5.2 (in case AIX 5.1 is broken). The effect is quite different here. It builds all of xgpc and the libgpc.a just fine, but then crashes in trying to build "binobj". The error is this: gmake[2]: Entering directory `/s1/gpc-build/gcc/p/utils' ../.././xgpc -B../.././ -I../rts --automake --executable-file-name -W -Wall -Wmissing-prototypes -Wmissing-declarations -g -O2 --executable-path=. --unit-path=/s1/gcc-3.2.3/gcc/p/rts --unit-path=/s1/gcc-3.2.3/gcc/p/units `cat needed-options` "/s1/gcc-3.2.3/gcc/p/utils/binobj.pas" collect2: library libgpc not found gmake[2]: *** [binobj] Error 1 gmake[2]: Leaving directory `/s1/gpc-build/gcc/p/utils' gmake[1]: *** [pascal.utils] Error 2 gmake[1]: Leaving directory `/s1/gpc-build/gcc' If I change the -B invocation to use an absolute path, the library is found, but the (AIX) ld doesn't really like the result either: ../.././xgpc -B/s1/gpc-build/gcc/ -I../rts --automake --executable-file-name -W -Wall -Wmissing-prototypes -Wmissing-declarations -g -O2 --executable-path=. --unit-path=/s1/gcc-3.2.3/gcc/p/rts --unit-path=/s1/gcc-3.2.3/gcc/p/units `cat needed-options` "/s1/gcc-3.2.3/gcc/p/utils/binobj.pas" ld: 0711-317 ERROR: Undefined symbol: Tempdirectory.1 ld: 0711-317 ERROR: Undefined symbol: Tempstr.4 ld: 0711-317 ERROR: Undefined symbol: Buffer.8 ld: 0711-317 ERROR: Undefined symbol: Zero.3 ld: 0711-317 ERROR: Undefined symbol: Epoch.6 ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status I've checked with "nm", and it looks like all the stuff should be there: gd@hilb3:/s1/gpc-build/gcc/p/utils> nm ../../libgpc.a | grep Tempdir Tempdirectory.1 U - Tempdirectory.1 d 37956 8 Tempdirectory.1.P8 d 37952 4 Tempdirectoryset.0 d 37948 4 Since I had the nagging suspicion that there might be something in the pascal libraries that the system ld doesn't understand, I tried installing the GNU binutils, ./configure'd again, and rebuilt. Built bombed in libgcc (gcc created stuff that gas didn't like). Removed gas, ./configure'd again, rebuilt. Same error as above (collect2 not finding libgpc). Trying again with absolute paths and GNU ld linked into the "-B" directory as "real-ld" led to a new error: ../.././xgpc -B/gnulocal/src/gcc-3.2.3/gcc/ -I../rts --automake --executable-file-name -W -Wall -Wmissing-prototypes -Wmissing-declarations -g -O2 --executable-path=. --unit-path=/gnulocal/src/gcc-3.2.3/gcc/p/rts --unit-path=/gnulocal/src/gcc-3.2.3/gcc/p/units `cat needed-options` "binobj.pas" /gnulocal/src/gcc-3.2.3/gcc/libgpc.a(filename.o)(.tc+0x4):filename.pas: undefined reference to `Tempdirectory.1' /gnulocal/src/gcc-3.2.3/gcc/libgpc.a(filename.o)(.tc+0x4):filename.pas: undefined reference to `Tempstr.4' /gnulocal/src/gcc-3.2.3/gcc/libgpc.a(filename.o)(.tc+0x4):filename.pas: undefined reference to `Buffer.8' /gnulocal/src/gcc-3.2.3/gcc/libgpc.a(time.o)(.tc+0x4):time.pas: undefined reference to `Zero.3' /gnulocal/src/gcc-3.2.3/gcc/libgpc.a(time.o)(.tc+0x4):time.pas: undefined reference to `Epoch.6' collect2: ld returned 1 exit status (the -B path is different from the example above, because it's a different system - the other one doesn't have the GNU binutils installed yet - but don't let that confuse you) --> so it seems that actually the library itself has unresolved symbols, and not the "binobj.pas" program it tries to link. "ranlib" doesn't help either. Any further ideas how to tackle this? The whole symbol format confuses me - being a C programmer, I'm used to errors about "_crypt" not found, but not without a "_" and neither with trailing numbers... thanks again, gert -- Gert Doering gd(a)medat.de MEDAT Muenchen Tel: 089/126808-0 Fax: -50

4 19

www.gnu-pascal.de up again
by Eike Lange 19 Jul '04

19 Jul '04

Hi Folks! The server is up again. Latest uptime was 394 days :-) The mainboard becomes too warm or the BIOS detects the wrong temperature. However, if you are a "contributor" with files on this server, please make a private backup. I'm going to backup the complete files to a cdrom. If someone would like to contribute a new server hardware, you are welcome. ;-) Please send me a private mail in this case. Eike -- http://www.gnushi.de

1 0

www.gnu-pascal.de down!
by Eike Lange 18 Jul '04

18 Jul '04

Hi folks! Currently our GPC-Server is down. As I do not know the reason, I cannot tell you the time to fix. I hope it will be soon. Yours Eike -- http://www.gnushi.de/

1 0

ANNOUNCEMENT: Unit for multithreading (and some more stuff)
by Markus Gerwinski 18 Jul '04

18 Jul '04

Markus Gerwinski proudly presents: GNU Application Libraries for Pascal, in short GNUALP, pre-release 0.1.4. The current status of the package contains units for - exception handling, - standard collection types (lists, hashtables etc.), - system time and calendar functions, - and last but not least: multithreading. You can download a tarball with the current sources from http://www.markus.gerwinski.de/gnualp/gnualp-0.1.4.tar.gz. The library is tested on SuSE Linux 8.0, 9.1, and Windows XP with MinGW. You can install the tarball just the usual way, i.e. unpack it into your source directory, then run "./configure", "make", "make install", and everything will be in place. The API units will then be installed to a directory named /usr/local/units/gnualp-0.1. This also generates a shared library, libgnualp.so, which you'll have to link against. E.g. to compile a program foo.pas which uses the GNUALP library units, your gpc compiler call will have to look like this: gpc --automake --unit-path=/usr/local/units/gnualp-0.1 foo.pas -o foo -lgnualp This library is work under development and far from being complete, so it is all undocumented up to now. However, since several folks seemed to have a pressing urge for multithreading, I'll give a short introduction here on how to use the resp. features of the library: - Include `AlpThreads' into the uses clause of your program. Declare any threads you want to start as vars of type `pThread'. - To run some simple procedure as a thread, give it a parameter list like this: Procedure doingSomething ( thread: pThread; data: pointer ); You can then from anywhere in the program create a thread object for this procedure with the following statement: someThread:= new ( pSimpleThread, start ( doingSomething, nil ) ); The thread then starts running immediately and will automatically dispose itself after it is ready. It can be stopped from within the doingSomething procedure using the command `thread^.stop'. In this case, it will also dispose itself. For more sophisticated thread handling, derive an object type from the abstract tThread type and override the `work' method to do whatever the thread is supposed to do; if need be, you can also override the `cleanup' method. This one's always executed at the end of the thread, no matter if it was regularly ended or `stop'ped in-between. - Mutexes and semaphores are represented by the tMutex and tSemaphore object types. To create e.g. a mutex, just call mutex:= new ( pMutex, init ); To lock the mutex, call `mutex^.lock'; to unlock it, call `mutex^.unlock'. To dispose it after use, call `dispose ( mutex, fini )'. Just as simple. :-) Semaphores work in an analogous way; they only require an integer parameter in their constructor to determine the maximum count of threads they may be accessed by. For usage examples, see the files simplethreads.pas, mutexes.pas, and semaphores.pas in the demos/pas subdirectory of the gnualp package. They aren't documented or commented either, since I've only set them up as a test for myself, but I hope the code isn't too difficult to read. :-} Regards, Markus

1 0

gpc+gcc-3.3.4
by Russell Whitaker 18 Jul '04

18 Jul '04

Hi downloaded gcc-3.3.4 today. building gcc-20040516 with Waldek's Make-lang.in patch, configure --enable-languages=c,c++,pascal test results: Unsupported: regextest.pas # of tests 3910 # of expected passes 3909 # of unsupported tests 1 gpc version 20040516, based on gcc-3.3.4 Good. Thanks, Russ

4 5

gpc-20040516, Mingw, gcc-3.4.1, and update27h.diff #2
by Prof A Olowofoyeku (The African Chief) 17 Jul '04

17 Jul '04

Hi again Following on my earlier post, I have discovered something else. "pascal.install" did not install "gpc1.exe". I had to copy it manually to its correct location. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

1 0

GPC and Threads
by Jose Pascual 15 Jul '04

15 Jul '04

Hi, I'm working in port some of my little application to linux. All of my application has been writting in pascal. My porting to linux is going ok but some of them use threads. I have read in GPC lists there are people working in a thread unit for GPC, aren't you? Could someone share this unit with me? I could help to debugging it. thank you so much best regards Jose Pascual

2 1