[fpc-pascal] static binding to C shared library (linux)

[Tony Pelton]

On 1/17/06, Alain Michaud <Alain.Michaud at nrc-cnrc.gc.ca> 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/