Trying to bind a C library

[alsor]

Hello,

I am trying to bind a C library and I am having trouble with forward declaration.
This is the C code:

Code: C  [Select][+][-]

1. // Forward declaration
2. struct StructA;
3.  
4. typedef void (*FunctionA)(const char* name, struct StructA result);
5.  
6. typedef struct StructA {
7.   FunctionA onComplete;
8. }
9.  

I'm a bit clueless on how to solve this cyclic dependency

Thank you! 

this is no c but c++ rather.

in the case of c all args must be scalars, newer structs.

try somethig like this:
typedef void (*FunctionA)(const char* name, struct StructA *result); // or & = reference in c++

there is a pointer to struct, not struct alone.

but this type of coding is rather stupid: try to use types only, without the struct keyword;

[engkin]

Hello,

I am trying to bind a C library and I am having trouble with forward declaration.
This is the C code:

Code: C  [Select][+][-]

1. // Forward declaration
2. struct StructA;
3.  
4. typedef void (*FunctionA)(const char* name, struct StructA result);
5.  
6. typedef struct StructA {
7.   FunctionA onComplete;
8. }
9.  

I'm a bit clueless on how to solve this cyclic dependency

Thank you! 

this is no c but c++ rather.

C++ expert you say.

[lumi]

I am just trying to make a binding of an existing library, this isn't my code.

I still am unable to use it cause of unresolved external symbol to stuff like _free, _realloc, _memcp (which I assume comes from the c runtime).

I tried adding {$LINKLIB c} at the top of my bindings but then the compiler tells me it cannot find the import library 'c'. I also tried to add my MinGW\lib folder to the included directory but it didn't really change anything.

(The static library was compiled with MinGW)

Thank you

[alsor]

these _free, _realloc, _memcp ...

can be declared correctly as externals c style, or rewritten simply to pas:

procedure _free(p :Pointer)
begin  pascalfree(p); end;

function _realloc(...)
begin pascalstandardrealoc...

_alloc -> some pascal alloc compatible: GetMem or...

ect.

this is simple.

[engkin]

these _free, _realloc, _memcp ...

can be declared correctly as externals c
ect.

this is simple.

It is "etc.", and he needs to link C runtime library, not only these three functions, Mr. Expert. 

[alsor]

No. You never include full c libs to the pas,
because this is superfluous - the pascal compliler contains and links the same libs!

About ten functions (redef) is necessary, no more.

With one exception: somebody want to work in pas, but using c libs, what is nonsense... use just c.
cpas/pasc - that language don't exists yet... as javapas.

[engkin]

Did you say link or include, Mr. Expert? 
You are THE expert here.

[MarkMLl]

No. You never include full c libs to the pas,
because this is superfluous - the pascal compliler contains and links the same libs!

I think you need to explain what you're trying to say there.

With one exception: somebody want to work in pas, but using c libs, what is nonsense... use just c.

