option -Fc

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

option -Fc

Aleksey Y. Ulasevich (STAKANOV)
What codepages supported by option "-Fc"?

--
Aleksey Y. Ulasevich (STAKANOV)
icq:26493224 http://stakanov.nm.ru

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Fast CGI units?

Matt Emson
Does anyone have a working link to the "Fast CGI" PASCAL implementation?
The link on the Units page is dead, and I could really do with the units
for a project I'm working on.

Alternatively, please feel free to send it here ( [hidden email]
) if you have the files..

TIA

M

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

static binding to C shared library (linux)

Alain Michaud
Hi,

 I would apreciate if someone could give me some advice please. In this
example:

cfunction = function(theparameter:cint):cint;cdecl;external'theclib';

It seems that this will not build unless I have the
file: /usr/local/include/theclib.h  

1-Is this true?
2-Does the FPC compiler read this .h file?
3-Does the linker read this file?
 

The C prototypes for the two functions that I want to use look like
this:

plPlotterParams * pl_newplparams(void)

or:

plPlotterParams * pl_newplparams

and:

int pl_setplparam (plPlotterParams * plotter_params, const char
*parameter, void *value)

or:
 
int pl_setplparam (plPlotterParams * plotter_params, const char
*parameter, char *value)
 
The two set of prototypes exists because of a switch: "NO_VOID_SUPPORT"
to accept different compilers.

1 - Does anyone knows which case my compiler uses? "void" or "no_void"?


The first function "pl_newplparams" is suposed to allocate a structure
then return a handle. It seems that it returns something different than
"nil" but I am not sure if it is valid however.

This pointer is used as a parameter for the second function
"pl_setplparam".

ERR := pl_setplparam(plotter_param,'PAGESIZE','letter');

As soon as I call the function I get an "access" exception at the offset
000000000. Although the function has 3 parameters, it could be the first
one (the pointer) that has the wrong type!

I have tried many things like this:

type
plplotterparams = record end;

function pl_newplparams:plplotterparams; cdecl; external 'plot';

function pl_setplparam (plotter_params:plplotterparams; const
parameter:PCHAR; value:PCHAR):cint; cdecl; external 'plot';
 
Can someone give me some hints on how to solve that problem. I have
spent the whole week-end on these three lines and I am quite frustrated
right now!  The package is called "libplot" ("plotutils") and I was
planning to put it on the web if I can get it to work. :(

May be there is a book, documentation or an example file that I could
use and was not aware of?

Thank you for reading

Alain Michaud



_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: static binding to C shared library (linux)

Tony Pelton
take what i have to say with a HUGE grain of salt because i have no
idea what i'm talking about.

On 1/16/06, Alain Michaud <[hidden email]> wrote:

> Hi,
>
>  I would apreciate if someone could give me some advice please. In this
> example:
>
> cfunction = function(theparameter:cint):cint;cdecl;external'theclib';
>
> It seems that this will not build unless I have the
> file: /usr/local/include/theclib.h
>
> 1-Is this true?
> 2-Does the FPC compiler read this .h file?
> 3-Does the linker read this file?

not sure about that, i haven't done alot of work with external 'C' libs.

i have called DLL's written in 'C' before though ... and haven't had
to worry about having the headers for them, as i've had Pascal files
with the right stuff in them.

>
>
> The C prototypes for the two functions that I want to use look like
> this:
>
> plPlotterParams * pl_newplparams(void)
>
> or:
>
> plPlotterParams * pl_newplparams
>
> and:
>
> int pl_setplparam (plPlotterParams * plotter_params, const char
> *parameter, void *value)
>
> or:
>
> int pl_setplparam (plPlotterParams * plotter_params, const char
> *parameter, char *value)
>
> The two set of prototypes exists because of a switch: "NO_VOID_SUPPORT"
> to accept different compilers.
>
> 1 - Does anyone knows which case my compiler uses? "void" or "no_void"?

well ... i think that is some sort of 'C' pedantry having to do with
whether you have to declare that your no-arg 'C' function takes 'void.

are you compiling this lib ? or is it already compiled for you ? or ?

i guess i should back up and ask the big question ... how are you
trying to use this 'C' lib ?

as a shared library ?

i don't think Pascal should care about the void/no_void thingy.

>
>
> The first function "pl_newplparams" is suposed to allocate a structure
> then return a handle. It seems that it returns something different than
> "nil" but I am not sure if it is valid however.

your function, as you've written it here, appears to be returning a
pointer to something of type 'plPlotterParams' ... presumably a
struct.

>
> This pointer is used as a parameter for the second function
> "pl_setplparam".
>
> ERR := pl_setplparam(plotter_param,'PAGESIZE','letter');
>
> As soon as I call the function I get an "access" exception at the offset
> 000000000. Although the function has 3 parameters, it could be the first
> one (the pointer) that has the wrong type!
>
> I have tried many things like this:
>
> type
> plplotterparams = record end;

i think you have a few issues :

a) you can't just make up your own record for the parameter type.

