dylib creation and usage

[Corvinian]

Hi,

Could someone tell me what might be going wrong with this procedure.  I am creating a dylib on Leopard 10.5.2 with the following function:

testdll.cpp:

Code: [Select]


extern "C" {

int testcall(int x)
{
  return x;
}

}

and compiling with the following line

g++ testdll.cpp -dynamiclib -o libtestdll.dylib

using nm on the resulting dylib produces the following entry

00000ff2 T _testcall

So I copy the dylib to both /usr/lib and /sw/lib and insert the following var line into my project:

Code: [Select]

function testcall(a : integer) : integer; cdecl; external 'testdll';

and inside a button click invoke it with

Code: [Select]

b := testcall(5);

and the project invariably fails linking with the following:

Undefined symbols:
  "_testcall", referenced from:
      UNIT1_TFORM1_$__BUTTON1CLICK$TOBJECT in Unit1.o
ld: symbol(s) not found

This same procedure works fine in the same project utilizing the likes of strlen from one of the standard libs.  I've also tried utilizing __attribute__((visibility("default"))) before the call in the library.  

Anyone have any suggestions as to why this is failing or provide a set of instructions on producing a minimally funcation dylib that works with Lazarus on the Mac?

Thanks

[Phil]

Anyone have any suggestions as to why this is failing or provide a set of instructions on producing a minimally funcation dylib that works with Lazarus on the Mac?

Try adding this below the function declaration in your Pascal file:

{$linklib testdll}

This is still required with OS X, I believe. I'm not sure where it's documented.

If you'll be compiling your .cpp on other platforms, you can put this around the linklib:

{$IFDEF DARWIN}
{$ENDIF}

Thanks.

-Phil

[Corvinian]

Thanks Phil.  I actually just solved it by adding a -ltestdll to the linker flags but I like your way better.  Its funny, had I been in C I wouldn't have thought twice about doing that.  I think I've carried over some of the ways Delphi spoiled me..

Thanks again.

[Phil]

Thanks Phil.  I actually just solved it by adding a -ltestdll to the linker flags but I like your way better.  Its funny, had I been in C I wouldn't have thought twice about doing that.  I think I've carried over some of the ways Delphi spoiled me..

Thanks again.

If your library will be used by multiple apps you can put it in a framework and install it in /Library/Frameworks. Then any app you create that's linked against your framework will find it regardless of where the app is installed.

Example of creating a framework:

http://wiki.lazarus.freepascal.org/Qt_Interface_Mac

Thanks.

-Phil