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