you've got to find the definition of plPlotterParams 'type' in the 'C'
source, and then define a type in Pascal that matches it.

presumably, it is a 'C' struct, so you care going to define a Pascal
"record" ... but you have to define the members of it properly.

once you've defined the "record" in Pascal to match the 'C' struct
(assuming that is what it is) ... i think your Pascal code will go
something like as follows :

Var my_params^ : pascal_plPlotterParams; // pointer to your pascal type

my_params := pl_newplparams();
pl_setplparams(my_params,....);

>
> function pl_newplparams:plplotterparams; cdecl; external 'plot';
>
> function pl_setplparam (plotter_params:plplotterparams; const
> parameter:PCHAR; value:PCHAR):cint; cdecl; external 'plot';
>
> Can someone give me some hints on how to solve that problem. I have
> spent the whole week-end on these three lines and I am quite frustrated
> right now!  The package is called "libplot" ("plotutils") and I was
> planning to put it on the web if I can get it to work. :(

so yeah ...

as i've said ... i _think_ you have 2 primary problems :

a) you've got to define a type in Pascal that matches the "type" that
your first function returns.
b) you've got to use Pascal "pointer" syntax when defining your
"handle" in Pascal for the variable you are going to use to capture
the pointer being return from your func.

btw ... i _suspect_ that, if you aren't going to _use_ the value being
return from the first function, you could just use a "void" pointer
type in pascal to retrieve the address of  the thing being emitted
from the first function ... and just pass it to the second.

Var my_point : Pointer;

my_point := firstfunction();
secondfunction(my_point);

... or something like that.

of course, if you actually want to manipulate the thing being
returned, to modify it's members or something ... you will have to
define stuff in Pascal so the compiler can generate the code needed to
get at the members within.

>
> Thank you for reading

all guesses ... but sure ...

>
> Alain Michaud

Tony

--
X-SA user ? 0.4 is out !
http://x-plane.dsrts.com
http://games.groups.yahoo.com/group/x-plane-foo/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: static binding to C shared library (linux)

Alain Michaud
Hi,

thank-you for the reply.  

1 - I compile the C library myself. I even use it from a C program
compiled by me. Therefore for the C part, I am sure that everything is
OK. I also know that the path, and all that works.

I can also access a string constant (the version number) from the
library using my pascal program.  

This makes me think that it has to do with the parameters. This one has
three. Unfortunately there is no other 'simple' function in the
library:

int pl_setplparam (plPlotterParams * plotter_params, const char
*parameter, void *value)

which I translate into:

function pl_setplparam (plotter_params:plplotterparams; const
parameter:PCHAR; value:PCHAR):cint; cdecl; external 'plot';

please look at the last two parameters: one is "const" while the other
is not. Does that looks OK to you? Should I always use the same variable
names as the .h file? What should I do with the f... "void"?

Is the "cint" type equivalent to C: "int"  ? should I use "smallint"
instead.


2 - Someone tells me that old compilers would accept " * int" while the
new compilers would prefer a variable name: "variable * int" or "void *
int". Unless this the other way around then I should not use the
NO_VOID_SUPORT. So  I guess I do not worry about that one any more.

3 - The file I have is "libplot.so" I think that this is a shared
library. Does that coresponds to "cdecl; external 'plot';"? If not, then
this is where my mistake was!!!!!!!

Is: external 'plot';  equivalent to: {$L liplot.so} or: {$Linklib
liplot.so} ?

4 - The structure  "plPlotterParams" is not defined in the .h file.
Belive it or not, there is only one line:

struct plPlotterParamsStruct plPlotterParams

I understand that this is just a name change and plPlotterParamsStruct
was the name used inside the library. Why is this not defined remains a
mistery for me! Apparently the linker just assumes that it is a pointer!

