[fpc-pascal] Mangle name in fpc-FreeBSD ?

[Marc Santhoff]

On Do, 2016-03-17 at 04:27 -0700, fredvs wrote:
> > it would be helpful to see the code fragments in question.
> > The declaration of the external functions if any and the code calling
> > LoadLibrary() and GetProcAddress(). 
> 
> Hello Mark and thanks for help.
> 
> Here declaration to load-getprocess:
> -----------------------------------------------------
> var
>   mp4ff_open_read    : function(f : p_mp4ff_callback_t) : mp4ff_t; cdecl;
>   libpointer : {$IFDEF MSWINDOWS}longword{$ELSE}{$IFDEF
> CPU32}longword{$ELSE}PtrInt{$ENDIF}{$ENDIF};
> ...
> 
> libpointer := DynLibs.SafeLoadLibrary(PChar(mp4ff)); -> OK for FreeBSD64
> too;-)
> 
>  Pointer(mp4ff_open_read) :=
>         GetProcAddress(hMp4ff, pchar('mp4ff_open_read')); -> Here always =
> nil for FreeBSD 64 ;-( (but ok for Linux + Windows)
> ...
> -----

When following the procedure calls I find:

<dynlibs.pas>
Function GetProcAddress(Lib : TlibHandle; const ProcName : AnsiString) :
Pointer;

begin
  Result:=GetProcedureAddress(Lib,Procname);
end;
</dynlibs.pas>

Next is:

<dynlibs.inc>
Function GetProcedureAddress(Lib : TLibHandle; const ProcName :
AnsiString) : Pointer;

begin
  Result:=dlsym(lib,pchar(ProcName));
end;
</dynlibs.inc>

Okay, man page says:

http://www.freebsd.org/cgi/man.cgi?query=dlsym&apropos=0&sektion=0&manpath=FreeBSD+10.2-RELEASE&arch=default&format=html

You could do some things, like trying to use the special handle
RTLD_NEXT, or and much more important, call dlerror() after the failing
dlsym(). It should tell _why_ the call failed.

> PS: I have the same problem for other libraries in FreeBSD 64 ->
> GetProcAddress() fail.
> PS2: It appends for some libraries in FreeBSD64, not all.

Intresting. I know there are differences in the systems dlopen() and
another similar variant installed by libtool, found in libbtdl regarding
to my notes. Dunno if it matters. Libtools implementation does
differentiate between OSs by itself (at compile time). Cold be a source
of confusion...

-- 
Marc Santhoff <M.Santhoff at web.de>