SOLVED: OS X Strange compile error on a dylib

[tk]

Hi, having strange compile error when compiling a dylib (OS X Yosemite on Wmvare):

Code: [Select]

Free Pascal Compiler version 3.0.0 [2015/11/14] for i386
Copyright (c) 1993-2015 by Florian Klaempfl and others
(1002) Target OS: Darwin for i386
(3104) Compiling DrvLan.dpr
/Users/tk/Documents/drivers/lan/DrvLan.dpr(182,9) Warning: (5066) Symbol "GetTickCount" is deprecated: "Use GetTickCount64 instead"
<stdin>:3433:8: error: non-local symbol required in directive
.globl  LocalizationLoad
        ^
The error is only visible when compiling on command line (lazbuild). The compiler exits with exit code 256.

EDIT:  Is only problem when compiling libraries, I can normally build host application. I could not find anything on google about this error...

[tk]

Reply to myself, it seems that either I am totally stupid or somebody makes really bad joke on my account :

Code: Pascal  [Select][+][-]

1. library DrvLan;
2. ...
3.  
4. function LocalizationLoad(AHandle: TPluginHandle; AXmlLocalizationUTF8: PAnsiChar): Boolean; stdcall;
5. begin
6.   ConfigLocalization := AnsiString(AXmlLocalizationUTF8);
7.   Result := True;
8. end;
9.  
10. exports
11.   ...
12.   LocalizationLoad,
13.   ...
14.  

The function name is used only for this function in the whole library project.
And when I change the name LocalizationLoad to eg. SetLocalization the compilation works...

[skalogryz]

what happens if you use name LocalizationLoad2 ?

[tk]

Hmm, seems that every function name beginning with capital L aborts the compilation. localizationLoad already compiles fine.

Have looked with the nm utility at the exported names and they are ok (of course with the other name where I could compile the lib).

Have not yet tried to load the library and use it, however, will do tomorrow.

[skalogryz]

Let's revert to LocalizationLoad and try to play by OSX (unix) rules.
Try to change your function declaration to:

Code: Pascal  [Select][+][-]

1. function LocalizationLoad(AHandle: TPluginHandle; AXmlLocalizationUTF8: PAnsiChar): Boolean;
2. {$ifdef mswindows}stdcall;{$endif}
3. {$ifdef unix}cdecl;{$endif}
4. begin
5. ...
6.  

cdecl is the calling convention that should be used in OSX dylibs.

It should also take care of "L" problem

[tk]

cdecl solved this problem indeed, thank you.

Even more with stdcall the exported functions could not be loaded with GetProcAddress.

But FPC should clearly output a warning here...

EDIT: Under both Win and Linux stdcall worked fine.

[chenyuchih]

Excuse me, I am interesting in this issue....

Why Mac OS X/iOS don't let the library function name with capital "L" beginning?

Does it have any special meaning?

Is there any other rule that I need to be aware of?

Best Regards,
ChenYuChih

[tk]

I still don't know exactly, now think that function names cannot begin with "Loc". Not problem with FPC but Xcode that FPC needs: http://wiki.lazarus.freepascal.org/OS_X_Programming_Tips#Installing_Lazarus_and_Free_Pascal

[chenyuchih]

Well, according to my test, not only functions begin with "Loc" but also all functions with "L" begin would cause compiling error(Exit Code 256) in dynlib project.

Can anyone provide the naming constraint reference of Mac OS? It would be helpful for rookies like me when encountering such a weird problem.

Thanks in advance.

ChenYuChih

[Phil]

I'm not aware of any restrictions on naming .dylib functions.

See if this compiles for you, eg,

ppc386 libtest.pas
ppcx64 libtest.pas

Code: Pascal  [Select][+][-]

1. library libtest;
2.  
3. procedure LSomeFunc; {$IFDEF MSWINDOWS}stdcall{$ELSE}cdecl{$ENDIF};
4. begin
5. end;
6.  
7. exports
8.   LSomeFunc;
9.  
10. end.
11.  

[chenyuchih]

Okay, I found where the problem is. In my library, I kept the calling convention as "StdCall" and thought it would be seen as "CDecl", just like under Linux. My bad, sorry.

But there's something interesting. As long as the function name not begin with "L", the "StdCall" convention still compiles! I don't know why and what it output after compiling. Is it a bug or...?

Anyway, thanks Phil. You do me a favor again.

ChenYuChih

[Phil]

I don't know. I would never use stdcall with OS X or Linux libraries.

If you need stdcall for some reason, maybe file an FPC bug report.

Note that it's generally a good idea to add a prefix to each of your library's functions. As long as your prefix does not start with "L" you should be fine with stdcall too.

-Phil

[Jonas Maebe]

Okay, I found where the problem is. In my library, I kept the calling convention as "StdCall" and thought it would be seen as "CDecl", just like under Linux.

Stdcall does not mean the same as cdecl under Linux. The name mangling for them may be the same under Linux, but (at least for i386) the way parameters are passed is completely different.