You are right. The "user" is not supposed to access the "struct"
directly. This is only a handle for the second function, therefore there
was no need to define it in the .h file.   I guess I can find the
definition in the source code! However It seems to me that a "generic"
pointer should do. (What if did not have the source code)

Is the pascal type "pointer" EQUIVALENT to the C operator: '*' to a
struct?  

Thank you so much for reading

Alain


On Mon, 2006-01-16 at 19:45 -0500, Tony Pelton wrote:

> take what i have to say with a HUGE grain of salt because i have no
> idea what i'm talking about.
>
> On 1/16/06, Alain Michaud <[hidden email]> wrote:
> > Hi,
> >
> >  I would apreciate if someone could give me some advice please. In this
> > example:
> >
> > cfunction = function(theparameter:cint):cint;cdecl;external'theclib';
> >
> > It seems that this will not build unless I have the
> > file: /usr/local/include/theclib.h
> >
> > 1-Is this true?
> > 2-Does the FPC compiler read this .h file?
> > 3-Does the linker read this file?
>
> not sure about that, i haven't done alot of work with external 'C' libs.
>
> i have called DLL's written in 'C' before though ... and haven't had
> to worry about having the headers for them, as i've had Pascal files
> with the right stuff in them.
>
> >
> >
> > The C prototypes for the two functions that I want to use look like
> > this:
> >
> > plPlotterParams * pl_newplparams(void)
> >
> > or:
> >
> > plPlotterParams * pl_newplparams
> >
> > and:
> >
> > int pl_setplparam (plPlotterParams * plotter_params, const char
> > *parameter, void *value)
> >
> > or:
> >
> > int pl_setplparam (plPlotterParams * plotter_params, const char
> > *parameter, char *value)
> >
> > The two set of prototypes exists because of a switch: "NO_VOID_SUPPORT"
> > to accept different compilers.
> >
> > 1 - Does anyone knows which case my compiler uses? "void" or "no_void"?
>
> well ... i think that is some sort of 'C' pedantry having to do with
> whether you have to declare that your no-arg 'C' function takes 'void.
>
> are you compiling this lib ? or is it already compiled for you ? or ?
>
> i guess i should back up and ask the big question ... how are you
> trying to use this 'C' lib ?
>
> as a shared library ?
>
> i don't think Pascal should care about the void/no_void thingy.
>
> >
> >
> > The first function "pl_newplparams" is suposed to allocate a structure
> > then return a handle. It seems that it returns something different than
> > "nil" but I am not sure if it is valid however.
>
> your function, as you've written it here, appears to be returning a
> pointer to something of type 'plPlotterParams' ... presumably a
> struct.
>
> >
> > This pointer is used as a parameter for the second function
> > "pl_setplparam".
> >
> > ERR := pl_setplparam(plotter_param,'PAGESIZE','letter');
> >
> > As soon as I call the function I get an "access" exception at the offset
> > 000000000. Although the function has 3 parameters, it could be the first
> > one (the pointer) that has the wrong type!
> >
> > I have tried many things like this:
> >
> > type
> > plplotterparams = record end;
>
> i think you have a few issues :
>
> a) you can't just make up your own record for the parameter type.
>
> you've got to find the definition of plPlotterParams 'type' in the 'C'
> source, and then define a type in Pascal that matches it.
>
> presumably, it is a 'C' struct, so you care going to define a Pascal
> "record" ... but you have to define the members of it properly.
>
> once you've defined the "record" in Pascal to match the 'C' struct
> (assuming that is what it is) ... i think your Pascal code will go
> something like as follows :
>
> Var my_params^ : pascal_plPlotterParams; // pointer to your pascal type
>
> my_params := pl_newplparams();
> pl_setplparams(my_params,....);
>
> >
> > function pl_newplparams:plplotterparams; cdecl; external 'plot';
> >
> > function pl_setplparam (plotter_params:plplotterparams; const
> > parameter:PCHAR; value:PCHAR):cint; cdecl; external 'plot';
> >
> > Can someone give me some hints on how to solve that problem. I have
> > spent the whole week-end on these three lines and I am quite frustrated
> > right now!  The package is called "libplot" ("plotutils") and I was
> > planning to put it on the web if I can get it to work. :(
>
> so yeah ...
>
> as i've said ... i _think_ you have 2 primary problems :
>
> a) you've got to define a type in Pascal that matches the "type" that
> your first function returns.
> b) you've got to use Pascal "pointer" syntax when defining your
> "handle" in Pascal for the variable you are going to use to capture
> the pointer being return from your func.
>
> btw ... i _suspect_ that, if you aren't going to _use_ the value being
> return from the first function, you could just use a "void" pointer
> type in pascal to retrieve the address of  the thing being emitted
> from the first function ... and just pass it to the second.
>
> Var my_point : Pointer;
>
> my_point := firstfunction();
> secondfunction(my_point);
>
> ... or something like that.
>
> of course, if you actually want to manipulate the thing being
> returned, to modify it's members or something ... you will have to
> define stuff in Pascal so the compiler can generate the code needed to
> get at the members within.
>
> >
> > Thank you for reading
>
> all guesses ... but sure ...
>
> >
> > Alain Michaud
>
> Tony
>
> --
> X-SA user ? 0.4 is out !
> http://x-plane.dsrts.com
> http://games.groups.yahoo.com/group/x-plane-foo/

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: static binding to C shared library (linux)