Rubbish. As an example, it is entirely reasonable to want to use the facilities of Lazarus/LCL to put a UI around imported libraries written in other languages: C, python and the rest provided that they use a stable calling convention (note Sven's comment in another thread that C++ can be a problem since the stackframe can vary depending on the precise circumstances).

MarkMLl

[alsor]

What include?

In the linking stage... pfffffffffff.

Ok. I'm too stupid to instruct stupids.

[avk]

The expert was given two iron balls. He broke one and lost the other.

[alsor]

Try study some code:

function __open(PathName: PChar; Flags: Integer; Mode: Integer): Integer; cdecl;
  external libc name 'open';

function __close(Handle: Integer): Integer; cdecl;
  external libc name 'close';

function __read(Handle: Integer; Buffer: Pointer; Count: Cardinal): Cardinal; cdecl;
  external libc name 'read';

function __write(Handle: Integer; Buffer: Pointer; Count: Cardinal): Cardinal; cdecl;
  external libc name 'write';

function __mkdir(PathName: PChar; Mode: Integer): Integer; cdecl;
  external libc name 'mkdir';

function __getcwd(Buffer: PChar; BufSize: Integer): PChar; cdecl;
  external libc name 'getcwd';

function __getenv(Name: PChar): PChar; cdecl;
  external libc name 'getenv';

function __chdir(PathName: PChar): Integer; cdecl;
  external libc name 'chdir';

function __rmdir(PathName: PChar): Integer; cdecl;
  external libc name 'rmdir';

function __remove(PathName: PChar): Integer; cdecl;
  external libc name 'remove';

function __rename(OldPath, NewPath: PChar): Integer; cdecl;
  external libc name 'rename';

function strlen(OldPath, NewPath: PChar): Integer; cdecl;
  external libc name 'strlen';

procedure memcpy(Dest: Pointer; Source: Pointer; N: Integer); cdecl;
  external libc name 'memcpy';

{$IFDEF EFENCE}
function __malloc(Size: Integer): Pointer; cdecl;
  external 'libefence.so' name 'malloc';

procedure __free(P: Pointer); cdecl;
  external 'libefence.so' name 'free';

function __realloc(P: Pointer; Size: Integer): Pointer; cdecl;
  external 'libefence.so' name 'realloc';
{$ELSE}
function __malloc(Size: Integer): Pointer; cdecl;
  external libc name 'malloc';

procedure __free(P: Pointer); cdecl;
  external libc name 'free';

function __realloc(P: Pointer; Size: Integer): Pointer; cdecl;
  external libc name 'realloc';
{$ENDIF}

[MarkMLl]

Try study some code:

And your point is...?

MarkMLl

[alsor]

The key to omit this stupid linking is simpy - just recode these several functions:

function __malloc(Size: Integer): Pointer; cdecl;
begin Result := GetMem(size);end;

procedure __free(P: Pointer); cdecl;
begin  Free(P); end;

function __realloc(P: Pointer; Size: Integer): Pointer; cdecl;
begin Result := Realloc(P, size); end;


........

only the keyword: cdecl, must be preserved, because 'c' functions work in different way than in pas.

And even a compiler don't have the 'cdecl' directive, then you still can redefine this - using asm.

function __realloc(P: Pointer; Size: Integer): Pointer; assembler;
asm


... the c-calls leave parameters on the stack, then you must leave its - for the c-code callers.
end;


the double underlines: __ is also compiler dependent, because the c functions have only one underline _,
but some very programmers try to complicate even more this stuff, so, they all are masters, hence they add additional: _.

[MarkMLl]

@alcor you're still making no sense, and you're creating a lot of uneccessary noise in a thread where the original poster is still looking for help with his problem.

If you have anything coherent to say, please start your own thread.

MarkMLl

[MarkMLl]

I am just trying to make a binding of an existing library, this isn't my code.

I still am unable to use it cause of unresolved external symbol to stuff like _free, _realloc, _memcp (which I assume comes from the c runtime).

I tried adding {$LINKLIB c} at the top of my bindings but then the compiler tells me it cannot find the import library 'c'. I also tried to add my MinGW\lib folder to the included directory but it didn't really change anything.

(The static library was compiled with MinGW)

Just a mo. MinGW is more of a compatibility wrapper than anything else... do you mean that you compiled with gcc?

I'm by no means an expert at this and I tend to work on Linux rather than Windows, and most of what I've been doing recently which is remotely relevant is related to dynamic linkage. I think what I'd suggest is that working with GCC/MinGW you try to compile an example program (I presume something is supplied with the library you're using) and then look very carefully at the paths being set up in the makefile.

Beware of the possible situation where the library is explicitly invoking msvcrt.

Looking at bits of my code... I've not had to do a {$LINKLIB c} in a program that links in the HID libraries, or one that interfaces to Alsa, or one that wraps Python. But as I've said I'm no expert in this area, and there's a real possibility that you've got a combination that I've not.

MarkMLl