Re: still trying to compile

"Robert P. Ewing" a écrit :

Hello, all

I am still having trouble with the RHIDE and gpc setup. I have fixed my problems with environment space, so the path is now fine. But I am not getting programs with grx20 to compile. Here is some output, with commentary:

When I compile from bash, at the command line, in the $DJDIR$ directory, I write: gpc --automake -v -o taste.exe contrib/grx232/pascal/taste.p -lgrx20 2> outfile Outfile then contains: Reading specs from c:/djgpp/lib/gcc-lib/djgpp/2.952/specs gpc version 20000725, based on 2.95.2 19991024 (release) c:/djgpp/lib/gcc-lib/djgpp/2.952/gpcpp.exe -lang-pascal -v -famtmpfile=c:/djgpp/tmp/RHcaaaaa\ccaqs0wh -fautomake -fdelphi-comments -D__GNU_PASCAL__ -undef -D__GNUC__=2 -D__GNUC_MINOR__=95 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=20000725 -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 -Dunix -Di386 -DGO32 -DDJGPP=2 -DMSDOS -D__OS_DOS__=1 -D__unix__ -D__i386__ -D__GO32__ -D__DJGPP__=2 -D__MSDOS__ -D__OS_DOS__=1 -D__unix -D__i386 -D__GO32 -D__DJGPP=2 -D__MSDOS -Asystem(unix) -Asystem(msdos) -Acpu(i386) -Amachine(i386) -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -D__tune_pentium__ -imacros c:/djgpp/lib/../include/sys/version.h -remap contrib/grx232/pascal/taste.pas c:/djgpp/tmp/RHcaaaaa\ccbqs0wh.i GNU Pascal Compiler PreProcessor version 2.95.2 19991024 (release) (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: c:/djgpp/LANG/PASCAL [**] c:/djgpp/include c:/djgpp/contrib/grx232/include /usr/local/include [**] JDIR/i586-pc-msdosdjgpp/include [**] $DJDIR/lib/gcc-lib/djgpp/2.952/include $DJDIR/include [*@] End of search list. c:/djgpp/lib/gcc-lib/djgpp/2.952/gpc1.exe c:/djgpp/tmp/RHcaaaaa\ccbqs0wh.i -quiet -dumpbase taste.pas -version -famtmpfile=c:/djgpp/tmp/RHcaaaaa\ccaqs0wh -fautomake -o c:/djgpp/tmp/RHcaaaaa\ccbqs0wh.s GNU Pascal version 2.95.2 19991024 (release) (djgpp) compiled by GNU C version 2.95.2 19991024 (release). c:/djgpp/bin/as.exe -o c:/djgpp/tmp/RHcaaaaa\ccbqs0wh1.o c:/djgpp/tmp/RHcaaaaa\ccbqs0wh.s c:/djgpp/lib/gcc-lib/djgpp/2.952/collect2.exe -o taste.exe c:/djgpp/lib/crt0.o -Lc:/djgpp/lib -Lc:/djgpp/contrib/grx232/lib/dj2 -Lc:/djgpp/lib/gcc-lib/djgpp/2.952 -Lc:/djgpp/bin -Lc:/djgpp/lib c:/djgpp/tmp/RHcaaaaa\ccbqs0wh1.o -lgrx20 -lgpc -lm -lgcc -lc -lgcc -Tdjgpp.djl c:/djgpp/tmp/RHcaaaaa\ccbqs0wh1.o(.text+0x9cb):taste.pas: undefined reference to `init_Grx20' collect2: ld returned 1 exit status

Some comments on this: Why am I still getting an "undefined reference to init_Grx20, when I am linking in libgrx20.a? What more can I do about it?

You do no say exactly what you have done. Probably many compilations, editing and move of files.

The above is inconsistent: temp files c:/djgpp/tmp/RHcaaaaa\ccbqs0wh.i are produced under rhide. Under dos or bash there is no RHcaaaaa or the like subdirectories (This was made by rhide for fear than two rhides running simultaneously in two different dos boxes make conflicting temporary files) In that case I am interested to know how you have get the output of the message window.

Moreover in the preceding example you have nothing corresponding to the compilation of the unit grx20.pas, while the original taste.pas contains the clause

uses grx20;

Here it means the grx20.pas file, not the library libgrx20.a This grx20.pas file is there to translate pascal function calls to corresponding library calls.

I have attached two output files (first and second) which corresponds as close as I can to what you say.

cd \djgpp bash gpc --automake -v -o taste.exe contrib/grx232/pascal/taste.pas -lgrx20 2> first gpc --automake -v -o taste.exe contrib/grx232/pascal/taste.pas -lgrx20 2> second

(two files to see the difference when grx20 has already ben compiled or not)

but first I have to copy grx20.pas to the c:\djgpp directory (or I had needed to add the option --unit-path=grx232/pascal to enable gpc to locate this file)

To decipher those output files first:

1- gpcpp (pre processor) examines taste.pas and produces a temporary file ccbi5ngg.i 2- gpc1 compiles this ccbi5ngg.i and produces an assembly temporary file ccbi5ngg.s 3- gpcpp grx20.pas ccaybogg.i 4- gpc1 ccaybogg.i ccaybogg.s 5- as assembles ccaybogg.s to give grx20.o 6- as ccbi5ngg.s a temporary ccbi5ngg1.o 7- ld links grx20.o and ccbi5ngg1.o to give taste.exe

second: steps 4 and 5 are missing since grx20.o is already there

If you have no call to compile grx20.pas (at least the pre procesor stage which is always there) and no inclusion of grx20.o in the link stage, it means that you have deleted the "uses grx20" clause and probably added something of your own, otherwise the compiler would complain about missing functions: how can we know ?

Output from within RHIDE is essentially identical, with a few slightly different compiler options. The same result and error, though.

On a more positive note, I have succeeded in compiling grx20.pas, so now I have a $DJDIR$/bin/grx20.o file.

This is certainly not where it belongs. This means that probably you start rhide from within the $DJDIR/bin directory, so that a whole bunch of mess go there. The consistent way to work:

cd directory_of_main_file rhide open a project: this is not mandatory but avoids lots of confusion (if it exists already type rhide taste.gpr) if all the units are in this main directory you can make/build and every file (.exe, .o .gpi .gpm) is produced in this directory. if not you have to add in the Option/compiler Options --unit-path=somepath (very useful for general purpose units, like grx20 or bcc2grx and others of your own) if you do not like where the .o .gpi .gpr files go you can also add --unit-destination-path=anotherpath (very useful to keep things tidy)

Finally, I've started playing with some of my .pas files from an older version of gpc. Several contain the following, because I need to be particular about data types (in one program, I need a roughly 128MB 3D array of byte, so I can't afford to use 2-byte integers instead!): Type shortint = __byte__ integer; byte = __unsigned__ shortint; int16 = __short__ integer; word = __unsigned__ int16; UI = __unsigned__ integer; {32-bit unsigned integer for MT} LI = __long__ integer; {64-bit integer for statistics} Quad = __long__ real;

The compiler complains about this: identifiers should not start with an underscore, should not end with an underscore, and should not have two consecutive underscores in them. But this is what I've done ever since I started using gpc, and it is what the example programs did! Has the syntas changed?

Yes this has been superseded by a more clear and clean syntax (see integer types in the info files). This new syntax exists since already long time, and the old has been dropped in the last release.

Hope this helps

Maurice