Tony Pelton
On 1/17/06, Alain Michaud <[hidden email]> wrote:
> Hi,
>
> thank-you for the reply.
>
> 1 - I compile the C library myself. I even use it from a C program
> compiled by me. Therefore for the C part, I am sure that everything is
> OK. I also know that the path, and all that works.

ok.

>
> I can also access a string constant (the version number) from the
> library using my pascal program.

ok.

>
> This makes me think that it has to do with the parameters. This one has
> three. Unfortunately there is no other 'simple' function in the
> library:
>
> int pl_setplparam (plPlotterParams * plotter_params, const char
> *parameter, void *value)
>
> which I translate into:
>
> function pl_setplparam (plotter_params:plplotterparams; const
> parameter:PCHAR; value:PCHAR):cint; cdecl; external 'plot';

i hope someone else on the list will jump in here ... but i'll stick
my neck out ...

i'm doing this off the top of my head ... you should really read the
doc for the compiler.

i think your first parameter should be declared as a _pointer_ to the type :

plotter_params : plplotterparams^;

and i think _technically_ that third param should be :

value : Pointer;

>
> Is the "cint" type equivalent to C: "int"  ? should I use "smallint"
> instead.

i'm not sure.

a smallint is a short in 'C' i think.

you really have to find out where cint is declared in your 'C'
environment and then look that up in the pascal doc.

you could try guessing ... and maybe it won't segfault.

>
> 2 - Someone tells me that old compilers would accept " * int" while the
> new compilers would prefer a variable name: "variable * int" or "void *
> int". Unless this the other way around then I should not use the
> NO_VOID_SUPORT. So  I guess I do not worry about that one any more.

that sounds like it is a define to deal with old/new style function
prototype stuff in 'C'.

i don't think this bit matters to Pascal.

>
> 3 - The file I have is "libplot.so" I think that this is a shared
> library. Does that coresponds to "cdecl; external 'plot';"? If not, then
> this is where my mistake was!!!!!!!

cdecl is a directive that declares the "calling convention" for the
function i think.

this makes it so that the pascal compiler knows how to generate code
to invoke the 'C' function and/or pass variables to the 'C' function.

the external is telling the pascal compiler that the function
implementation is "external" ... somewhere ... later.

i'm honestly not sure how the "name" thing works. i'd need to look that up.

i think the name ties to the "linker directive" in some way.

>
> Is: external 'plot';  equivalent to: {$L liplot.so} or: {$Linklib
> liplot.so} ?

well ... i think "external 'plot'" says "find this function in the
'plot' library".

i think the {$L libplot.so} says, link the libplot.so library.

i think there is some magic here ... in that the linker does some
things with these names.

so ... i think "plot" for your external declaration works, because the
linker, when it processes your {$L} directive, matches the "plot" with
"libplot.so" by stripping the "lib" and the ".so" portions to match
the names.

or something like that ...

its those two pieces though that tie everything together for the
linker, so that the linker knows that there is going to be a function
in an external library first, and then later, it tells the linker to
actually link the library, and during the link phase, the linker is
going to make sure it can "resolve externals" ... which is to say that
it makes sure that it can find all of the functions you declared
"extern" in the libraries you've told it to link.

>
> 4 - The structure  "plPlotterParams" is not defined in the .h file.
> Belive it or not, there is only one line:
>
> struct plPlotterParamsStruct plPlotterParams

