Hi GPC'ers!! I was trying to set up a cross compiler on a Linux host to generate Windoze executables. I succeeded using the usual --target=...-mingw32 but when I run i...-mingw32-gpc I get a message about collect2 missing. And in fact, it is missing. Only symlinking ld to collect2 works smoothly. Why does that happen? Thanks in advance. Nick
On 30 Jun 2001, at 20:25, Nicola Girardi wrote:
...but when I run i...-mingw32-gpc I get a message about collect2 missing. And in fact, it is missing. Only symlinking ld to collect2 works smoothly. Why does that happen?
"collect2" appears to be involved with ensuring that C++ constructors and destructors are called correctly. I do not believe that it has any function in GPC. See: http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_3.html#SEC59 "collect2" is being called because the GPC build process creates a "specs" file that has this section present: *linker: collect2 During the build process, the "specs" file is created by executing these commands: ./xgcc -dumpspecs > tmp-specs mv tmp-specs specs Note that the "specs" file is created by running "xgcc" and not "xgpc". "gpc.c" is based on "gcc.c". However, newer versions of "gcc.c" (e.g., 2.95.3) check to see if "collect2" exists. If not, "ld" is called in its place. Perhaps that check should be migrated to "gpc.c". The workaround you have used is OK. Other GPC-specific workarounds are to change the "specs" entry to: *linker: ld ...or to regenerate a GPC-specific "specs" file: gpc -dumpspecs > specs (and then move the resulting "specs" file to the appropriate place). -- Dave
J. David Bryan wrote:
"gpc.c" is based on "gcc.c". However, newer versions of "gcc.c" (e.g., 2.95.3) check to see if "collect2" exists. If not, "ld" is called in its place. Perhaps that check should be migrated to "gpc.c".
I'm copying this part. I can't check it here. So when this will have been uploaded (perhaps next week since I'm also trying to solve another issue before uploading anything; probably the next GPC version number greater than today), anyone who has this problem and used a work-around, please try it without the work-around then and tell us if it works. Frank -- Frank Heckenbach, frank@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
On 4 Jul 2001, at 2:10, Frank Heckenbach wrote:
I'm copying this part. I can't check it here. So when this will have been uploaded (perhaps next week since I'm also trying to solve another issue before uploading anything; probably the next GPC version number greater than today), anyone who has this problem and used a work-around, please try it without the work-around then and tell us if it works.
I'll be happy to do that. However, in doing a comparison between "gpc.c" and the "gcc.c" of 2.95.3, I notice a number of points of divergence. The GPC ChangeLog implies that "gpc.c" was periodically synchronized with "gcc.c" in the past. I presume that hasn't been done for a while. But would it make more sense to create "gpc.c" by copying "gcc.c" to "gpc.c" and then applying a patch to "gpc.c"? Would that be less work than either synchronizing periodically or running afoul of the type of problem that started this thread? I suppose I am asking why the "patching option" is not being used. Again, the Changelog seems to imply that patches were made directly to "gcc.c" before "gpc.c" was split out as a separate program (a _long_ time ago). -- Dave
J. David Bryan wrote:
On 4 Jul 2001, at 2:10, Frank Heckenbach wrote:
I'm copying this part. I can't check it here. So when this will have been uploaded (perhaps next week since I'm also trying to solve another issue before uploading anything; probably the next GPC version number greater than today), anyone who has this problem and used a work-around, please try it without the work-around then and tell us if it works.
I'll be happy to do that.
However, in doing a comparison between "gpc.c" and the "gcc.c" of 2.95.3, I notice a number of points of divergence. The GPC ChangeLog implies that "gpc.c" was periodically synchronized with "gcc.c" in the past. I presume that hasn't been done for a while.
Correct (or rather, parts of it have been synchronized, but only when direct need arose, like above).
But would it make more sense to create "gpc.c" by copying "gcc.c" to "gpc.c" and then applying a patch to "gpc.c"? Would that be less work than either synchronizing periodically or running afoul of the type of problem that started this thread?
I suppose I am asking why the "patching option" is not being used. Again, the Changelog seems to imply that patches were made directly to "gcc.c" before "gpc.c" was split out as a separate program (a _long_ time ago).
gpc.c has diverged quite a bit from gcc.c (in its own functionality, not only because of changes to gcc.c), but our plan is to move it closer again -- e.g., a good deal of the difference is due to the automake feature, and once this will be replaced by an external tool, which is planned, gpc.c can get rid of much of the extra code. Then it probably makes sense indeed to use a patch. (If we're really lucky, the only difference will be that it links -lm -lgpc by default while gcc.c doesn't.) Frank -- Frank Heckenbach, frank@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
participants (3)
-
Frank Heckenbach -
J. David Bryan -
Nicola Girardi