Gpc December 1999

gpc@gnu.de

26 participants
45 discussions

Re: Problem with some strings procedures.
by Frank Heckenbach 22 Dec '99

22 Dec '99

Alfredo Cesar Fontana wrote: > Hello: > > In this example: > > PROGRAM STR; > {$IFDEF BAD} > TYPE P=PROCEDURE(S:STRING); > {$ENDIF} > VAR S:STRING; > BEGIN > S:='123'; > DELETE(S,1,1); > WRITELN(S) > END. > > with GPC v 19990118 (DJGPP and Linux) and GPC v 19990609 > > when I "gpc -o str str.pas" > I get: "23", the delete procedure works fine. But > if I "gpc -o str str.pas -DBAD" > then I get: "123". I lost my delete procedure :'-( Thanks for the report, I'm adding it to the To-Do list and testsuite (fontana1.pas). I've traced the problem to parse.y:2196, but I can't fix it because there are strange things going on in that area which I don't understand. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

Re: Help for gpc install
by Frank Heckenbach 22 Dec '99

22 Dec '99

"Khimenko Victor" wrote: > I'm not know if it's right thing to do. Internal gcc libraries are installed > in <prefix>/lib/gcc-lib/<platform>/<version>/ on purpose and not just since > "so happens" (libstdc++ is installed there as well while shared version > of library is installed in <prefix>/lib :-) On my gcc-2.95.2 installation, both libstdc++.{a,so} are symlinks to the ones in /usr/lib. > libgcc.a depends on libc, BTW. "C" part of libgcc.a is more or less stable > now (AFAIK anyway). So usually it works. But "C++" part (at least C++ part!) > of libgcc.a is in constant flux. And yes, if you have C++ library compiled > with gcc 2.8.1 you can not use it with gcc 2.95.2 (even if this library does > not use libstdc++ library and it's very rare C++ library then :-) Only two > days ago I helped guy to compile some program based on C++ library compiled > in RedHat 5.2 under RedHat 6.1. He ended with installation of egcs 1.0.3 from > RedHat 5.2 ... GPC does not use the C++ part of libgcc.a, so we can exclude this for now. The question is, is it possible (without subtle bugs) to link files compiled with, say GPC based on gcc-2.8.1 and files compiled with gcc-2.95 (in which case the libgcc.a used would be wrong for either of them)? Since GPC uses the same backend as GCC, this is equivalent to the question whether you can link C files compiled with gcc-2.8.1 and gcc-2.95, which is the situation if you install gcc-2.95 on your system while your libraries have been compiled with gcc-2.8.1. Since I didn't read in the GCC docs that I should recompile all my libs after installing a new GCC version, I still can't believe that there's a problem (as far as C and Pascal are concerned)... > P.S. Do you think much about possible usage of libgpc.a with different > version of gpc while developing gpc/libgpc ? No. > Why do you think gcc development > is different ? Because GCC is a stable product and many libraries compiled with it are distributed, while GPC is alpha/beta... Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

Unit ports.pas, InPortW
by Opie Pecheux 22 Dec '99

22 Dec '99

Hi, I think that there is a mistake un the ports.pas unit on the gpc-19990430-i386-pc-djgppv202.zip : function InPortW (PortNumber : ShortWord) : ShortWord; var Result : volatile ShortWord; (*@@*) begin asm ('inb %%dx, %%al' : '=a' (Result) : 'd' (PortNumber) : 'ax', 'dx'); InPortW := Result end; Wasn't ax instead of al? Note: I don't need to use it! -- Opie --------Publicite--personnelle--------------------------------------- ........ ABC de la Programmation (Assembleur, C, Pascal) ................ http://www.multimania.com/opecheux ................ Pour Ãªtre averti des nouvelles Ã©tapes, abonnez vous Abonnez vous aux listes franÃ§aises: - Assembleur: http://www.onelist.com/subscribe/prog_nasm - C : http://www.onelist.com/subscribe/prog_c_gnu - Pascal : http://www.onelist.com/subscribe/prog_pascal_gnu --

2 1

Re: Problem with the CRT uniy
by Frank Heckenbach 22 Dec '99

22 Dec '99

Peter Gerwinski wrote: > > > And `/usr/lib/gcc-lib/i386-redhat-linux/2.8.1/units/crt.pas' is > > > in place? > > > > Nothing, I don't have this, I don't understand.... => I installed gpc with the > > src.rpm (base and extra) > > Then your `src.rpm' is incomplete. If this is the archive > from `agnes.dida.physik.uni-essen.de' it should be complete. > (I tend to remember to have checked that before uploading; > however I cannot re-check right now because I am on holidays > and have only a slow and very expensive connection to the > Internet.) I just checked it. I assume you mean gpc-19990118-1.src.rpm. It contains gpc-19990118.tar.gz which is a complete GPC source archive, including CRT and the other units. Did you install GPC after building with `make install' or similar? If you just copied the compiler executables or something, you'll be missing the units, of course. In case the installation is done by the packaging utilities automatically (I didn't check this), maybe these scripts have to be adjusted... But you can simply copy the units from the source archive to the directory named above, they're not modified in any way while building GPC. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

3 2

Re: Problem with the CRT uniy
by Frank Heckenbach 22 Dec '99

22 Dec '99

Romain Chantereau wrote: > Ok, I installed gpc with the tar.gz gived with the src.rpm, and it works !!! > > But, I would know how compile without the --automake option, because xwpe-alpha or > rhide don't permit to modify the basic command line... (and I don't want to make > remplacement script, but if I dont' find something, i will do that..) > > Thks for all, it was very cool to help me like that !!! RHIDE (not sure about xwpe) lets you modify the command line -- in fact, it does use `--automake' by default, but (unless that has been corrected in a newer release) also some obsolete automake parameters which cause a warning by GPC. Some earlier messages this year on this list described how to modify the command line. You also might want to try my IDE PENG (http://fjf.gnu.de/peng.html) which was written in GPC and, of course, uses an appropriate command line for GPC. (What a shameless plug! ;-) Apart from that, to answer your question, you can compile a single unit or program with the `-c' switch, and link all the object files, e.g. with a program `foo' that uses a unit `bar': gpc -c bar.pas gpc -c foo.pas gpc -o foo foo.o bar.o This way, you have to compile the units used by a program/unit before the program/unit itself, and you have to make sure to recompile anything when necessary. Also, you have to take care of C files and libs referenced from some units, e.g. CRT, with `{$L}' directives. IOW, you better write a Makefile, as usual in C... Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: Help for gpc install
by Frank Heckenbach 22 Dec '99

22 Dec '99

Tom Schneider wrote: > > Here is your problem: GPC can not be used with different version of GCC. > > If it's compiled from sources against of GCC 2.8.1 you need GCC 2.8.1 to run > > the beast, if it's compiled against of EGCS 1.1.2 you need EGCS 1.1.2 and so > > on. Even minor changes (EGCS 1.1.1 => EGCS 1.1.2) will break harmony :-) > > That's lovely. So why not read from the current gcc > what version it is and if they differ put up a BIG MESSAGE > and abort? The current problem is a bit different: GPC searches for the GCC files (including libgcc.a and cc1, the actual C compiler which is used for compiling C files referenced from Pascal code) in the same directory it's installed in (i.e. <prefix>/lib/gcc-lib/<platform>/<version>/). If there is a matching GCC version, it will be installed in the same directory, GPC will find the files, and everything is fine. If there's no matching GCC installed, GPC will simply not see it, and will therefore not give any particular message about this situation, just the usual linker error that a library is not found. Well, I'm currently writing a utility to simplify the usage of GPC, avoid the automake problems, and I've also intended it to simplify the calling of GCC so it will by default call `gcc' rather than cc1 (with special handling for cross-compiles and similar things) which will work with any installed GCC (as long as it can be found in the PATH). Now I'm reading this stuff about libgcc.a incompatibilites, and I'm wondering if that's the right thing to do, or if it will just replace an obvious problem by more difficult to find subtle problems (which would be a bad thing)... Khimenko Victor wrote: > 20-Dec-99 18:11 you wrote: > > Hello again. > > > Khimenko Victor wrote: > >> > >> > to a global one (such as /usr/local/lib/). After my humble > >> > experience, this doesn't harm. (But don't blame me if it does > >> > for you.;-) > >> > >> It will work for simple programs like "Hello, World!" (where libgcc is not > >> needed anyway) just fine. But for more complex programs it'll create problems. > >> libgcc.a is INTERNAL gcc library - [...] > > > So you mean that different versions of `libgcc.a' are not > > compatible enough even between egcs-1.1.1 and egcs-1.1.2 to > > make this work in a stable way? > > It CAN be compatible but it's NOT tested (and since it's not used this way > and not used much overral probability is VERY high to get silent damage and > not notice it for very long time). > > > Well, then the creator of the GPC binary distribution _must_ > > supply a matching `libgcc.a'. > > He just must add > -- cut -- > Require: gcc = 2.8.1 > -- cut -- > line in .spec file. Then rpm will just refuse to install gpc without > corresponding gcc. If the incompatibility really exists, than that's indeed what has to be done, i.e. each GPC binary should require or include GCC. Just supplying libgcc.a with GPC without the corresponding GCC would be problematic because: - Parts of the Run Time System and some units are written in C, and would "require" another libgcc.a if compiled with another C compiler. - Perhaps it's a problem for the packages if both GCC and GPC contain libgcc.a. I don't know the different packaging systems to well, so I don't know if they're designed to handle this situation. But I'm still wondering about this incompatibility. I recently did a joint Pascal/C++ project using gpc-19990813, based on gcc-2.8.1, and g++-2.95, linking to g++-2.95's libgcc.a, and it works well under both Solaris/Sparc and Linux/x86, even though the Pascal code does some 64 bit arithmetic... That's, of course, no proof that there are no problems. But what about libraries, e.g.? If they're dependent on the libgcc.a used for compiling them, this would mean that each program using a library has to be compiled with the same compiler version (i.e., the same libgcc.a version) as the library itself, to prevent subtle bugs. IOW, after upgrading a compiler, one would have to recompile libc and everything that depends on it, i.e. basically the whole system. I've never heard of this, and I really hope this isn't true... Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

Re: Unit ports.pas, InPortW
by Frank Heckenbach 21 Dec '99

21 Dec '99

Opie Pecheux wrote: > Hi, > > I think that there is a mistake un the ports.pas unit on the > gpc-19990430-i386-pc-djgppv202.zip : > > > function InPortW (PortNumber : ShortWord) : ShortWord; > var Result : volatile ShortWord; (*@@*) > begin > asm ('inb %%dx, %%al' : '=a' (Result) : 'd' (PortNumber) : 'ax', > 'dx'); > InPortW := Result > end; > > Wasn't ax instead of al? That's right, also `inw' instead of `inb'. Thanks for the report, Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Problem with some strings procedures.
by Alfredo Cesar Fontana 20 Dec '99

20 Dec '99

Hello: In this example: PROGRAM STR; {$IFDEF BAD} TYPE P=PROCEDURE(S:STRING); {$ENDIF} VAR S:STRING; BEGIN S:='123'; DELETE(S,1,1); WRITELN(S) END. with GPC v 19990118 (DJGPP and Linux) and GPC v 19990609 when I "gpc -o str str.pas" I get: "23", the delete procedure works fine. But if I "gpc -o str str.pas -DBAD" then I get: "123". I lost my delete procedure :'-( I'm trying to migrate to GPC from TP. I want that the source compiles in TP, GPC in DOS and GPC in Linux. But I have some problems. How can I use the BP Strings Schema for not converting databases? I'm not realy sure. But I think that when I try compile a line who needs a function which returns a string but this function is undeclared; the compiler breaks. I'll work on it for getting the realy trouble, and then ask you for help. Thanks... Alfredo

1 0

x-compile, graphics, array vs pointers
by Klaus Friis Østergaard 20 Dec '99

20 Dec '99

Hi , I have just installed GPC-19990118 on a redhat 6.0 linux. I have some questions: a.. Is it possible to make the program development on the linux, and =when I am finished to cross-compile it to windows 98/windowsNT? b.. How do I work with graphics in GNU pascal, so that I am able to =use the same source to compile to both linux/windows execute files. c.. Where do I find information on the graphics tools to use in GPC. d.. I am working with the traveling salesmans problem. There I need to =make a 2-dimensional array which contain the distance between each =city/node. As I'am new to GNU pascal and pointers, I wounder if it is =possible to make some kind of pointer structure that is working faster, =use memory dynamically or smarter than using a 2-dimensionally array? kind regards, klaus ---------------------------- Klaus F. Østergaard Laser Technical Services A/S Private: Sneppevang 3 Farremosen 3 DK-3450 Allerød DK-3450 Allerød tel: +45 48 17 61 61 +45 48 17 30 44 fax: + 45 48 17 10 65 Email : kfo(a)lasertech.dk company : laser(a)lasertech.dk

5 5

Problem with the CRT uniy
by Romain Chantereau 20 Dec '99

20 Dec '99

Hi, I wanted to compile a program with the GPC, and when I invoke gpc supp.pas it make "supp.pas:5: module/unit interface `Crt' could not be imported" !! I have installed GPC with the src.rpm. I have installed FPC too, and I tried to compile with the crt.o or/and the crt.ppu or/and the crt.pas gived with the source. Where can I find this Unit under Linux ?? Or how to do this work ! ?

2 6

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 December 1999