there has to be more to this somewhere.

keep poking around in your header files.

>
> I understand that this is just a name change and plPlotterParamsStruct
> was the name used inside the library. Why is this not defined remains a
> mistery for me! Apparently the linker just assumes that it is a pointer!

i don't think this is right.

in order for you to use the 'struct' ... you have to know how it is composed.

>
> You are right. The "user" is not supposed to access the "struct"
> directly. This is only a handle for the second function, therefore there
> was no need to define it in the .h file.   I guess I can find the
> definition in the source code! However It seems to me that a "generic"
> pointer should do. (What if did not have the source code)
>
> Is the pascal type "pointer" EQUIVALENT to the C operator: '*' to a
> struct?

well ... i _think_ in Pascal :

"Pointer" in pascal is equivalent to "void*" in 'C'.

this is reffered to as a a "void pointer" or an "untyped pointer".

"typed" pointers are pointers that point at a known type of thing,
rather than just being known to point to an address :

Pascal : Var foo : Integer^;
'C' : int* foo;

i think that is how that works.

>
> Thank you so much for reading

sure.

>
> Alain

Tony

--
X-SA user ? 0.4 is out !
http://x-plane.dsrts.com
http://games.groups.yahoo.com/group/x-plane-foo/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: option -Fc

Martin Schreiber
In reply to this post by Aleksey Y. Ulasevich (STAKANOV)
On Monday 16 January 2006 11.54, Aleksey Y. Ulasevich (STAKANOV) wrote:

> What codepages supported by option "-Fc"?

If I read the code right: utf8, cp437,cp850,8859_1 (files cp437.pas cp850.pas
cp8859_1.pas).

Martin


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: static binding to C shared library (linux)

Гено Рупски
In reply to this post by Alain Michaud
В пн, 2006-01-16 в 23:07 -0500, Alain Michaud написа:

> This makes me think that it has to do with the parameters. This one has
> three. Unfortunately there is no other 'simple' function in the
> library:
>
> int pl_setplparam (plPlotterParams * plotter_params, const char
> *parameter, void *value)
>
> which I translate into:
>
> function pl_setplparam (plotter_params:plplotterparams; const
> parameter:PCHAR; value:PCHAR):cint; cdecl; external 'plot';

The proper function declarations should be:

type
  PPlPlotterParams = Pointer;

function pl_newplparams: PPlPlotterParams; cdecl; external 'plot';

function pl_setplparam(plotter_params: PPlPlotterParams; parameter:
PChar; value: PChar): longint; cdecl; external 'plot';

note that PPlPlotterParams is declared as pointer. It's easiest way when
you don't care what is the structure it is pointing to. Also notice that
the second parameter is desclared without const this is due to pascal
tranforming const parameters into pointers which is equivalent as
declaring second parameter as "parameter: PPChar".
>
> please look at the last two parameters: one is "const" while the other
> is not. Does that looks OK to you? Should I always use the same variable
> names as the .h file? What should I do with the f... "void"?

parameters names (even procedure names when using name) does not matter.
it only matters the parameters' types and calling convention.

>
> 2 - Someone tells me that old compilers would accept " * int" while the
> new compilers would prefer a variable name: "variable * int" or "void *
> int". Unless this the other way around then I should not use the
> NO_VOID_SUPORT. So  I guess I do not worry about that one any more.

you don't have to worry because in both ways the resulting lib is
compatible with your declaration.

>
> 3 - The file I have is "libplot.so" I think that this is a shared
> library. Does that coresponds to "cdecl; external 'plot';"? If not, then
> this is where my mistake was!!!!!!!

yes it is a shared library it corresponds to "cdecl; external 'plot';"
>
> Is: external 'plot';  equivalent to: {$L liplot.so} or: {$Linklib
> liplot.so} ?

external 'plot' - tells the linker in which lib to search for the
function while using {$L} or {$linklib} adds the library and when you
declare a function as external without specifying where it is located
the linker searches for the name in all libraries

Also please see the program h2pas in the utils section of free pascal.
It makes translation from headers to pascal very easy,

TIA,
Geno Roupsky

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: option -Fc

Florian Klämpfl
In reply to this post by Martin Schreiber
Martin Schreiber wrote:

