Gpc

gpc@gnu.de

5400 discussions

More Red Hat troubles with binary distribution
by Ken Linder (KC7RAD) 16 Dec '98

16 Dec '98

Hi again all, Is there anyone out there using RH 5.0, 5.1, or 5.2 that is able to use the GPC binary to compile pascal code? I have a Slackware install @ home that runs without a problem but I just installed RH 5.1 @ work and have the same old problems I used to have. If I recall correctly, a solution was never found. Hints??? Ideas???? Solutions??? Anything would be appreciated!!! TNX Ken Linder kc7rad(a)vegasnet.net

3 2

re: link problem with gpc beta
by Russ Whitaker 16 Dec '98

16 Dec '98

Ross Cartidge wrote about problem with gpc and gcc 2.8.1 had same problem earlier do a make clean make CFLAGS="-O2" LANGUAGES=pascal make CFLAGS="-O2" pascal.install and the problem will go away Russ

1 0

Re: link problem with gpc beta
by Frank Heckenbach 15 Dec '98

15 Dec '98

Ross Cartlidge wrote: > I just compiled the version beta version of gpc with gcc 2.8.1. > It compiled and installed fine but when I tried to compile a pascal > program the following were undefined:- > > `_p_gpc_locase' > `_p_gpc_upcase' > `_p_strlen' > > > I couldnt find them in the source - where are they :-) They should be in rts/gstrings.pas, and go into libgpc.a when compiling GPC. Which beta version exactly did you get, and are you sure you use only files of the same version together (and not perhaps unintentionally a previously installed libgpc.a)? This might apply especially if you're using DJGPP where AFAIK there was a directory restructuring recently. When in doubt, you might want to remove all instances of libgpc.a and install again. Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

link problem with gpc beta
by Ross Cartlidge 15 Dec '98

15 Dec '98

I just compiled the version beta version of gpc with gcc 2.8.1. It compiled and installed fine but when I tried to compile a pascal program the following were undefined:- `_p_gpc_locase' `_p_gpc_upcase' `_p_strlen' I couldnt find them in the source - where are they :-) -- Mr Ross Rodney Cartlidge, Data Network Manager, Information Technology Services Building H08, The University of Sydney, NSW, 2006, Australia R.Cartlidge(a)isu.usyd.edu.au Ph: +61 2 9351 5506 Fax: +61 2 9351 5001 Mobile: +61 412 551 283

1 0

Unsubscribe
by Donohue, Pat 14 Dec '98

14 Dec '98

Unsubscribe

1 0

Re: enumerations in units problem
by Sam B 13 Dec '98

13 Dec '98

Frank Heckenbach replied: >It has been >fixed by now, and your test program will compile with the next GPC >version. Thanks for the report, anyway. Has this next version been released? I have searched the net and the latest version I could find any reference to was the one I am already using (19980830). If a new version has not been released, is there somewhere I can get a patch for this particular problem? ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

1 0

Re: Why won't this work?...
by Frank Heckenbach 12 Dec '98

12 Dec '98

Orlando Llanes wrote: > I get the following error with the program listed below: > > 0c:/nano/tmp2.exe: could not read all the data from file `tmp.txt' in > `BlockRead' (#414) > > Seems that it prints the first character, but then ends unexpectedly. The > file tmp.txt is below the program. This seems to be due to a DJGPP bug (fflush() clobbers the file position -- or is this allowed, any standard experts here?). For now, I put a work-around in the RTS for Dos systems. Perhaps this should better be done by an autoconf test, but I don't know how to do this (any autoconf experts here?). -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

3 2

Why won't this work?...
by Orlando Llanes 11 Dec '98

11 Dec '98

I get the following error with the program listed below: 0c:/nano/tmp2.exe: could not read all the data from file `tmp.txt' in `BlockRead' (#414) Seems that it prints the first character, but then ends unexpectedly. The file tmp.txt is below the program. {--- Cut here for tmp2.pas ---} program Tmp2; var F : File; Ch : Char; begin Assign( F, 'tmp.txt' ); Reset( F, 1 ); while not EOF(F) do begin BlockRead( F, Ch, 1 ); Write( Ch ); end; Close( F ); end. {--- Cut here ---} {--- Cut here for tmp.txt ---} 0x3dF 0X3Af ++ TestOJL, ++= 1e0 1.2 22.3e-3 309 , _1234567890_1234567890_1234567890_1234567890_1234567890_1234567890 _Testing_123 This_is_a_really_long_variable_in_fact_only_part_of_it_will_be_kept_the_rest_will_be_ignored ' ' '' '''' print( 'foo' ) foo 'a string' 'another string' __test__ == -= << >> >>= if main print() endmain {--- Cut here ---} See ya! Orlando Llanes "Meine Damen und Herren, Elvis hat soeben das Gebaeude verlassen!" "Look out fo' flyeeng feet" O__/ a010111t(a)bc.seflin.org \/|____. O <__. \/\> / \ ____________|___\______ http://ourworld.compuserve.com/homepages/Monkey414

1 0

unsubscribe
by Harald A. Irmer 11 Dec '98

11 Dec '98

unsubscribe

1 0

Re: enumerations in units problem
by Frank Heckenbach 11 Dec '98

11 Dec '98

Sam B wrote: > Greetings, > I am having a rather strange problem when using an enumerated > type declared in a unit. If that type is used in a second unit, > and also in a third that uses both the first and second, the > type cannot be used as a parameter to a function. This probably > isn't a very good description Actually, it is ;-), because this was a notorious bug. It has been fixed by now, and your test program will compile with the next GPC version. Thanks for the report, anyway. Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

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