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@pascal.gnu.de. It is distributed under the terms of the GNU General Public License, version 2.
Frank
On 16 May 2004 at 23:53, Frank Heckenbach wrote:
I have uploaded the first public beta version of GP to http://gnu-pascal.de/contrib/frank/misc/gp-0.54.tar.gz.
[...]
I get this error while trying to build under Mingw:
"gpc -c -O3 -g -W -Wall -Werror -Wfloat-equal --no-automake --unit- path=/src/mingw/gcc-3.2.3-20030504-1/build/gp-0.54 `cat needed-options` \mingw\bin..\lib\gcc-lib\mingw32\3.2.3\units/gpc.pas gpc.exe: mingwbin..libgcc-libmingw323.2.3units/gpc.pas: No such file or directory gpc.exe: no input files make: *** [gpc.o] Error 1"
The problem, as you can see, is the backspace used in Mingw (in the return value of "--print-file-name=units".
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
Prof A Olowofoyeku (The African Chief) wrote:
On 16 May 2004 at 23:53, Frank Heckenbach wrote:
I have uploaded the first public beta version of GP to http://gnu-pascal.de/contrib/frank/misc/gp-0.54.tar.gz.
[...]
I get this error while trying to build under Mingw:
"gpc -c -O3 -g -W -Wall -Werror -Wfloat-equal --no-automake --unit- path=/src/mingw/gcc-3.2.3-20030504-1/build/gp-0.54 `cat needed-options` \mingw\bin..\lib\gcc-lib\mingw32\3.2.3\units/gpc.pas gpc.exe: mingwbin..libgcc-libmingw323.2.3units/gpc.pas: No such file or directory gpc.exe: no input files make: *** [gpc.o] Error 1"
The problem, as you can see, is the backspace used in Mingw (in the return value of "--print-file-name=units".
I've only taken care about it for DJGPP so far. Try putting the mingw target description instead of `i386-pc-msdosdjgpp' in line 107 of the Makefile:
ifeq ($(PLATFORM),i386-pc-msdosdjgpp)
Frank
On 18 May 2004 at 4:21, Frank Heckenbach wrote:
[....]
The problem, as you can see, is the backspace used in Mingw (in the return value of "--print-file-name=units".
I've only taken care about it for DJGPP so far. Try putting the mingw target description instead of `i386-pc-msdosdjgpp' in line 107 of the Makefile:
ifeq ($(PLATFORM),i386-pc-msdosdjgpp)
Changing it to this: ifeq ($(PLATFORM),mingw32) solves that problem. However, later on, I get this:
"gpc -c -s -O2 -march=i486 -mcpu=i686 -I /src/mingw/gcc-3.2.3-20030504- 1/build/gp-0.54 /src/mingw/gcc-3.2.3-20030504-1/build/gp-0.54\gp- parse.c gpc.exe: d:/src/mingw/gcc-3.2.3-20030504-1/build/gp-0.54gp-parse.c: No such file or directory gpc.exe: no input files make: *** [gp-parse.o] Error 1"
Moving "DIR_SEPARATOR=/" to the line just before: "OBJECTS=gpc.o pipes.o pipesc.o stringutils.o fileutils.o md5.o gp- parse.o gp.o $(VERSION_OBJECTS)"
solves that problem too. But this is of course not a satisfactory solution.
I am yet to test gp.exe ...
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
Prof A Olowofoyeku (The African Chief) wrote:
On 18 May 2004 at 4:21, Frank Heckenbach wrote:
[....]
The problem, as you can see, is the backspace used in Mingw (in the return value of "--print-file-name=units".
I've only taken care about it for DJGPP so far. Try putting the mingw target description instead of `i386-pc-msdosdjgpp' in line 107 of the Makefile:
ifeq ($(PLATFORM),i386-pc-msdosdjgpp)
Changing it to this: ifeq ($(PLATFORM),mingw32) solves that problem.
OK. Is this the only target description that occurs in mingw? Did you try it under MSYS and Cygwin? (Just so I can add all necessary target descriptions to the Makefile next time.)
However, later on, I get this:
"gpc -c -s -O2 -march=i486 -mcpu=i686 -I /src/mingw/gcc-3.2.3-20030504- 1/build/gp-0.54 /src/mingw/gcc-3.2.3-20030504-1/build/gp-0.54\gp- parse.c gpc.exe: d:/src/mingw/gcc-3.2.3-20030504-1/build/gp-0.54gp-parse.c: No such file or directory gpc.exe: no input files make: *** [gp-parse.o] Error 1"
Moving "DIR_SEPARATOR=/" to the line just before: "OBJECTS=gpc.o pipes.o pipesc.o stringutils.o fileutils.o md5.o gp- parse.o gp.o $(VERSION_OBJECTS)"
solves that problem too. But this is of course not a satisfactory solution.
Perhaps it is. I think I was a bit overzealous with DIR_SEPARATOR. Replacing `$(real_srcdir)$(DIR_SEPARATOR)' with `$(real_srcdir)/' in the Makefile (which has the same effect as your resetting DIR_SEPARATOR) seems to work OK for DJGPP.
Most of all, it's good that it runs under Mingw at all. That was probably the hardest target (least POSIX like and I couldn't test it at all).
I have run gp through a number of tests (under Mingw). It is pretty cool! Many congratulations to Frank for a very neat tool.
Thanks.
I have a number of observations/suggestions:
- I see that the GPC_UNIT_PATH environment variable is not used, even
though the compiler proper uses it. It would be very nice if gp would use it too.
OK.
- Any chance of gp using a configuration file
Yes. I'm planning this (and have already started writing it). But I didn't want to delay the initial release any further, so I made it without it.
Frank
On 19 May 2004 at 19:57, Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
On 18 May 2004 at 4:21, Frank Heckenbach wrote:
[....]
The problem, as you can see, is the backspace used in Mingw (in the return value of "--print-file-name=units".
I've only taken care about it for DJGPP so far. Try putting the mingw target description instead of `i386-pc-msdosdjgpp' in line 107 of the Makefile:
ifeq ($(PLATFORM),i386-pc-msdosdjgpp)
Changing it to this: ifeq ($(PLATFORM),mingw32) solves that problem.
OK. Is this the only target description that occurs in mingw?
This is the platform that the Mingw gcc maintainers declare and they have been using it for a while (probably as far back as gcc-2.95.3.x). I believe however that some people who build their own gpc for Mingw use things such as "i486-pc-mingw32". This is not "standard", and I guess they can edit the gp sources themselves, unless there is a way of supporting all the various permutations (i[3456]86-pc-mingw32).
Under Mingw, some programs compile without problem, using gp. With others I get this error:
"gp example1 d:\mingw\lib\gcc-lib\mingw32\3.2.3\units\dosunix.pas:400:5: internal erro r: parser position mismatch"
Did you try it under MSYS and Cygwin? (Just so I can add all necessary target descriptions to the Makefile next time.)
Seems to work okay under MSYS and Cygwin (I did not need to change anything in the sources). Cygwin seems to be perfect, Msys throws up some complaints ("gpc -print-file-name=units installation problem: cannot get default unit path"), but seems to be okay in the end, in the sense that the compiled program is there, and runs okay. I have attached a tarball containing logs of the output of the three Win32 platforms. I have ascertained that the complaints by the MSYS binary arise because "DirectoryExists (Res)" returns False when it should return true (in "GetUnitPath"). I have been unable to locate the actual body of the DirectoryExists function to ascertain why this is happening.
However, later on, I get this:
"gpc -c -s -O2 -march=i486 -mcpu=i686 -I /src/mingw/gcc-3.2.3-20030504- 1/build/gp-0.54 /src/mingw/gcc-3.2.3-20030504-1/build/gp-0.54\gp- parse.c gpc.exe: d:/src/mingw/gcc-3.2.3-20030504-1/build/gp-0.54gp-parse.c: No such file or directory gpc.exe: no input files make: *** [gp-parse.o] Error 1"
Moving "DIR_SEPARATOR=/" to the line just before: "OBJECTS=gpc.o pipes.o pipesc.o stringutils.o fileutils.o md5.o gp- parse.o gp.o $(VERSION_OBJECTS)"
solves that problem too. But this is of course not a satisfactory solution.
Perhaps it is. I think I was a bit overzealous with DIR_SEPARATOR. Replacing `$(real_srcdir)$(DIR_SEPARATOR)' with `$(real_srcdir)/' in the Makefile (which has the same effect as your resetting DIR_SEPARATOR) seems to work OK for DJGPP.
Seems ok here too (at least, it is not causing any problem).
Please check the attached log files and see if they are helpful. So far.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any other MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance.
---- File information ----------- File: gp-055-win32-log.tar.gz Date: 21 May 2004, 16:43 Size: 2473 bytes. Type: Unknown
Prof A Olowofoyeku (The African Chief) wrote:
This is the platform that the Mingw gcc maintainers declare and they have been using it for a while (probably as far back as gcc-2.95.3.x). I believe however that some people who build their own gpc for Mingw use things such as "i486-pc-mingw32". This is not "standard", and I guess they can edit the gp sources themselves, unless there is a way of supporting all the various permutations (i[3456]86-pc-mingw32).
I'll just add them.
Under Mingw, some programs compile without problem, using gp. With others I get this error:
"gp example1 d:\mingw\lib\gcc-lib\mingw32\3.2.3\units\dosunix.pas:400:5: internal erro r: parser position mismatch"
I can't reproduce it. Do you have an example where it occurs? Is it CR/LF related?
Can you add the line:
fprintf (stderr, "BufPos: %i, BufCount: %i\n", BufPos, BufCount);
before:
if (BufPos != BufCount) ParseError ("internal error: parser position mismatch");
in gp-parse.c and note the output when running?
Msys throws up some complaints ("gpc -print-file-name=units installation problem: cannot get default unit path"), but seems to be okay in the end, in the sense that the compiled program is there, and runs okay. I have attached a tarball containing logs of the output of the three Win32 platforms. I have ascertained that the complaints by the MSYS binary arise because "DirectoryExists (Res)" returns False when it should return true (in "GetUnitPath"). I have been unable to locate the actual body of the DirectoryExists function to ascertain why this is happening.
It's in the RTS. You reported a problem with it on 2003-11-22 (`Cygwin and "Stat"'), but according to the thread it was related to mingw and/or gcc versions. Anyway it's hard for me to debug. So if you have any suggestions (for a generic fix in the RTS), let me know.
Frank
On 27 May 2004 at 1:58, Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
This is the platform that the Mingw gcc maintainers declare and they have been using it for a while (probably as far back as gcc-2.95.3.x). I believe however that some people who build their own gpc for Mingw use things such as "i486-pc-mingw32". This is not "standard", and I guess they can edit the gp sources themselves, unless there is a way of supporting all the various permutations (i[3456]86-pc-mingw32).
I'll just add them.
Ok.
Under Mingw, some programs compile without problem, using gp. With others I get this error:
"gp example1 d:\mingw\lib\gcc-lib\mingw32\3.2.3\units\dosunix.pas:400:5: internal erro r: parser position mismatch"
I can't reproduce it. Do you have an example where it occurs? Is it CR/LF related?
So far, it seems to only happen in dosunix.pas (at the very end). It may be CR/LF related, because when I converted the line endings of dosunix.pas from unix to dos format, the error disappeared. But then when I converted it back to unix format again, the problem did not come back!
Can you add the line:
fprintf (stderr, "BufPos: %i, BufCount: %i\n", BufPos, BufCount);
before:
if (BufPos != BufCount) ParseError ("internal error: parser position mismatch");
in gp-parse.c and note the output when running?
This is the output: "d:\mingw\lib\gcc-lib\mingw32\3.2.3\units\dosunix.pas:400:5: internal error: parser position mismatch BufPos: 9871, BufCount: 9870 d:\mingw\lib\gcc-lib\mingw32\3.2.3\units\dosunix.pas:400:5: internal erro r: parser position mismatch BufPos: 9871, BufCount: 9870"
Seems that something is trying to read past EOF (or perhaps an extra character (^z ?) exists in the file).
Msys throws up some complaints ("gpc -print-file-name=units installation problem: cannot get default unit path"), but seems to be okay in the end, in the sense that the compiled program is there, and runs okay. I have attached a tarball containing logs of the output of the three Win32 platforms. I have ascertained that the complaints by the MSYS binary arise because "DirectoryExists (Res)" returns False when it should return true (in "GetUnitPath"). I have been unable to locate the actual body of the DirectoryExists function to ascertain why this is happening.
It's in the RTS. You reported a problem with it on 2003-11-22 (`Cygwin and "Stat"'), but according to the thread it was related to mingw and/or gcc versions. Anyway it's hard for me to debug. So if you have any suggestions (for a generic fix in the RTS), let me know.
Where in the RTS is DirectoryExists? Do I have to look for Stat or something to that effect?
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof A Olowofoyeku (The African Chief) wrote:
On 27 May 2004 at 1:58, Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
Under Mingw, some programs compile without problem, using gp. With others I get this error:
"gp example1 d:\mingw\lib\gcc-lib\mingw32\3.2.3\units\dosunix.pas:400:5: internal erro r: parser position mismatch"
I can't reproduce it. Do you have an example where it occurs? Is it CR/LF related?
So far, it seems to only happen in dosunix.pas (at the very end).
The error always appears at the end. It's an internal consistency check done after reading a file.
It may be CR/LF related, because when I converted the line endings of dosunix.pas from unix to dos format, the error disappeared. But then when I converted it back to unix format again, the problem did not come back!
Can you add the line:
fprintf (stderr, "BufPos: %i, BufCount: %i\n", BufPos, BufCount);
before:
if (BufPos != BufCount) ParseError ("internal error: parser position mismatch");
in gp-parse.c and note the output when running?
This is the output: "d:\mingw\lib\gcc-lib\mingw32\3.2.3\units\dosunix.pas:400:5: internal error: parser position mismatch BufPos: 9871, BufCount: 9870 d:\mingw\lib\gcc-lib\mingw32\3.2.3\units\dosunix.pas:400:5: internal erro r: parser position mismatch BufPos: 9871, BufCount: 9870"
Seems that something is trying to read past EOF (or perhaps an extra character (^z ?) exists in the file).
Still can't reproduce it. Can you send me the output of `gpc -E dosunix.pas'? Can you try to find out which part of the unit is causing problems by removing lines (doesn't have to compile, just `{$if}' etc. have to match)?
Msys throws up some complaints ("gpc -print-file-name=units installation problem: cannot get default unit path"), but seems to be okay in the end, in the sense that the compiled program is there, and runs okay. I have attached a tarball containing logs of the output of the three Win32 platforms. I have ascertained that the complaints by the MSYS binary arise because "DirectoryExists (Res)" returns False when it should return true (in "GetUnitPath"). I have been unable to locate the actual body of the DirectoryExists function to ascertain why this is happening.
It's in the RTS. You reported a problem with it on 2003-11-22 (`Cygwin and "Stat"'), but according to the thread it was related to mingw and/or gcc versions. Anyway it's hard for me to debug. So if you have any suggestions (for a generic fix in the RTS), let me know.
Where in the RTS is DirectoryExists?
filename.pas
Do I have to look for Stat or something to that effect?
Probably (since that's where DirectoryExists calls). It's in rts.c (`_p_Stat').
Frank
On 27 May 2004 at 13:03, Frank Heckenbach wrote:
[...]
This is the output: "d:\mingw\lib\gcc-lib\mingw32\3.2.3\units\dosunix.pas:400:5: internal error: parser position mismatch BufPos: 9871, BufCount: 9870 d:\mingw\lib\gcc-lib\mingw32\3.2.3\units\dosunix.pas:400:5: internal erro r: parser position mismatch BufPos: 9871, BufCount: 9870"
Seems that something is trying to read past EOF (or perhaps an extra character (^z ?) exists in the file).
Still can't reproduce it. Can you send me the output of `gpc -E dosunix.pas'?
Attached.
Can you try to find out which part of the unit is causing problems by removing lines (doesn't have to compile, just `{$if}' etc. have to match)?
The fault is random. If I insert a space after the "." of the last "end." statement, there is no error. If I remove the space so that the dot is the last thing in the file, the error comes back. If I remove all the comments at the top of the file, the error goes away. If I add the comments back, the error comes back. In each case, BufPos = BufCount + 1. Perhaps you just need to allow for the extra byte.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any other MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance.
---- File information ----------- File: dosunix.e.gz Date: 27 May 2004, 22:52 Size: 2664 bytes. Type: Unknown
Prof A Olowofoyeku (The African Chief) wrote:
The fault is random. If I insert a space after the "." of the last "end." statement, there is no error. If I remove the space so that the dot is the last thing in the file, the error comes back. If I remove all the comments at the top of the file, the error goes away. If I add the comments back, the error comes back. In each case, BufPos = BufCount + 1. Perhaps you just need to allow for the extra byte.
It was indeed an uninitialized-state bug which was triggered (but not caused) by the use of CR/LF -- a rather complicated situation. Thanks for finding it. (I could reproduce it with your file.)
This patch should fix it.
Frank
Hi everyone,
Finally gotten an old program to a state that the compiler has almost stopped telling interesting little titbits (errors) in the build.
Two things remain: an error and a warning:
1. The error indicates (to me) that the compiler thinks its generating an enormous code or that the linker/loader is doing strange things. Its not *that* big! Any ideas? I'm developing this on OSX 10.2.8. (I can't locate a la_symbol_ptr in the source code, btw.)
e.g.
/usr/bin/ld: /usr/lib/crt1.o can't create relocation entry for prebinding (address of section (__DATA,__la_symbol_ptr) more than 24-bits away from first segment, use -noprebind)
2. I've been warned about using underscores at the end of identifiers. Obviously I can rename them, but there is a reason for this naming. Does this really do any harm? I can understand issues with underscores at the start of identifiers, but at the end?
e.g.
ghj_aainit.pas: In procedure `load_action_table': ghj_aainit.pas:379: warning: identifiers should not end with an underscore
The full results are below.
Grant
[G4:Programming/ghjseqGPCIncludes/aa_prog_dir_port] gjacobs% gpc GHJ_AA.pas ghj_aaglobalunit.pas:395: warning: identifiers should not end with an underscore ghj_aainit.pas: In procedure `load_action_table': ghj_aainit.pas:379: warning: identifiers should not end with an underscore ghj_aadescriptors.pas: In function `default_feature_expr': ghj_aadescriptors.pas:546: warning: identifiers should not end with an underscore ghj_aamerge.pas: In procedure `merge_index': ghj_aamerge.pas:378: warning: constructing limited integer set `0 .. 255'; ghj_aamerge.pas:378: warning: use `--setlimit=NUMBER' to change the size limit at compile time. ghj_aaanalyse.pas: In function `match_integer': ghj_aaanalyse.pas:716: warning: identifiers should not end with an underscore /usr/bin/ld: /usr/lib/crt1.o can't create relocation entry for prebinding (address of section (__DATA,__la_symbol_ptr) more than 24-bits away from first segment, use -noprebind) /usr/bin/ld: /usr/lib/crt1.o can't create relocation entry for prebinding (address of section (__DATA,__la_symbol_ptr) more than 24-bits away from first segment, use -noprebind) /usr/bin/ld: /usr/lib/crt1.o can't create relocation entry for prebinding (address of section (__DATA,__la_symbol_ptr) more than 24-bits away from first segment, use -noprebind) collect2: ld returned 1 exit status
Grant Jacobs wrote:
Finally gotten an old program to a state that the compiler has almost stopped telling interesting little titbits (errors) in the build.
Two things remain: an error and a warning:
- The error indicates (to me) that the compiler thinks its
generating an enormous code or that the linker/loader is doing strange things. Its not *that* big! Any ideas? I'm developing this on OSX 10.2.8. (I can't locate a la_symbol_ptr in the source code, btw.)
e.g.
/usr/bin/ld: /usr/lib/crt1.o can't create relocation entry for prebinding (address of section (__DATA,__la_symbol_ptr) more than 24-bits away from first segment, use -noprebind)
I don't know exactly, maybe some internal linker stuff (and due to the use of the RTS and libc the total code size might get bigger, though 16 MB would be *quite* a lot, not sure where it comes from; how big is the resulting executable?). Anyway, did you try just using `-noprebind' as it says?
- I've been warned about using underscores at the end of
identifiers. Obviously I can rename them, but there is a reason for this naming. Does this really do any harm? I can understand issues with underscores at the start of identifiers, but at the end?
Which issues actually? The thing is simply that both ways (plus several underscores in a row) are forbidden in ISO Extended Pascal. Some other dialects allow them, so GPC only warns. ('-Wno-underscore' to turn it off).
Frank
Grant Jacobs wrote:
- The error indicates (to me) that the compiler thinks its generating
an enormous code or that the linker/loader is doing strange things. Its not *that* big! Any ideas? I'm developing this on OSX 10.2.8. (I can't locate a la_symbol_ptr in the source code, btw.)
e.g.
/usr/bin/ld: /usr/lib/crt1.o can't create relocation entry for prebinding (address of section (__DATA,__la_symbol_ptr) more than 24-bits away from first segment, use -noprebind)
Well, did you try to disable prebinding by passing "-Wl,-noprebind" on the command line ? What if you pass "-Wl,-prebind_allow_overlap" or "-Wl,-prebind_all_twolevel_modules" or "-Wl,-noprebind_all_twolevel_modules" ? Are you, by the way, linking with dynamic libraries ?
- I've been warned about using underscores at the end of identifiers.
Obviously I can rename them, but there is a reason for this naming. Does this really do any harm? I can understand issues with underscores at the start of identifiers, but at the end?
Just pass "-Wno-underscore".
Regards,
Adriaan van Os
At 7:58 PM +0200 28/5/04, Adriaan van Os wrote:
Grant Jacobs wrote:
- The error indicates (to me) that the compiler thinks its
generating an enormous code or that the linker/loader is doing strange things. Its not *that* big! Any ideas? I'm developing this on OSX 10.2.8. (I can't locate a la_symbol_ptr in the source code, btw.)
e.g.
/usr/bin/ld: /usr/lib/crt1.o can't create relocation entry for prebinding (address of section (__DATA,__la_symbol_ptr) more than 24-bits away from first segment, use -noprebind)
Well, did you try to disable prebinding by passing "-Wl,-noprebind" on the command line ? What if you pass "-Wl,-prebind_allow_overlap" or "-Wl,-prebind_all_twolevel_modules" or "-Wl,-noprebind_all_twolevel_modules" ? Are you, by the way, linking with dynamic libraries ?
Thanks for that. I vaguely recalled you writing something about some options to do with prebinding but I couldn't find any message with 'prebind' in my archive of gpc posts. Is this documented somewhere btw? Its not in gpc's PDF help file.
I'm not linking any libraries explicitly (yet); any ones that gpc are linking in are done whatever way it does them...
- I've been warned about using underscores at the end of
identifiers. Obviously I can rename them, but there is a reason for this naming. Does this really do any harm? I can understand issues with underscores at the start of identifiers, but at the end?
Just pass "-Wno-underscore".
Ta, missed that one when scanning the options.
Grant
On 29 May 2004 at 9:01, Grant Jacobs wrote:
[...]
- I've been warned about using underscores at the end of
identifiers. Obviously I can rename them, but there is a reason for this naming. Does this really do any harm? I can understand issues with underscores at the start of identifiers, but at the end?
Just pass "-Wno-underscore".
Ta, missed that one when scanning the options.
I have often wondered myself what the warnings about underscores are for. Can someone please explain why they are considered worthy of warnings?
Thanks.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof. Abimbola A. Olowofoyeku wrote:
On 29 May 2004 at 9:01, Grant Jacobs wrote:
[...]
- I've been warned about using underscores at the end of
identifiers. Obviously I can rename them, but there is a reason for this naming. Does this really do any harm? I can understand issues with underscores at the start of identifiers, but at the end?
Just pass "-Wno-underscore".
Ta, missed that one when scanning the options.
I have often wondered myself what the warnings about underscores are for. Can someone please explain why they are considered worthy of warnings?
AFAIKS the warning was introduced many years ago, so I can not say about original motivation. However, my rationale is: leading or trailing underscores (and double underscore inside) are forbiden in ISO 10206. Since such underscores are quite easy to avoid in new code the warning seem justified. And for legacy code `-Wno-underscore' gets rid of the warning.
Waldek Hebisch wrote:
Prof. Abimbola A. Olowofoyeku wrote:
On 29 May 2004 at 9:01, Grant Jacobs wrote:
[...]
- I've been warned about using underscores at the end of
identifiers. Obviously I can rename them, but there is a reason for this naming. Does this really do any harm? I can understand issues with underscores at the start of identifiers, but at the end?
Just pass "-Wno-underscore".
Ta, missed that one when scanning the options.
I have often wondered myself what the warnings about underscores are for. Can someone please explain why they are considered worthy of warnings?
AFAIKS the warning was introduced many years ago, so I can not say about original motivation. However, my rationale is: leading or trailing underscores (and double underscore inside) are forbiden in ISO 10206. Since such underscores are quite easy to avoid in new code the warning seem justified. And for legacy code `-Wno-underscore' gets rid of the warning.
I'd say that's about it. (Besides, IMHO, they don't really add to the readability of an identifier, unlike single underscores inside, sometimes.)
Frank
Grant Jacobs wrote:
Thanks for that. I vaguely recalled you writing something about some options to do with prebinding but I couldn't find any message with 'prebind' in my archive of gpc posts. Is this documented somewhere btw? Its not in gpc's PDF help file.
Apple's "Fred Flintstone" Mach-O Runtime architecture is discussed at <http://developer.apple.com/documentation/DeveloperTools/Conceptual/ MachORuntime/>. The "Bam Bam" linker is documented in the ld man pages - type "man ld" on the terminal command line.
/usr/bin/ld: /usr/lib/crt1.o can't create relocation entry for prebinding (address of section (__DATA,__la_symbol_ptr) more than 24-bits away from first segment, use -noprebind)
From the ld man pages (prebinding is the default for executables):
-prebind Have the static linker, ld(1), prebind an executable's or dynamic shared library's undefined symbols to the addresses of the dynamic libraries it is being linked with. This optimiza- tion can only be done if the libraries don't overlap and no sym- bols are overridden.
So, maybe the 24-bits message is msleading and there is a symbol naming conflict instead (just a wild guess).
Regards,
Adriaan van Os
On 28 May 2004 at 2:10, Frank Heckenbach wrote:
[...]
It was indeed an uninitialized-state bug which was triggered (but not caused) by the use of CR/LF -- a rather complicated situation. Thanks for finding it. (I could reproduce it with your file.)
This patch should fix it.
It does ...
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Hi
gp appends ".resource" to the filename of resource files linked with {$R "filename.res"}. This leads to a "file not found" error from gpc, even when "filename.res" is there, because gpc is looking for "filename.res.resource".
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Frank Heckenbach a écrit:
I have uploaded the first public beta version of GP to http://gnu-pascal.de/contrib/frank/misc/gp-0.54.tar.gz.
I have found a bug with --unit-destination-path
In a scratch directory (c:\lombardi\djgpp\gpc\hello) I put a program
hello.pas ----------------------------------------------- program hello;
uses U;
begin writeln(OK); end. ------------------------------------------------ and a unit
U.pas ------------------------------------------------ unit U;
INTERFACE
const OK = 'OK';
IMPLEMENTATION
end. -----------------------------------------------
I create a subdirectory ./o to store object files
compiling with
redir -eo gp hello.pas -v --unit-destination-path=o > hello.lst
results in the attached file hello.lst
replacing "gp" by "gpc --automake" gives correct results
Maurice
Maurice Lombardi wrote:
Frank Heckenbach a écrit:
I have uploaded the first public beta version of GP to http://gnu-pascal.de/contrib/frank/misc/gp-0.54.tar.gz.
I have found a bug with --unit-destination-path [...]
Oh yes, silly bug.
Frank
Frank Heckenbach a écrit:
Maurice Lombardi wrote:
Frank Heckenbach a écrit:
I have uploaded the first public beta version of GP to http://gnu-pascal.de/contrib/frank/misc/gp-0.54.tar.gz.
I have found a bug with --unit-destination-path [...]
Oh yes, silly bug.
OK it works now
Thanks
Maurice
On Sun, May 16, 2004 at 11:53:09PM +0200, Frank Heckenbach wrote:
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.
After compiling gp on a Linux box, it failed its self-test:
[gp-0.54]% make check ./gp --test-parser --unit-path=/home/emil/dist/gpc/gp-0.54 /home/emil/dist/gpc/gp-0.54/test-parser.pas > test-parser.tmp sed -e '/^[PVm]/d;s,/,/,g;s,'`pwd`',@srcdir@,g;s,/home/emil/dist/gpc/gp-0\.54,@srcdir@,g' < test-parser.tmp > test-parser.new rm -f test-parser.tmp if diff /home/emil/dist/gpc/gp-0.54/test-parser.out test-parser.new; then \ echo "Parser test succeeded" >&2; \ rm -f test-parser.new; \ else \ echo "Parser test failed" >&2; \ fi 7a8
M
9,10c10,11 < L l1 < L l2 ---
L -ll1 L -ll2
Parser test failed
Emil
Emil Jerabek wrote:
On Sun, May 16, 2004 at 11:53:09PM +0200, Frank Heckenbach wrote:
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.
After compiling gp on a Linux box, it failed its self-test:
Oh yeah, just a small bug in the test itself. Will be corrected.
Frank
-
Adriaan van Os -
Emil Jerabek -
Frank Heckenbach -
Frank Heckenbach -
Grant Jacobs -
Maurice Lombardi -
Prof A Olowofoyeku (The African Chief) -
Waldek Hebisch