Prof A Olowofoyeku (The African Chief) wrote:
I have produced a GPC interface unit for GNU plotutils (courtesy of the "headconv" program). However, there is a problem. Trying to compile a test program gives this error:
"d:/mingw/bin/../lib/gcc-lib/mingw32/3.2.3/libgpc.a(init.o): In function `p_initialize': d:/src/mingw/gcc-3.2.3/gcc/p/rts/init.pas:266: multiple definition of `_p_initialize'
"p_defplot.c" has this: void _p_initialize (S___(Plotter *_plotter))
Grmpf. We'd always assumed our `_p_' prefixes should be good enough to avoid such conflicts. Apparently not.
The solution is either to change their our our naming. OTH, GPC probably was there first (this naming is in use at least for ~10 years).
OTOH, it might be somewhat easier to change in GPC since user programs (except in rare cases) don't care about the linker names.
Additionally, thanks to qualified identifiers, we can, in the long run, get rid of some prefixes. Actually, I'm now dropping the linker names in all units, except where required for C interfaces. We can do the same in the RTS when the compiler calls RTS routines via a Pascal interface (not a linker interface, as is done now). This is yet to do, but again, QI were an essential precondition.
But some prefixes will remain, e.g. for C library interfaces. We could discuss changing our prefix to something even less likely con conflict (`_gpc_'? -- though we once had a problem with a libgpc in another package, so even that might not be unique enough) ... Any suggestions?
But this doesn't help in the short run. If it's only _p_initialize, we could perhaps rename it (though, that's just one of the few routines that are sometimes needed in user programs, namely for C programs with their own `main' that link to GPC code).
So perhaps one could talk with the plotutils developers first. If it's only an internal routine there (I don't know), it might be easier to rename that instead.
Frank