> On Monday 16 January 2006 11.54, Aleksey Y. Ulasevich (STAKANOV) wrote:
>
>
>>What codepages supported by option "-Fc"?
>
>
> If I read the code right: utf8, cp437,cp850,8859_1 (files cp437.pas cp850.pas
> cp8859_1.pas).
>

You can load any code page file available from the unicode forum. However, this
code page is _only_ used for string constant to widestring conversions, nothing
else.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: option -Fc

Aleksey Y. Ulasevich (STAKANOV)
Florian Klaempfl пишет:

>Martin Schreiber wrote:
>
>  
>
>>On Monday 16 January 2006 11.54, Aleksey Y. Ulasevich (STAKANOV) wrote:
>>
>>
>>    
>>
>>>What codepages supported by option "-Fc"?
>>>      
>>>
>>If I read the code right: utf8, cp437,cp850,8859_1 (files cp437.pas cp850.pas
>>cp8859_1.pas).
>>
>>    
>>
>
>You can load any code page file available from the unicode forum. However, this
>code page is _only_ used for string constant to widestring conversions, nothing
>else.
>  
>
How I can use it? Where I can get more information (documentations,
tutorials, examples). Is it in FreePascal documentation?

I writing my sources in koi8-r code page, and I must convert my strings
to UCS2 (for example: x:=UTF8Decode(AnsiToUTF8('some koi8-r text '))).
Is it correct? May be I must write x:='some koi8-r text' and add '-FcXXXX'?

PS. Sorry for my English.

--
Aleksey Y. Ulasevich (STAKANOV)
icq:26493224 http://stakanov.nm.ru

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: static binding to C shared library (linux)

Alain Michaud
In reply to this post by Гено Рупски
Hi,

  Thank you to you all. After I wrote the declaration just like given
below, I had the library linked to my pascal program, and did not even
need to spend the week end on it!  :)

Thanks again to you all.

Alain Michaud

On Tue, 2006-01-17 at 10:34 +0200, Гено Рупски wrote:

> В пн, 2006-01-16 в 23:07 -0500, Alain Michaud написа:
> > This makes me think that it has to do with the parameters. This one has
> > three. Unfortunately there is no other 'simple' function in the
> > library:
> >
> > int pl_setplparam (plPlotterParams * plotter_params, const char
> > *parameter, void *value)
> >
> > which I translate into:
> >
> > function pl_setplparam (plotter_params:plplotterparams; const
> > parameter:PCHAR; value:PCHAR):cint; cdecl; external 'plot';
>
> The proper function declarations should be:
>
> type
>   PPlPlotterParams = Pointer;
>
> function pl_newplparams: PPlPlotterParams; cdecl; external 'plot';
>
> function pl_setplparam(plotter_params: PPlPlotterParams; parameter:
> PChar; value: PChar): longint; cdecl; external 'plot';
>
> note that PPlPlotterParams is declared as pointer. It's easiest way when
> you don't care what is the structure it is pointing to. Also notice that
> the second parameter is desclared without const this is due to pascal
> tranforming const parameters into pointers which is equivalent as
> declaring second parameter as "parameter: PPChar".
> >
> > please look at the last two parameters: one is "const" while the other
> > is not. Does that looks OK to you? Should I always use the same variable
> > names as the .h file? What should I do with the f... "void"?
>
> parameters names (even procedure names when using name) does not matter.
> it only matters the parameters' types and calling convention.
>
> >
> > 2 - Someone tells me that old compilers would accept " * int" while the
> > new compilers would prefer a variable name: "variable * int" or "void *
> > int". Unless this the other way around then I should not use the
> > NO_VOID_SUPORT. So  I guess I do not worry about that one any more.
>
> you don't have to worry because in both ways the resulting lib is
> compatible with your declaration.
>
> >
> > 3 - The file I have is "libplot.so" I think that this is a shared
> > library. Does that coresponds to "cdecl; external 'plot';"? If not, then
> > this is where my mistake was!!!!!!!
>
> yes it is a shared library it corresponds to "cdecl; external 'plot';"
> >
> > Is: external 'plot';  equivalent to: {$L liplot.so} or: {$Linklib
> > liplot.so} ?
>
> external 'plot' - tells the linker in which lib to search for the
> function while using {$L} or {$linklib} adds the library and when you
> declare a function as external without specifying where it is located
> the linker searches for the name in all libraries
>
> Also please see the program h2pas in the utils section of free pascal.
> It makes translation from headers to pascal very easy,
>
> TIA,
> Geno Roupsky
>

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal