Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2011-08

Imposible call DLL (dylib) in Mac OSX Lion

13 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Juan Sánchez

Hello,
I'm going to start a new program in Lazarus based on Win32, Linux and Mac OSX. I'm making some previous test and I've found a problem. I write a DLL project and a Executable project. Executable project calls a very simple function in DLL. I cannot compile Exe project because a LD error in Mac. DLL (dylib) project compiles OK and with NM and OTOOL I can see function in OK.

If I include in Exe project:

function DllMessage(): Longint; stdcall; external 'project1';

and:

x:= DllMessage();

I get:

ld: symbol(s) not found for architecture i386
Error: Error while linking

at compiling.

I've tried with GetProcedureAddress (adapting code) and LoadLibrary loads the library but GetProcedureAddress returns nil.

Function in DLL is very simple:

function DllMessage(): Integer;
begin
 Result:= 1;
end;

I would like someone could help me.

Thanks a lot.
Best regards,
Juan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110806/339dd4c9/attachment.html>

Reply by email

Ludo Brands
to Juan Sánchez

ld: symbol(s) not found for architecture i386
Error: Error while linking

at compiling.

I've tried with GetProcedureAddress (adapting code) and LoadLibrary loads the library but GetProcedureAddress returns nil.

Function in DLL is very simple:

function DllMessage(): Integer;
begin
 Result:= 1;
end;

Did you export DllMessage() ?

exports DLLMessage;

Try from the console and run (change libyourlib.dylib with the name of your library):

nm libyourlib.dylib | grep -i DllMessage

and check if it is in the list.

Ludo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110806/56a56fe5/attachment.html>

Reply by email

Juan Sánchez
to Ludo Brands

Hello Ludo, thanks a lot. Yes. I included in exports the name of the function. In Win32 it goes ok but it is in Mac OSX where it doesn't go right.

With "nm" I get function name so it is on library.

Juan.
El 06/08/2011 16:16, "Ludo Brands" escribi?:

Show quoted text 28 lines
ld: symbol(s) not found for architecture i386 Error: Error while linking at compiling. I've tried with GetProcedureAddress (adapting code) and LoadLibrary loads the library but GetProcedureAddress returns nil. Function in DLL is very simple: function DllMessage(): Integer; begin Result:= 1; end; Did you export DllMessage() ? exports DLLMessage; Try from the console and run (change libyourlib.dylib with the name of

your

Show quoted text 7 lines
library): nm libyourlib.dylib | grep -i DllMessage and check if it is in the list. Ludo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110806/3ec4c54a/attachment.html>

Reply by email

Sven Barth
to Juan Sánchez: I'm going to start a new program in Lazarus based on Win32, Linux and Mac OSX. I'm making…
Juan S?nchez wrote 15 lines
Hello, I'm going to start a new program in Lazarus based on Win32, Linux and Mac OSX. I'm making some previous test and I've found a problem. I write a DLL project and a Executable project. Executable project calls a very simple function in DLL. I cannot compile Exe project because a LD error in Mac. DLL (dylib) project compiles OK and with NM and OTOOL I can see function in OK. If I include in Exe project: function DllMessage(): Longint; stdcall; external 'project1'; and: x:= DllMessage();

AFAIK you MUST add a "{$linklib project1}" on OS X if you want to use "external".

Regards,
Sven

Reply by email

Ludo Brands
to Juan Sánchez: Hello Ludo, thanks a lot. Yes. I included in exports the name of the function. In Win32…

Hello Ludo, thanks a lot. Yes. I included in exports the name of the function. In Win32 it goes ok but it is in Mac OSX where it doesn't go right.

With "nm" I get function name so it is on library.

For static linking, you should also add {$linklib mylib} to the project.
{$linklib project1} in your example.

Ludo

Juan.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110806/12979faa/attachment.html>

Reply by email

Ludo Brands
to Juan Sánchez: Hello Ludo, thanks a lot. Yes. I included in exports the name of the function. In Win32…

With "nm" I get function name so it is on library.

When you do a GetProcedureHandle for DllMessage, it will actually look for _DllMessage. That's the reason why GetProcedureHandle returns nil.

If you declare your function as _DllMessage, loading at runtime will work also.

Ludo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110806/a873b815/attachment.html>

Reply by email

Juan Sánchez
to Sven Barth: AFAIK you MUST add a "{$linklib project1}" on OS X if you want to use "external". Sven

Thanks a lot. Tonight at home I'l try it again.
Juan.
El 06/08/2011 18:44, "Sven Barth" escribi?:

Show quoted text 28 lines
On 06.08.2011 15:11, Juan S?nchez wrote: > Hello, > I'm going to start a new program in Lazarus based on Win32, Linux and > Mac OSX. I'm making some previous test and I've found a problem. I write > a DLL project and a Executable project. Executable project calls a very > simple function in DLL. I cannot compile Exe project because a LD error > in Mac. DLL (dylib) project compiles OK and with NM and OTOOL I can see > function in OK. > > If I include in Exe project: > > function DllMessage(): Longint; stdcall; external 'project1'; > > and: > > x:= DllMessage(); AFAIK you MUST add a "{$linklib project1}" on OS X if you want to use "external". Regards, Sven -- _______________________________________________ Lazarus mailing list http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110806/b5871002/attachment-0001.html>

