Prof A Olowofoyeku (The African Chief) wrote:
On 18 Mar 2005 at 14:02, Frank Heckenbach wrote:
Grmpf. We'd always assumed our `_p_' prefixes should be good enough to avoid such conflicts. Apparently not.
No, not in this case :(
BTW: it also has "_p_terminate" in case we ever consider using that name ...
I don't currently (we have `_p_finalize' instead).
To avoid this particular conflict, we could just upper-case the letter after `_p_'. But this may turn out too short-sighted in the future again ...
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?
How about: _gpc_<unitname>_foo { for units } _gpc_rts_foo { for RTS stuff } _gpc_<programname>_foo { for programs }
I don't really mind, but I don't want to have to rename them again sometime later. So we should be sure the new names are "unique enough" if we rename them now.
Waldek, what do you think?
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.
The libplot _p_initialize seems to be a method name in a C++ class. I renamed it for my tests, but I am not sure whether it will affect C++ programs. There is this comment: "/* The private `initialize' method, which is invoked when a Plotter is created. It is used for such things as initializing capability flags from the values of class variables, allocating storage, etc. When this is invoked, _plotter points to the Plotter that has just been created. */ "
Then there is also this (in extern.h): "#define _p_initialize PSPlotter::initialize" I have no idea what this means ...
They internally "rename" a C++ symbol. It probably doesn't help us avoid this conflict, as there also seems to be a real (C) `_p_initialize' function which conflicts on the linker level.
- On many platforms one can remove conflict using linker magic.
On windows using `LoadLibrary' and `GetProcAddress' on DLL should work without conflict.
Unfortunately, I have a static version of libplot the libraries. I built it myself, and it was rather straightforward. Indeed, I propose to release the binaries sometime, since I was never able to find prebuilt Win32 binaries.
To build it into a Windows DLL with gcc would require alchemy ...
It would only be a work-around anyway.
Frank