Hi
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' d:/mingw/lib/libplot.a(p_defplot.o):p_defplot.c:(.text+0x0): first defined here"
"p_defplot.c" has this: void #ifdef _HAVE_PROTOS _p_initialize (S___(Plotter *_plotter)) #else _p_initialize (S___(_plotter)) S___(Plotter *_plotter;) #endif
Any ideas?
Thanks.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof A Olowofoyeku (The African Chief) wrote:
Hi
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' d:/mingw/lib/libplot.a(p_defplot.o):p_defplot.c:(.text+0x0): first defined here"
"p_defplot.c" has this: void #ifdef _HAVE_PROTOS _p_initialize (S___(Plotter *_plotter)) #else _p_initialize (S___(_plotter)) S___(Plotter *_plotter;) #endif
Any ideas?
Thanks.
Best regards, The Chief
Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
First suggestion. The plot utilities has two redundant sets of prototypes, legacy and new "threadsafe." You might have both being called. I'll check some things later.
Also, I'll get the ada binding uploaded today. I need to get another ISP, my third email address in a month, fourth in six months. Nothing works here anymore, even the mail.
Rick.
On 18 Mar 2005 at 4:44, Rick Engebretson wrote:
Prof A Olowofoyeku (The African Chief) wrote:
Hi
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' d:/mingw/lib/libplot.a(p_defplot.o):p_defplot.c:(.text+0x0): first defined here"
[...]
First suggestion. The plot utilities has two redundant sets of prototypes, legacy and new "threadsafe." You might have both being called. I'll check some things later.
No. This is caused by a clashing export in the GPC runtime system (libgpc.a) and p_defplot.c.
Also, I'll get the ada binding uploaded today. I need to get another ISP, my third email address in a month, fourth in six months. Nothing works here anymore, even the mail.
I have the Ada binding. It is far too involved, and is not a direct translation of the C interface. What I have done is to translate "plot.h".
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
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
On 18 Mar 2005 at 14:02, Frank Heckenbach wrote:
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.
No, not in this case :(
BTW: it also has "_p_terminate" in case we ever consider using that name ...
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).
This code is in libplot. I am not sure how long that has existed ..
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?
How about: _gpc_<unitname>_foo { for units } _gpc_rts_foo { for RTS stuff } _gpc_<programname>_foo { for programs }
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 ...
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
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
On 24 Mar 2005 at 14:59, Frank Heckenbach wrote:
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 ...
Indeed ...
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.
Agreed. That is why I proposed names prefixed with "_gpc_" and including the name of the unit/program + the name of the symbol. This also avoids symbol duplication between units, although that is no longer a problem as we now have qualified identifiers. There is a theoretical risk of someone else hijacking the prefix "_gpc_", but I dobut that this is a realistic risk. If we think it is a realistic risk, then perhaps "_gnu_pascal_" would be a better prefix? (I think that is too long-winded).
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
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.
I think that `_p_initialize' is really the main problem. Namely, it one of few (maybe the only one) rts routine with user visible name -- if `main' is in another language users should call it. And the name is really good (so good that other packages also would like to use it :).
For user names the prefix really is `_p__' so there is no conflict (at least ATM). Also, our external names look like:
_p__M3_Foo_S0_Myfun
They already include unit name (`Foo' here) and routine name (forming that names is part of qualified identifier implementation).
We may easily change the prefix (I see no reason to change the other part, it was specially designed to be unique). However, I think that change in `plotutils' is preferable:
1) We need rather large namespace and use only a single prefix 2) They use quite a lot of single letter prefixes (and polute namespace quite heavily) so quite likely they will have to change their names anyway 3) The `_' prefix was intended for language implementation. Its use in general purpose library looks like an abuse 4) Our `_p_initialize' has to be in implementation space, but is also user visible. AFAICS `plotutils' just want private names which are not intended to be user visible
BTW Has anybody contacted `plotutils' developers? (I did not).
- 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.
IMHO what we are doing now (and what everbody else is doing) is really a work-around. Namely, it is linker job to integrate names from various source modules. In particular linker should have proper support for namespaces. It seems that no popular object format supports namespaces, but there is partial support: with GNU ld and ELF one can link a number of object files into a module and "localize" the symbols used internally. Similar things happen when using shared libraries.
The problem is that linker support is unportable and only partial, so everbody uses name-mangling, but I think that we need better linkers.
Waldek Hebisch wrote:
Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
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.
I think that `_p_initialize' is really the main problem. Namely, it one of few (maybe the only one) rts routine with user visible name -- if `main' is in another language users should call it. And the name is really good (so good that other packages also would like to use it :).
For user names the prefix really is `_p__' so there is no conflict (at least ATM). Also, our external names look like:
_p__M3_Foo_S0_Myfun
They already include unit name (`Foo' here) and routine name (forming that names is part of qualified identifier implementation).
We may easily change the prefix (I see no reason to change the other part, it was specially designed to be unique). However, I think that change in `plotutils' is preferable:
- We need rather large namespace and use only a single prefix
- They use quite a lot of single letter prefixes (and polute
namespace quite heavily) so quite likely they will have to change their names anyway 3) The `_' prefix was intended for language implementation. Its use in general purpose library looks like an abuse 4) Our `_p_initialize' has to be in implementation space, but is also user visible. AFAICS `plotutils' just want private names which are not intended to be user visible
BTW Has anybody contacted `plotutils' developers? (I did not).
- 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.
IMHO what we are doing now (and what everbody else is doing) is really a work-around. Namely, it is linker job to integrate names from various source modules. In particular linker should have proper support for namespaces. It seems that no popular object format supports namespaces, but there is partial support: with GNU ld and ELF one can link a number of object files into a module and "localize" the symbols used internally. Similar things happen when using shared libraries.
The problem is that linker support is unportable and only partial, so everbody uses name-mangling, but I think that we need better linkers.
I think GPC should redefine its _p_initialize to _pascal_initialize and have a reserved namespace. Rick.
Waldek Hebisch wrote:
Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
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.
I think that `_p_initialize' is really the main problem. Namely, it one of few (maybe the only one) rts routine with user visible name -- if `main' is in another language users should call it. And the name is really good (so good that other packages also would like to use it :).
Yes, one of a few -- `_p_finalize' is another one.
For user names the prefix really is `_p__' so there is no conflict (at least ATM). Also, our external names look like:
_p__M3_Foo_S0_Myfun
They already include unit name (`Foo' here) and routine name (forming that names is part of qualified identifier implementation).
These names should be ok, thanks to your encoding.
But there are some explicit linker names where C interfaces are involved (e.g., those units that have C parts, and in the RTS rts.c). These names are explicit, though not user-visible (only needed within the unit and the C code), so they can be changed rather easily, but it has to be done. Also, an encoding as above is probably not well suited here since it has to be written manually. Perhaps we could use something like `_p__M3_Foo_Bar' (the unit name doesn't usually change, and it's length can be counted manually once; the real identifiers don't conflict here as we want to use the same in C, so we don't do overloading etc.). Or what else?
We may easily change the prefix (I see no reason to change the other part, it was specially designed to be unique). However, I think that change in `plotutils' is preferable:
- We need rather large namespace and use only a single prefix
- They use quite a lot of single letter prefixes (and polute namespace quite heavily) so quite likely they will have to change their names anyway
Quite possible. (I haven't looked at plotutils closely.)
- The `_' prefix was intended for language implementation. Its use in general purpose library looks like an abuse
If this is so (I'm not really familiar with those namespace conventions), this would be a rather compelling argument. :-)
What's the mechanism for libraries, double-underscore? (I see that GMP uses `__gmp_*'.) However, ncurses uses `_nc_foo' for private routines, is this wrong then?
- Our `_p_initialize' has to be in implementation space, but is also user visible. AFAICS `plotutils' just want private names which are not intended to be user visible
Yes, then it's clearly easier for them to change.
BTW Has anybody contacted `plotutils' developers? (I did not).
Me neither.
Frank
Hi
I have run into some problems with the translation of libplot.
Given this declaration: plPlotter * pl_newpl_r (___const char *type, FILE *infile, FILE *outfile, FILE *errfile, const plPlotterParams *plotter_params);
and this call: if ((plotter = pl_newpl_r ("meta", stdin, stdout, stderr, plotter_params)) == NULL)
how would you translate the "FILE *foo" to GPC? Would it be "foo : file" or "var foo : file" or "foo : text" or "var foo : text" or "foo : pfile" { pfile = ^file } or "foo : ptext" { ptext = ^text }
or something else?
The issue here seems to be the precise equivalent of the C "FILE" struct. I believe that the library wants to write to these "FILE *" stuff.
Thanks.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof A Olowofoyeku wrote:
Hi
I have run into some problems with the translation of libplot.
<nip>
or something else?
The issue here seems to be the precise equivalent of the C "FILE" struct. I believe that the library wants to write to these "FILE *" stuff.
C "FILE" is an opaque pointer. Opaque means that all operations on it should go trough C library. It is completly different than Pascal file. AFAICS GPC has no support for C "FILE". In practice you can write:
type CFile = pointer;
You may use some tricks to ensure that all operations on CFile go trough library (like wrapping it iside a record or declaring it restricted). To really use it you need declarations for libc functions. Minimally:
function fopen(name : CString; mode CString): CFile; external name 'fopen'; function fclose(f : CFile) : CInteger; external name 'fclose';
and then: var f : CFile;
begin f := fopen('my_file.bin', 'rb'); if f = nil then begin writeln('Unable to open: ', 'my_file.bin'); Halt end; { Use f }
if fclose(f) <> 0 then writeln('Unable to close f');
On 21 Mar 2005 at 17:54, Waldek Hebisch wrote:
Prof A Olowofoyeku wrote:
Hi
I have run into some problems with the translation of libplot.
<nip> > or something else? > > The issue here seems to be the precise equivalent of the C "FILE" > struct. I believe that the library wants to write to these "FILE *" > stuff. >
C "FILE" is an opaque pointer. Opaque means that all operations on it should go trough C library. It is completly different than Pascal file. AFAICS GPC has no support for C "FILE". In practice you can write:
type CFile = pointer;
You may use some tricks to ensure that all operations on CFile go trough library (like wrapping it iside a record or declaring it restricted). To really use it you need declarations for libc functions. Minimally:
function fopen(name : CString; mode CString): CFile; external name 'fopen'; function fclose(f : CFile) : CInteger; external name 'fclose';
[...]
It is the libplot library itself that wants to write to these file pointers. It turns out that was I needed was a way to pass to the libplot routines pointers to the actual libc "stdin", "stdout" and "stderr", as opposed to Pascal implementations. I achieved it by writing a small C wrapper ("plotc.c"), with these:
#include <stdio.h> FILE *libc_stdin (void); FILE *libc_stdin (void) {return stdin;}
FILE *libc_stdout (void); FILE *libc_stdout (void) {return stdout;}
FILE *libc_stderr (void); FILE *libc_stderr (void) {return stderr;}
Then in the Pascal unit, I have "{$L plotc.c}", and then I declare these: Type TPlotFile = Pointer; Function libc_stdin : TPlotFile; external name 'libc_stdin'; Function libc_stdout : TPlotFile; external name 'libc_stdout'; Function libc_stderr : TPlotFile; external name 'libc_stderr';
So in the calling program I can pass the libc_std* to libplot routines, and everyone seems happy ...
It probably makes more sense to use external variables than external functions, but trying to make the libc_std* stuff into variables caused GPFs. I am not too bothered to try to sort it out, as the functions work perfectly well.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Ok folks, nearly there. How does one translate this to GPC? (I would hate to have to do it manually - but I am not sure how one can initialise an array of records on declaration like this):
struct hershey_word demo_word[NUM_DEMO_WORDS] = { {"Invitation", "HersheyScript-Bold", { 1., 0., 0., 1., -3125., 3980. }, 'l' }, {"ECONOMY", "HersheySans", { 1., 0., 0., 1., -3125., 3340. }, 'l'}, {"CARTOGRAPHY", "HersheySans", { CART, 0., 0., CART, -3125., 2700. }, 'l'}, {"Gramma", "HersheySerifSymbol", { 1., 0., 0., 1., -3125., 2060. }, 'l'}, {"\347\322\301\306\311\313\301", "HersheyCyrillic", { 1., 0., 0., 1., -3125., 1420. }, 'l'},
{"COMMUNICATION", "HersheySans-Bold", { 1., 0., 0., 1., 0., 3980. }, 'c'}, {"VERSATILITY", "HersheySerif-Italic", { 1., 0., 0., 1., 0., 3340. }, 'c'}, {"Standardization", "HersheySerif", { 1., 0., 0., 1., 0., 2700. }, 'c'}, {"Sumbolon", "HersheySerifSymbol", { INDEXICAL, 0., 0., INDEXICAL, 0., 2060. }, 'c'}, {"\363\354\357\366\356\357\363\364\370", "HersheyCyrillic", { 1., 0., 0., 1., 0., 1420. }, 'c'}, };
BTW: this is the declaration of the struct; struct hershey_word { char *word; char *fontname; double m[6]; char just; };
Thanks.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof A Olowofoyeku (The African Chief) wrote:
Ok folks, nearly there. How does one translate this to GPC? (I would hate to have to do it manually - but I am not sure how one can initialise an array of records on declaration like this):
I don't dare offer advice on libplot.
On a far simpler library of the libplot group (libxmi), I feel I have encouragement for Pascal devotees.
As I muddle through the macros, decipher the typedefs, unravel pointers to pointers, reconstruct structs, then write it into Pascal, I find I can chop C, hack C, burn C.
The more Pascal data structures replace C's ridiculous counterparts the better.
Prof A Olowofoyeku (The African Chief) a écrit:
Ok folks, nearly there. How does one translate this to GPC? (I would hate to have to do it manually - but I am not sure how one can initialise an array of records on declaration like this):
struct hershey_word demo_word[NUM_DEMO_WORDS] = { {"Invitation", "HersheyScript-Bold", { 1., 0., 0., 1., -3125., 3980. }, 'l' }, {"ECONOMY", "HersheySans", { 1., 0., 0., 1., -3125., 3340. }, 'l'}, {"CARTOGRAPHY", "HersheySans", { CART, 0., 0., CART, -3125., 2700. }, 'l'}, {"Gramma", "HersheySerifSymbol", { 1., 0., 0., 1., -3125., 2060. }, 'l'}, {"\347\322\301\306\311\313\301", "HersheyCyrillic", { 1., 0., 0., 1., -3125., 1420. }, 'l'},
{"COMMUNICATION", "HersheySans-Bold", { 1., 0., 0., 1., 0., 3980. }, 'c'}, {"VERSATILITY", "HersheySerif-Italic", { 1., 0., 0., 1., 0., 3340. }, 'c'}, {"Standardization", "HersheySerif", { 1., 0., 0., 1., 0., 2700. }, 'c'}, {"Sumbolon", "HersheySerifSymbol", { INDEXICAL, 0., 0., INDEXICAL, 0., 2060. }, 'c'}, {"\363\354\357\366\356\357\363\364\370", "HersheyCyrillic", { 1., 0., 0., 1., 0., 1420. }, 'c'}, };
BTW: this is the declaration of the struct; struct hershey_word { char *word; char *fontname; double m[6]; char just; };
The following compiles ----------------------------------------------------------------------- program translate;
const NUM_DEMO_WORDS=10; CART = 1.0; {guessed} INDEXICAL=2.0; {dito}
type hershey_word = record word: CString; fontname: CString; m: array [0..5] of double; just: char; end;
var demo_word : array [0..NUM_DEMO_WORDS-1] of hershey_word = ( ('Invitation', 'HersheyScript-Bold', ( 1.0, 0.0, 0.0, 1.0, -3125.0, 3980.0 ), 'l' ), ('ECONOMY', 'HersheySans', ( 1.0, 0.0, 0.0, 1.0, -3125.0, 3340.0 ), 'l'), ('CARTOGRAPHY', 'HersheySans', ( CART, 0.0, 0.0, CART, -3125.0, 2700.0 ), 'l'), ('Gramma', 'HersheySerifSymbol', ( 1.0, 0.0, 0.0, 1.0, -3125.0, 2060.0 ), 'l'), (chr(8#347)+chr(8#322)+chr(8#301)+chr(8#306)+chr(8#311)+chr(8#313)+chr(8#301), 'HersheyCyrillic', ( 1.0, 0.0, 0.0, 1.0, -3125.0, 1420.0 ), 'l'), ('COMMUNICATION', 'HersheySans-Bold', ( 1.0, 0.0, 0.0, 1.0, 0.0, 3980.0 ), 'c'), ('VERSATILITY', 'HersheySerif-Italic', ( 1.0, 0.0, 0.0, 1.0, 0.0, 3340.0 ), 'c'), ('Standardization', 'HersheySerif', ( 1.0, 0.0, 0.0, 1.0, 0.0, 2700.0 ), 'c'), ('Sumbolon', 'HersheySerifSymbol', ( INDEXICAL, 0.0, 0.0, INDEXICAL, 0.0, 2060.0 ), 'c'), (chr(8#363)+chr(8#354)+chr(8#357)+chr(8#366)+chr(8#356)+chr(8#357)+chr(8#363)+chr(8#364)+chr(8#370), 'HersheyCyrillic', ( 1.0, 0.0, 0.0, 1.0, 0.0, 1420.0 ), 'c') );
begin end. -------------------------------------------------------------------- Obtained basically with some search and replace in my editor (regex aware). The only tricky part is the replacement of octal numbers.
Maurice
On 22 Mar 2005 at 15:09, Maurice Lombardi wrote:
[...]
var demo_word : array [0..NUM_DEMO_WORDS-1] of hershey_word = ( ('Invitation', 'HersheyScript-Bold', ( 1.0, 0.0, 0.0, 1.0, -3125.0, 3980.0 ), 'l' ), ('ECONOMY', 'HersheySans', ( 1.0, 0.0, 0.0, 1.0, -3125.0, 3340.0 ), 'l'), ('CARTOGRAPHY', 'HersheySans', ( CART, 0.0, 0.0, CART, -3125.0, 2700.0 ), 'l'), ('Gramma', 'HersheySerifSymbol', ( 1.0, 0.0, 0.0, 1.0, -3125.0, 2060.0 ), 'l'), (chr(8#347)+chr(8#322)+chr(8#301)+chr(8#306)+chr(8#311)+chr(8#313)+chr(8 #301), 'HersheyCyrillic', ( 1.0, 0.0, 0.0, 1.0, -3125.0, 1420.0 ), 'l'), ('COMMUNICATION', 'HersheySans-Bold', ( 1.0, 0.0, 0.0, 1.0, 0.0, 3980.0 ), 'c'), ('VERSATILITY', 'HersheySerif-Italic', ( 1.0, 0.0, 0.0, 1.0, 0.0, 3340.0 ), 'c'), ('Standardization', 'HersheySerif', ( 1.0, 0.0, 0.0, 1.0, 0.0, 2700.0 ), 'c'), ('Sumbolon', 'HersheySerifSymbol', ( INDEXICAL, 0.0, 0.0, INDEXICAL, 0.0, 2060.0 ), 'c'), (chr(8#363)+chr(8#354)+chr(8#357)+chr(8#366)+chr(8#356)+chr(8#357)+chr(8 #363)+chr(8#364)+chr(8#370), 'HersheyCyrillic', ( 1.0, 0.0, 0.0, 1.0, 0.0, 1420.0 ), 'c') );
begin end.
Obtained basically with some search and replace in my editor (regex aware). The only tricky part is the replacement of octal numbers.
Yes, this works well, thanks. I had done the other translations but the octal stuff eluded me ...
Well, folks, I now have a functional GPC interface (unit) for libplot, and a working test program, thanks to Maurice.
Now, all we need is to sort out the "_p_initalize" duplicate symbol problem.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof A Olowofoyeku (The African Chief) wrote:
On 22 Mar 2005 at 15:09, Maurice Lombardi wrote:
[...]
var demo_word : array [0..NUM_DEMO_WORDS-1] of hershey_word = ( ('Invitation', 'HersheyScript-Bold', ( 1.0, 0.0, 0.0, 1.0, -3125.0, 3980.0 ), 'l' ), ('ECONOMY', 'HersheySans', ( 1.0, 0.0, 0.0, 1.0, -3125.0, 3340.0 ), 'l'), ('CARTOGRAPHY', 'HersheySans', ( CART, 0.0, 0.0, CART, -3125.0, 2700.0 ), 'l'), ('Gramma', 'HersheySerifSymbol', ( 1.0, 0.0, 0.0, 1.0, -3125.0, 2060.0 ), 'l'), (chr(8#347)+chr(8#322)+chr(8#301)+chr(8#306)+chr(8#311)+chr(8#313)+chr(8 #301), 'HersheyCyrillic', ( 1.0, 0.0, 0.0, 1.0, -3125.0, 1420.0 ), 'l'), ('COMMUNICATION', 'HersheySans-Bold', ( 1.0, 0.0, 0.0, 1.0, 0.0, 3980.0 ), 'c'), ('VERSATILITY', 'HersheySerif-Italic', ( 1.0, 0.0, 0.0, 1.0, 0.0, 3340.0 ), 'c'), ('Standardization', 'HersheySerif', ( 1.0, 0.0, 0.0, 1.0, 0.0, 2700.0 ), 'c'), ('Sumbolon', 'HersheySerifSymbol', ( INDEXICAL, 0.0, 0.0, INDEXICAL, 0.0, 2060.0 ), 'c'), (chr(8#363)+chr(8#354)+chr(8#357)+chr(8#366)+chr(8#356)+chr(8#357)+chr(8 #363)+chr(8#364)+chr(8#370), 'HersheyCyrillic', ( 1.0, 0.0, 0.0, 1.0, 0.0, 1420.0 ), 'c') );
begin end.
Obtained basically with some search and replace in my editor (regex aware). The only tricky part is the replacement of octal numbers.
Yes, this works well, thanks. I had done the other translations but the octal stuff eluded me ...
Of course, you could also convert the octal to (hexa)decimal numbers. It's just that C only allows octal numbers in characters (or does it allow hex meanwhile? At least originally it didn't AFAIK). Other than that, I see no particular reason for octals here (and almost anywhere else).
Frank
On 22 Mar 2005 at 22:28, Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
On 22 Mar 2005 at 15:09, Maurice Lombardi wrote:
[...]
var demo_word : array [0..NUM_DEMO_WORDS-1] of hershey_word = ( ('Invitation', 'HersheyScript-Bold', ( 1.0, 0.0, 0.0, 1.0, -3125.0, 3980.0 ), 'l' ), ('ECONOMY', 'HersheySans', ( 1.0, 0.0, 0.0, 1.0, -3125.0, 3340.0 ), 'l'), ('CARTOGRAPHY', 'HersheySans', ( CART, 0.0, 0.0, CART, -3125.0, 2700.0 ), 'l'), ('Gramma', 'HersheySerifSymbol', ( 1.0, 0.0, 0.0, 1.0, -3125.0, 2060.0 ), 'l'), (chr(8#347)+chr(8#322)+chr(8#301)+chr(8#306)+chr(8#311)+chr(8#313)+c hr(8 #301), 'HersheyCyrillic', ( 1.0, 0.0, 0.0, 1.0, -3125.0, 1420.0 ), 'l'), ('COMMUNICATION', 'HersheySans-Bold', ( 1.0, 0.0, 0.0, 1.0, 0.0, 3980.0 ), 'c'), ('VERSATILITY', 'HersheySerif-Italic', ( 1.0, 0.0, 0.0, 1.0, 0.0, 3340.0 ), 'c'), ('Standardization', 'HersheySerif', ( 1.0, 0.0, 0.0, 1.0, 0.0, 2700.0 ), 'c'), ('Sumbolon', 'HersheySerifSymbol', ( INDEXICAL, 0.0, 0.0, INDEXICAL, 0.0, 2060.0 ), 'c'), (chr(8#363)+chr(8#354)+chr(8#357)+chr(8#366)+chr(8#356)+chr(8#357)+c hr(8 #363)+chr(8#364)+chr(8#370), 'HersheyCyrillic', ( 1.0, 0.0, 0.0, 1.0, 0.0, 1420.0 ), 'c') );
begin end.
Obtained basically with some search and replace in my editor (regex aware). The only tricky part is the replacement of octal numbers.
Yes, this works well, thanks. I had done the other translations but the octal stuff eluded me ...
Of course, you could also convert the octal to (hexa)decimal numbers. It's just that C only allows octal numbers in characters (or does it allow hex meanwhile? At least originally it didn't AFAIK). Other than that, I see no particular reason for octals here (and almost anywhere else).
I wouldn't even know how to use octals ...
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof A Olowofoyeku (The African Chief) wrote:
It is the libplot library itself that wants to write to these file pointers. It turns out that was I needed was a way to pass to the libplot routines pointers to the actual libc "stdin", "stdout" and "stderr", as opposed to Pascal implementations. I achieved it by writing a small C wrapper ("plotc.c"), with these:
#include <stdio.h> FILE *libc_stdin (void); FILE *libc_stdin (void) {return stdin;}
FILE *libc_stdout (void); FILE *libc_stdout (void) {return stdout;}
FILE *libc_stderr (void); FILE *libc_stderr (void) {return stderr;}
Then in the Pascal unit, I have "{$L plotc.c}", and then I declare these: Type TPlotFile = Pointer; Function libc_stdin : TPlotFile; external name 'libc_stdin'; Function libc_stdout : TPlotFile; external name 'libc_stdout'; Function libc_stderr : TPlotFile; external name 'libc_stderr';
So in the calling program I can pass the libc_std* to libplot routines, and everyone seems happy ...
It probably makes more sense to use external variables than external functions, but trying to make the libc_std* stuff into variables caused GPFs. I am not too bothered to try to sort it out, as the functions work perfectly well.
Indeed, stdin etc. are not plain variables on many systems (they can be array references or pointer indirections via macros).
So functions returning them seems the only portable way to get them, and what you wrote is exactly what I'd have suggested.
Frank
Prof A Olowofoyeku wrote:
Hi
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' d:/mingw/lib/libplot.a(p_defplot.o):p_defplot.c:(.text+0x0): first defined here"
"p_defplot.c" has this: void #ifdef _HAVE_PROTOS _p_initialize (S___(Plotter *_plotter)) #else _p_initialize (S___(_plotter)) S___(Plotter *_plotter;) #endif
Any ideas?
1) Rename one of the offending symbols. IIRC `_p_initialize' is appears only twice in GPC sources. Or rename it in libplot.
2) On many platforms one can remove conflict using linker magic. On windows using `LoadLibrary' and `GetProcAddress' on DLL should work without conflict.
Waldek Hebisch wrote:
Prof A Olowofoyeku wrote:
Hi
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' d:/mingw/lib/libplot.a(p_defplot.o):p_defplot.c:(.text+0x0): first defined here"
"p_defplot.c" has this: void #ifdef _HAVE_PROTOS _p_initialize (S___(Plotter *_plotter)) #else _p_initialize (S___(_plotter)) S___(Plotter *_plotter;) #endif
Any ideas?
- Rename one of the offending symbols. IIRC `_p_initialize' is
appears only twice in GPC sources. Or rename it in libplot.
- On many platforms one can remove conflict using linker magic.
On windows using `LoadLibrary' and `GetProcAddress' on DLL should work without conflict.
Perhaps, this is a good example why C fails in larger programs. And why pascal is needed.
Rick Engebretson wrote:
Waldek Hebisch wrote:
Prof A Olowofoyeku wrote:
Hi
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' d:/mingw/lib/libplot.a(p_defplot.o):p_defplot.c:(.text+0x0): first defined here"
"p_defplot.c" has this: void #ifdef _HAVE_PROTOS _p_initialize (S___(Plotter *_plotter)) #else _p_initialize (S___(_plotter)) S___(Plotter *_plotter;) #endif
Any ideas?
- Rename one of the offending symbols. IIRC `_p_initialize' is
appears only twice in GPC sources. Or rename it in libplot.
- On many platforms one can remove conflict using linker magic.
On windows using `LoadLibrary' and `GetProcAddress' on DLL should work without conflict.
Perhaps, this is a good example why C fails in larger programs. And why pascal is needed.
There is a C++ API to libplot. Don't know if that's helpful. I'll look into it.
On 18 Mar 2005 at 14:28, Waldek Hebisch wrote:
Prof A Olowofoyeku wrote:
Hi
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' d:/mingw/lib/libplot.a(p_defplot.o):p_defplot.c:(.text+0x0): first defined here"
"p_defplot.c" has this: void #ifdef _HAVE_PROTOS _p_initialize (S___(Plotter *_plotter)) #else _p_initialize (S___(_plotter)) S___(Plotter *_plotter;) #endif
Any ideas?
- Rename one of the offending symbols. IIRC `_p_initialize' is
appears only twice in GPC sources. Or rename it in libplot.
I would move to rename it in GPC.
- 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 ...
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof A Olowofoyeku (The African Chief) wrote:
Hi
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' d:/mingw/lib/libplot.a(p_defplot.o):p_defplot.c:(.text+0x0): first defined here"
"p_defplot.c" has this: void #ifdef _HAVE_PROTOS _p_initialize (S___(Plotter *_plotter)) #else _p_initialize (S___(_plotter)) S___(Plotter *_plotter;) #endif
Any ideas?
Thanks.
Best regards, The Chief
Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Looking at the source of libplot. The plotter C files are merely prefixed according to types. Thus, at first glance, _p_initialize only effects the "postscript" type plotter. That is why the ada bindings probably separated the plotter types.
Anyway, _p_initialize does not appear to be an essential component of the library. But I've been wrong before (*millions).
-
Frank Heckenbach -
Maurice Lombardi -
Prof A Olowofoyeku (The African Chief) -
Rick Engebretson -
Waldek Hebisch