Reply by email

Juan Sánchez
to Ludo Brands: Hello Ludo, thanks a lot. Yes. I included in exports the name of the function. In Win32…

Thanks a lot. Tonight at home I'l try it again.
Juan.
El 06/08/2011 18:54, "Ludo Brands" escribi?:

Show quoted text 20 lines
Hello Ludo, thanks a lot. Yes. I included in exports the name of the function. In Win32 it goes ok but it is in Mac OSX where it doesn't go right. With "nm" I get function name so it is on library. For static linking, you should also add {$linklib mylib} to the project. {$linklib project1} in your example. Ludo Juan.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110806/ef5e87ae/attachment.html>

Reply by email

Juan Sánchez
to Ludo Brands: With "nm" I get function name so it is on library. When you do a GetProcedureHandle for…

Thans again. I'l rename function and try it. I'l inform about the result. Juan.
El 06/08/2011 19:11, "Ludo Brands" escribi?:

Show quoted text 14 lines
With "nm" I get function name so it is on library. When you do a GetProcedureHandle for DllMessage, it will actually look for _DllMessage. That's the reason why GetProcedureHandle returns nil. If you declare your function as _DllMessage, loading at runtime will work also. Ludo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110806/6ff61ee7/attachment.html>

Reply by email

Juan Sánchez
to Ludo Brands: With "nm" I get function name so it is on library. When you do a GetProcedureHandle for…

It went all right with dynamic loading. "liknlib" gives me and error in linking time. So I think runtime loading of dll is better. What I don't know is what it's necessary rename functions with "_" at starting in Mac. Is it a bug?
Regards.
Juan.
El 06/08/2011 19:11, "Ludo Brands" escribi?:

Show quoted text 14 lines
With "nm" I get function name so it is on library. When you do a GetProcedureHandle for DllMessage, it will actually look for _DllMessage. That's the reason why GetProcedureHandle returns nil. If you declare your function as _DllMessage, loading at runtime will work also. Ludo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110807/958b75a2/attachment-0001.html>

Reply by email

Ludo Brands
to Juan Sánchez

It went all right with dynamic loading. "liknlib" gives me and error in linking time. So I think runtime loading of dll is better. What I don't know is what it's necessary rename functions with "_" at starting in Mac. Is it a bug?
Regards.
Juan.

It is not a bug. dlsym, the function used to find the address assumes C type of function names which are prefixed with _. Pascal doesn't prefix exported functions with _. See
http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPa ges/man3/dlsym.3.html, down the page, notes.

What is the error you are getting with {$linklib project1}? The messages window doesn't show all messages. Click right on the messages window and select "copy all shown and hidden messages to clipboard" or "Save all messages to file" to get everything.

Ludo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110807/4dddbc65/attachment.html>

Reply by email

Ludo Brands
to Ludo Brands

It went all right with dynamic loading. "liknlib" gives me and error in linking time. So I think runtime loading of dll is better. What I don't know is what it's necessary rename functions with "_" at starting in Mac. Is it a bug?
Regards.
Juan.

It is not a bug. dlsym, the function used to find the address assumes C type of function names which are prefixed with _. Pascal doesn't prefix exported functions with _. See
http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPa ges/man3/dlsym.3.html, down the page, notes.

To make porting easier you can use the alias modifier with $ifdef like this:

function DllMessage(): Longint; {$ifdef darwin} alias : '_DllMessage';
{$endif}
...
exports DllMessage;

This way, the function will be exported as _DllMessage on Darwin only, DllMessage on other platforms.

Ludo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110807/5010d71a/attachment.html>

Reply by email

Juan Sánchez
to Ludo Brands

Thanks a lot Ludo. Until tomorrow at evening I will not be able to test it in Mac. So tomorrow as soon I can copy mesages I'll type them here. Regards.
Juan.
El 07/08/2011 20:11, "Ludo Brands" escribi?:

Show quoted text 5 lines
It went all right with dynamic loading. "liknlib" gives me and error in linking time. So I think runtime loading of dll is better. What I don't

know

is what it's necessary rename functions with "_" at starting in Mac. Is it

a

Show quoted text 5 lines
bug? Regards. Juan. It is not a bug. dlsym, the function used to find the address assumes C
type
of function names which are prefixed with _. Pascal doesn't prefix

exported

functions with _. See

http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPa

ges/man3/dlsym.3.html, down the page, notes. To make porting easier you can use the alias modifier with $ifdef like

this:

Show quoted text 10 lines
function DllMessage(): Longint; {$ifdef darwin} alias : '_DllMessage'; {$endif} ... exports DllMessage; This way, the function will be exported as _DllMessage on Darwin only, DllMessage on other platforms. Ludo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110807/d266e6ab/attachment.html>

Reply by email