Hello
I had tried to compile gpc under freebsd last year. But didn`t get far. Now I`m trying with a newer version of the compiler.
gpc-20030830 gcc-3.3.1 .
This is the last make output :
gcc -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -DHAVE_CIG_H -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -Wtraditional -pedantic -Wnong-long -o xgpc p/gpc.o prefix.o version.o intl.o ./intl/libintl.a ../libiberty/libiberty.a gcc -o p/diagnostic.o -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -DHAVE_CONFIG_H -I. -II/usr/home/karim/pascal/gcc-3.3.1/gcc -I/usr/home/karim/pascal/gcc-3.3.1/gcc/p -I/usr/home/karim/pascal/gcc-3.3.1/gcc/config -I/usr/home/km/pascal/gcc-3.3.1/gcc/../include -DGPC gcc: No input files specified *** Error code 1
Stop in /usr/home/karim/pascal/gpc-build/gcc. *** Error code 1
Stop in /usr/home/karim/pascal/gpc-build.
Has anybody a clue how to solve this problem ?
Greetings Karim
karim_f@mysunrise.ch wrote:
Hello
I had tried to compile gpc under freebsd last year. But didn`t get far. Now I`m trying with a newer version of the compiler.
gpc-20030830 gcc-3.3.1 .
This is the last make output :
gcc -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -DHAVE_CIG_H -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -Wtraditional -pedantic -Wnong-long -o xgpc p/gpc.o prefix.o version.o intl.o ./intl/libintl.a ../libiberty/libiberty.a gcc -o p/diagnostic.o -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -DHAVE_CONFIG_H -I. -II/usr/home/karim/pascal/gcc-3.3.1/gcc -I/usr/home/karim/pascal/gcc-3.3.1/gcc/p -I/usr/home/karim/pascal/gcc-3.3.1/gcc/config -I/usr/home/km/pascal/gcc-3.3.1/gcc/../include -DGPC gcc: No input files specified *** Error code 1
Are you using GNU make? (If not, please do. You can install it in parallel to BSD make, say as gmake, and invoke gmake instead of make. You might have to restart building from scratch then.)
Frank
Having installed gpc 2.1 and tried compiling a "hello world" type program, it fails on the linker:
/usr/bin/ld: cannot find -lgcc
I've installed gpc 2.1 (20020510) based on gcc-2.95.3 (20010315) from a binary installation.
I've already tried a naive hack of putting a link to the libgcc.a that's several levels down in the /usr/lib/gcc-lib hierarchy in /usr/lib and /usr/local/lib to no avail.
I'm thinking of installing the newer version rather than mucking around further. Would one of the newer (beta) version fix this issue?
In the interim I'm going to try on OSX instead even though I'd prefer this project be done under Linux (whatever works, etc...).
Grant
Grant Jacobs wrote:
Having installed gpc 2.1 and tried compiling a "hello world" type program, it fails on the linker:
/usr/bin/ld: cannot find -lgccI've installed gpc 2.1 (20020510) based on gcc-2.95.3 (20010315) from a binary installation.
Did you get the "-with-gcc" binary? (The one without will only work if you have the exactly matching GCC version already installed -- unlikely in this case).
I've already tried a naive hack of putting a link to the libgcc.a that's several levels down in the /usr/lib/gcc-lib hierarchy in /usr/lib and /usr/local/lib to no avail.
I'm thinking of installing the newer version rather than mucking around further. Would one of the newer (beta) version fix this issue?
Should be independent of this issues, but of course, it fixes a number of bugs on the Pascal side. (And it contains some incompatible changes, esp. the `external' syntax, so if you start something new, it seems better to start with the new version, lest you'll have to convert things later when upgrading.)
Frank
At 11:38 AM +0200 10/5/04, Frank Heckenbach wrote:
Grant Jacobs wrote:
Did you get the "-with-gcc" binary? (The one without will only work if you have the exactly matching GCC version already installed -- unlikely in this case).
I was sure that's what I was getting (I'm aware of difference, etc.). Maybe it wasn't what I was got! :-(
I'll start over & see what happens.
I'm thinking of installing the newer version rather than mucking around further. Would one of the newer (beta) version fix this issue?
Should be independent of this issues, but of course, it fixes a number of bugs on the Pascal side. (And it contains some incompatible changes, esp. the `external' syntax, so if you start something new, it seems better to start with the new version, lest you'll have to convert things later when upgrading.)
I'm beginning to see that. I've downloaded the 20030830 beta onto OSX and its a lot pickier than 20020510... :-) I suppose this version is stable enough?
Funnily I haven't run into external syntax issues yet, even though its old DEC Pascal code with lots of external references.
I've discovered that this newer version is pickier about unresolved forward references. I have a habit of creating these in the unit interface while designing a unit as code to be implemented later. GPC 20030830 insists that they are an error rather than a harmless unused reference. I've mixed feelings about that. Pedantically its perhaps the right thing to do but its killing an approach to designing units. Not that my view counts, but personally I have it generate a warning-level message only at the compile stage ("warning: XXX in interface not implemented in unit/module implementation"), with an error at the link stage if (and only if) some code tries to use that procedure, etc.) Just idle thoughts -- ignore me if I'm being a nuisance.
Oh - one Q: have short strings been implemented yet? - it'd save me doing a minor work-around.
Grant
Grant Jacobs wrote:
I'm beginning to see that. I've downloaded the 20030830 beta onto OSX and its a lot pickier than 20020510... :-) I suppose this version is stable enough?
Perhaps even more stable than 20020510 (if you don't use gcc-3.3.x where GPC has a known issue with predefined conditionals -- not very serious under Linux, though) since it's been around for so long now and probably rather well tested.
I've discovered that this newer version is pickier about unresolved forward references. I have a habit of creating these in the unit interface while designing a unit as code to be implemented later. GPC 20030830 insists that they are an error rather than a harmless unused reference. I've mixed feelings about that. Pedantically its perhaps the right thing to do but its killing an approach to designing units. Not that my view counts, but personally I have it generate a warning-level message only at the compile stage ("warning: XXX in interface not implemented in unit/module implementation"), with an error at the link stage if (and only if) some code tries to use that procedure, etc.) Just idle thoughts -- ignore me if I'm being a nuisance.
Well, I see it differently -- to a large degree out of bad experience from C. C compilers give warnings for many constructs that are actually wrong (or should be wrong, for any sane definition -- I'm no expert on the C standards). The result is that many C programmers just accept these warnings (which appear -- or flood -- when compiling), to be fixed later (read, never). And often they also hide the really dangerous warnings in the flood ...
IMHO, if a thing is clearly wrong, it should be an error. Warnings are for cases that the compiler can't clearly decide (such as the use of possibly undefined values), or things that are formally correct but suspicious (on request by the user) such as `;' after `then' or `a = b and c' without parentheses (which is correct if a, b and c are of Boolean type, but usually not what's intended), or dangerous/stupid dialect constructs (`absolute' variables/ initialized variables declared under `const', both from BP), and similar stuff.
(BTW, I don't claim that GPC behaves exactly like this already, but that's my goal.)
As for implementing later, you can of course comment out or `$if' out the future declarations, perhaps together with a nice comment (I myself put `@@' there) to remind you of this. In older GPC code (when GPC didn't check this) both of mine and from others, I found "dead" declarations lying around which either were meant to be implemented but never needed, or removed and the declaration forgotten.
Of course, the linker would give an error if an implemented routine was actually used, but IMHO a compiler should catch errors, so that a successfully compiled program does not run into linker problems (again, this may not always be the case yet).
Oh - one Q: have short strings been implemented yet? - it'd save me doing a minor work-around.
Not yet, but I'm considering to do them as one of the next big things, maybe at the end of this year ...
Frank
-
Frank Heckenbach -
Grant Jacobs -
karim_f＠mysunrise.ch