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

2016-03-20 Thread fredvs 
Aargh.

Indeed, the declaration of variable for the library-handle was wrong.
And FreeBSD is more strait than Linux and Windows.

I was focused on GetProcAddress but the bug was in LoadLibrary... ;-( 

Changing --> var lib_handle:TLibHandle=dynlibs.NilHandle;
solves everything, even in FreeBSD.

I am really sorry for all the noise.
But, thanks to you, I am very happy to have learned interesting things about
libraries (dlerror() is a pearl).

Conclusion, all ok for LoadLibrary and GetProcAddress() in FreeBSD too.

Many thanks my friends.

PS: Ewald --> you are very strong, well seen.

Fre;D




-
Many thanks ;-)
--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Mangle-name-in-fpc-FreeBSD-tp5724528p5724606.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

2016-03-20 Thread fredvs 
>> Why do you use "hn: Intege"hn: Integer" instead of "hn: TLibHandle"
> Excellent question...
> Because of... fpc...
>
> In fpc 64 bit unix : result of dynlibs.loadlibrary() is... a integer. 

Ooops,

How will I explain that ?...

In the pascal header of the library that gives problems this is defined :
var libhandle : {$IFDEF MSWINDOWS}longword{$ELSE}{$IFDEF
CPU32}longword{$ELSE}PtrInt{$ENDIF}{$ENDIF};

And in all the other library-headers that i use without problems it is
defined like this:
var libhandle:TLibHandle=dynlibs.NilHandle; 

Maybe (surely) the first definition is wrong.

I have to re-test the problematic library with
var libhandle:TLibHandle=dynlibs.NilHandle; 

and see if it is ok for GetProcAdress().

Maybe that was the problem.

Write you later.

PS: Sorry for all the noise but it is not easy.
FreeBSD, in his pkg install a_library gives only the main dynamic library
(.so).
All dependent-libraries are static (*.a).
So the end user has to re-compile all .a libraries to make it dynamic.

For the library in question: -> libmp4ff.a -->
gcc -shared -o libmp4ff.so.0.0.0 -Wl,--whole-archive libmp4ff.a
-Wl,--no-whole-archive

Then you have a dynamic library.

Huh, not so easy because there is the C war...
So you have to make:
gcc -shared -o libmp4ff.so.0.0.0 -Wl,--whole-archive libmp4ff.a
-Wl,--no-whole-archive
CC -shared -o libmp4ff.so.0.0.0 -Wl,--whole-archive libmp4ff.a
-Wl,--no-whole-archive
clang -shared -o libmp4ff.so.0.0.0 -Wl,--whole-archive libmp4ff.a
-Wl,--no-whole-archive
cpp -shared -o libmp4ff.so.0.0.0 -Wl,--whole-archive libmp4ff.a
-Wl,--no-whole-archive

And test each result with nm libmp4ff.so.0.0.0.
Finally, cpp gives something "doable".

And the problem was to know if that compiled library was ok.

Now, thanks to your help, I am sure the library is ok.

I feel bad to not have seen that the (surely) wrong declaration of
library_handle was maybe the cause of all the problems.

Fre;D










-
Many thanks ;-)
--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Mangle-name-in-fpc-FreeBSD-tp5724528p5724605.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

2016-03-20 Thread Ewald 
On 03/20/2016 05:32 PM, fredvs wrote:
>
>> Why do you use "hn: Intege"hn: Integer" instead of "hn: TLibHandle"
> Excellent question...
> Because of... fpc... 
>
> In fpc 64 bit unix : result of dynlibs.loadlibrary() is... a integer.
Well, if this is the case, then you should probably report a bug. The
man page of at least linux and freeBSD indicate that it should be a pointer.

However, I would like to note that on linux, using revision 32828,
TLibHandle is defined as a ptrint, which is correct.

-- 
Ewald

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

2016-03-20 Thread fredvs 
> That's totally OK, but the unit dynlibs is written for platform
> independence and I'd like to be able to use it on FreeBSD and at least
> Windows without having much $ifdefs and the like.

Huh,... me too...
I am sure that fpc team will find the solution.
But, before it will be integrate into new version of fpc, $ifdefs is the
fastest way to make my projects working.

Totally other thing...

Some time ago I noted here on fpc-mailing list that the size of
fpc-libraries is enormous vs same code for a fpc-program.
Somebody of fpc team promises to reduce the size (even without -fPIC).

I believe in the power of fpc-libraries (native or java-native), even more
than in the power of fpc-program.

Sadly, the size of a fpc library is very, very, very big, even in last fpc
3.1.1 trunk. (this without debug and stripped, of course)
Too big to compete with a c library (who does the same thing).

Does have fpc team project to reduce the size of fpc-libraries?

Many thanks.

Fre;D


 



-
Many thanks ;-)
--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Mangle-name-in-fpc-FreeBSD-tp5724528p5724603.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

2016-03-20 Thread Marc Santhoff 
On So, 2016-03-20 at 09:47 -0700, fredvs wrote:
> Re-hello.
> 
> To resume.
> 
> Here what is working perfectly for me:
> 
>  {$IF DEFINED(freebsd)}
> ...
>  var
> ap1 : pointer;
> begin
>   ap1 := dlopen(Pchar(mp4ff), 1);
>   Pointer(mp4ff_open_read) :=  dlsym(ap1, pchar('mp4ff_open_read'));
> ...
>  {$else}
> ...
>  var
> an1 : integer;
> begin
>   an1 := DynLibs.SafeLoadLibrary(PChar(mp4ff));
>   Pointer(mp4ff_open_read) :=  GetProcAddress(an1,
> pchar('mp4ff_open_read'));
> ...
>  {$endif}

That's totally OK, but the unit dynlibs is written for platform
independence and I'd like to be able to use it on FreeBSD and at least
Windows without having much $ifdefs and the like.

Have fun,
Marc

-- 
Marc Santhoff 

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

2016-03-20 Thread fredvs 
Re-hello.

To resume.

Here what is working perfectly for me:

 {$IF DEFINED(freebsd)}
...
 var
ap1 : pointer;
begin
  ap1 := dlopen(Pchar(mp4ff), 1);
  Pointer(mp4ff_open_read) :=  dlsym(ap1, pchar('mp4ff_open_read'));
...
 {$else}
...
 var
an1 : integer;
begin
  an1 := DynLibs.SafeLoadLibrary(PChar(mp4ff));
  Pointer(mp4ff_open_read) :=  GetProcAddress(an1,
pchar('mp4ff_open_read'));
...
 {$endif}

Fre;D



-
Many thanks ;-)
--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Mangle-name-in-fpc-FreeBSD-tp5724528p5724601.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

2016-03-20 Thread fredvs 
> For Fred:
> You can check the names inside a dynamic liobrary using system tools:

> nm -D /usr/lib/libipsec.so
> nm -D /usr/local/lib/vlc/plugins/codec/libx264_plugin.so

Thanks but... see my second mail in this topic... ;-)

Fre;D




-
Many thanks ;-)
--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Mangle-name-in-fpc-FreeBSD-tp5724528p5724600.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

2016-03-20 Thread fredvs 
>> Replacing all GetProcedureAdress() with dlsym()
>>
>> DOES THE TRICK ! ;-)

> Uhm, are you sure about this?

--> https://github.com/fredvs/uos

Try SimplePlayer example (all FreeBSD libraries are included in uos package)
--> choose /sound/test.m4a --> IT WORKS ;-)

> Could you add a "writeln(dlerror());" ate the "INDICATED
> POSITION"?
> Just curious about what is going on here...

See what I noted in previous mail :

GetProcedureAddress(hn, pchar('mp4ff_open_read');
writeln(dlerror());

---> Result:
Invalid shared object handle 0x2fb2800

> Why do you use "hn: Intege"hn: Integer" instead of "hn: TLibHandle"

Excellent question...
Because of... fpc... 

In fpc 64 bit unix : result of dynlibs.loadlibrary() is... a integer.

And for fpc <> unix 64 bit : result is a TLibHandle.

I agree it is strange.

By the way, many thanks for your bright light Ewald.

Fre;D





 



-
Many thanks ;-)
--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Mangle-name-in-fpc-FreeBSD-tp5724528p5724599.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

2016-03-20 Thread Marc Santhoff 
On So, 2016-03-20 at 15:10 +0100, Marc Santhoff wrote:
> On So, 2016-03-20 at 14:27 +0100, Ewald wrote:
> 
> > Could this be related to pointer trucation? The man page of dlopen tells
> > us that the return value is a pointer (hence the return value of
> > LoadLibrary has the same width). In your example you used an integer. Is
> > sizeof(Integer) = sizeof(Pointer) of your system?
> > 
> > If for example, you are missing the upper four bytes of the pointer, the
> > above message makes sense.
> 
> Good point:
> 
> marc@puma:/home/marc/program/Test_fpc/LoadLibrary > uname -mrs
> FreeBSD 9.1-STABLE amd64
> 
> marc@puma:/home/marc/program/Test_fpc/LoadLibrary > ./pointersize
> pointersize: 8
> size of integer: 2
> 
> marc@puma:/home/marc/program/Test_fpc/LoadLibrary > cat pointersize.pas 
> program pointersize;
> uses
>   sysutils;
> begin
>   writeln('pointersize: ' + inttostr(sizeof(pointer)));
>   writeln('size of integer: ' + inttostr(sizeof(integer)));
> end.

Doing it right it seems to work, I've tried three libs with one of them
definitely not part of the OS but from a port:

program loadlibrary;
{$mode objfpc}{$H+}
uses
  sysutils, dynlibs;
var
  //libname: string = '/usr/lib/libalias.so';
  //fncname: string = 'AddLink';
  //libname: string = '/usr/lib/libipsec.so';
  //fncname: string = 'ipsec_dump_policy';
  libname: string = '/usr/local/lib/vlc/plugins/codec/libx264_plugin.so';
  fncname: string = 'vlc_entry__1_1_0g';

  libhandle: TLibHandle;
  pfnc: pointer;
begin
  libhandle := dynlibs.LoadLibrary(pchar(libname));

  if (libhandle = 0) then begin
writeln('loading error: ' + GetLoadErrorStr);
halt(1);
  end else
writeln('library ' + libname + ' loaded.');

  pfnc := GetProcedureAddress(libhandle, pchar(fncname));
  if (pfnc = NIL) then
writeln('got proc address error: ' + GetLoadErrorStr)
  else begin
writeln('function ' + fncname + ' loaded.');
writeln(inttostr(qword(pfnc)));
  end;

  UnloadLibrary(libhandle);

end.

I did not call any of those functions, but their nakmes are found and
loaded by dlsym. For all three libraries the program worked fine.

For Fred:
You can check the names inside a dynamic liobrary using system tools:

nm -D /usr/lib/libipsec.so
nm -D /usr/local/lib/vlc/plugins/codec/libx264_plugin.so

The letters after the address tell the type of symbol, see

$ man nm

for an in detail explanation. Mostly those having a T are really inside
the library, U means unresolved and so linked fgrom another lib.


-- 
Marc Santhoff 

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Codepage + class helper raises "Error identifier idents no member ..."

2016-03-20 Thread Bart 
On 2/26/16, silvioprog  wrote:

> It compiles fine, but when you uncomment the line "//{$codepage utf8}", it
> raises:
>
> 'Error: identifier idents no member "Bar"'

@Silvio: Sven fixed it in trunk.
Can you test and report back in http://bugs.freepascal.org/view.php?id=29745
(I don't have fpc trunk)

Bart
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

2016-03-20 Thread Marc Santhoff 
On So, 2016-03-20 at 14:27 +0100, Ewald wrote:

> Could this be related to pointer trucation? The man page of dlopen tells
> us that the return value is a pointer (hence the return value of
> LoadLibrary has the same width). In your example you used an integer. Is
> sizeof(Integer) = sizeof(Pointer) of your system?
> 
> If for example, you are missing the upper four bytes of the pointer, the
> above message makes sense.

Good point:

marc@puma:/home/marc/program/Test_fpc/LoadLibrary > uname -mrs
FreeBSD 9.1-STABLE amd64

marc@puma:/home/marc/program/Test_fpc/LoadLibrary > ./pointersize
pointersize: 8
size of integer: 2

marc@puma:/home/marc/program/Test_fpc/LoadLibrary > cat pointersize.pas 
program pointersize;
uses
  sysutils;
begin
  writeln('pointersize: ' + inttostr(sizeof(pointer)));
  writeln('size of integer: ' + inttostr(sizeof(integer)));
end.

-- 
Marc Santhoff 

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

2016-03-20 Thread Ewald 
On 03/20/2016 01:11 PM, fredvs wrote:
>> Or simply dlerror() like in the other program, should work. 
> OK. here code + result of GetProcedureAddress(), maybe it could help for
> future fixes in fpc:
>
> GetProcedureAddress(hn, pchar('mp4ff_open_read');
> writeln(dlerror());
>
> ---> Result:
>
> "Invalid shared object handle 0x2fb2800"
>

Alright, ignore my previous mail, I'm lagging behind it seems  ;-)

Could this be related to pointer trucation? The man page of dlopen tells
us that the return value is a pointer (hence the return value of
LoadLibrary has the same width). In your example you used an integer. Is
sizeof(Integer) = sizeof(Pointer) of your system?

If for example, you are missing the upper four bytes of the pointer, the
above message makes sense.

-- 
Ewald

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

2016-03-20 Thread Ewald 
On 03/20/2016 12:56 AM, fredvs wrote:
> Re-hello (and last for tonight).
>
> Yep, yep, yep.
>
> Replacing all GetProcedureAdress() with dlsym()
>
> DOES THE TRICK ! ;-)

Uhm, are you sure about this? I always thought GetProcedureAddress
simply calls through to dlsym. If one works and the other doesn't, this
needs some more investigation I think?

Also, in you last example, quoted here:

--
Now with DynLibs:

procedure loadmylib(lib : pchar);
var
ap1: pointer;
hn : integer;
'
begin
/// with dynlibs
hn := dynlibs.loadlibrary(Pchar(lib));

if hn <> 0 then
writeln('loadlibrary() is OK') else
writeln('loadlibrary() is NOT OK') ;

ap1 := getprocedureaddress(hn, Pchar('mp4ff_open_read');

INDICATED POSITION


if ap1 <> nil then
writeln('getprocedureaddress() is OK') else
writeln('getprocedureaddress() is NOT OK') ;


end;
--

Could you add a "writeln(dlerror());" ate the "INDICATED POSITION"? 

Just curious about what is going on here...

PS: Why do you use "hn: Integer" instead of "hn: TLibHandle"? I don't know if 
it can be assumed that this handle will always be an integer (think, for 
example, pointer)? Just a thought.

-- 

Ewald

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

2016-03-20 Thread Marc Santhoff 
On So, 2016-03-20 at 05:11 -0700, fredvs wrote:
> >> ap1 := dlopen(Pchar(lib), 0);
> 
> > Here you are using 0 for three mode argument. One difference I can see
> > ist that uysing dynlibs.pas the mode is RTLD_LAZY like it should be, but
> > that constant is defined as 1. 
> 
> Huh, indeed, 0 is working in Linux but not in FreeBSD --> changed to 1 and
> all ok in FreeBSD.

So that's not the cause.

> > Or simply dlerror() like in the other program, should work. 
> 
> OK. here code + result of GetProcedureAddress(), maybe it could help for
> future fixes in fpc:
> 
> GetProcedureAddress(hn, pchar('mp4ff_open_read');
> writeln(dlerror());
> 
> ---> Result:
> 
> "Invalid shared object handle 0x2fb2800"

Doesn't tell much, I fear. I'll have to do same testing myself to find out.

> Many, many thanks to Marc, Marco, Ewald and Sven.

You're welcome, thanks for reporting and testing.

-- 
Marc Santhoff 

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Smartphone apps in FPC

2016-03-20 Thread Ingemar Ragnemalm 



Maciej Izak wrote:

Well, yes, it works fine, but you still need a Java part otherwise a
lot of APIs cannot be accessed. In particular APIs that require
creating interfaces.


I can confirm too :)


But for completeness, surely you do NOT have to write the Java (JVM) 
parts in Java, but you can write that too in FPC, right? I mean, using 
the FPC JVM compiler. But you need to interface JVM and native code like 
you do with Java code.



even is possible visual remote-debugging
from Lazarus (but that requires many IDE modifications).

wow, any link describing how to achieve that?

Work in progress.


I am looking forward to more information here! :)


/Ingemar

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

2016-03-20 Thread fredvs 
>> ap1 := dlopen(Pchar(lib), 0);

> Here you are using 0 for three mode argument. One difference I can see
> ist that uysing dynlibs.pas the mode is RTLD_LAZY like it should be, but
> that constant is defined as 1. 

Huh, indeed, 0 is working in Linux but not in FreeBSD --> changed to 1 and
all ok in FreeBSD.

> Or simply dlerror() like in the other program, should work. 

OK. here code + result of GetProcedureAddress(), maybe it could help for
future fixes in fpc:

GetProcedureAddress(hn, pchar('mp4ff_open_read');
writeln(dlerror());

---> Result:

"Invalid shared object handle 0x2fb2800"

Many, many thanks to Marc, Marco, Ewald and Sven.

Fre;D



-
Many thanks ;-)
--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Mangle-name-in-fpc-FreeBSD-tp5724528p5724593.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] crosscompiling problem (.a file)

2016-03-20 Thread Jonas Maebe 

On 20/03/16 09:05, ulrich wrote:

Dne 18.3.2016 v 9:37 Jonas Maebe napsal(a):

Try from a plain cmd.exe prompt instead then.


Thanks for your answers.

But when I added mingw directory to the PATH, I got the following result.


Don't add the mingw directory to the PATH. The problem is that the 
"make" program prefers any mingw/cygwin shell in the PATH over cmd.exe, 
and the FPC makefiles only work with cmd.exe as a shell under Windows.



Jonas

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] crosscompiling problem (.a file)

2016-03-20 Thread ulrich 

Dne 18.3.2016 v 9:37 Jonas Maebe napsal(a):

ulrich wrote:

Dne 16.3.2016 v 15:23 Jonas Maebe napsal(a):

ulrich wrote:

In Ming32 I ran the following command:
$ pwd
/c/lazarus16/fpc/3.0.0

$ make crossinstall CPU_TARGET=arm OS_TARGET=linux
CROSSBINDIR=/c/lazarus16/FPC/3.0.0/bin OPT=-dFPC_ARMEL
INSTALL_PREFIX=/c/lazarus16/FPC FPC=/c/lazarus16/FPC/3.0.0/bin/X86_
64-win64/FPC.

The result is:
system.pp (620) Error: Can not create archive file:
\c\lazarus16\fpc\3.0.0\RTL\units\x86_64-win64\libimpsystem.a



I have not installed the cygwin. Running a compilation from mingw
terminal.


Try from a plain cmd.exe prompt instead then.


Thanks for your answers.

But when I added mingw directory to the PATH, I got the following result.

C:\lazarus16\fpc\3.0.0>make all OS_TARGET=linux CPU_TARGET=x86_64 
FPC=C:\lazarus16\fpc\3.0.0\bin\x86_64-win64\fpc.exe
/c/lazarus16/fpc/3.0.0/"c:/mingw/msys/1.0/bin/make.EXE" compiler_cycle 
RELEASE=1
/bin/sh: /c/lazarus16/fpc/3.0.0/c:/mingw/msys/1.0/bin/make.EXE: No such 
file or directory

make.EXE": *** [build-stamp.x86_64-linux] Error 127

Rumisek



Jonas
___
fpc-pascal maillist  -
fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal




___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

2016-03-20 Thread Marc Santhoff 
On Sa, 2016-03-19 at 14:39 -0700, fredvs wrote:
> @ Marco and Marc thanks for help.
> 
> Sorry I do not have easy internet connection so I worked by my side.
> 
> I will try your tips.
> 
> By the way, here are my investigations:
> 
> 
> 
> Hello.
> 
> Ok, ok, understood and wow.
> 
> Added in code:
> 
> Function dlopen(filename: PChar; flags: cint): Pointer; cdecl; external;
> Function dlclose(handle: Pointer): cint; cdecl; external;
> Function dlsym(handle: Pointer; Name: PChar): Pointer; cdecl; external;
> Function dlerror: PChar; cdecl; external;
> 
> and, magic, it works. ;-)
> 
> Now the result:
> 
> In code:
> 
> procedure loadmylib(lib : pchar);
> var
> ap1, ap2, ap3 : pointer;
> '
> begin
> /// FreeBSD functions:
> ap1 := dlopen(Pchar(lib), 0);

Here you are using 0 for three mode argument. One difference I can see
ist that uysing dynlibs.pas the mode is RTLD_LAZY like it should be, but
that constant is defined as 1.

Does anyone now if this really makes a difference?

> if ap1 <> nil then
> writeln('dlopen() is OK') else
> writeln('dlopen() is NOT OK') ;
> 
> ap2 := dlsym(ap1, Pchar('mp4ff_open_read');
> if ap2 <> nil then
> writeln('dlsym() is OK') else
> writeln('dlsym() is NOT OK') ;
> 
> writeln(dlerror());
> 
> end;
> 
> ---> result:
> writeln('dlopen() is OK')
> writeln('dlsym() is OK')
> _ (no error)
> 
> --
> Now with DynLibs:
> 
> procedure loadmylib(lib : pchar);
> var
> ap1: pointer;
> hn : integer;
> '
> begin
> /// with dynlibs
> hn := dynlibs.loadlibrary(Pchar(lib));
> 
> if hn <> 0 then
> writeln('loadlibrary() is OK') else
> writeln('loadlibrary() is NOT OK') ;
> 
> ap1 := getprocedureaddress(hn, Pchar('mp4ff_open_read');
> 
> if ap1 <> nil then
> writeln('getprocedureaddress() is OK') else
> writeln('getprocedureaddress() is NOT OK') ;

Looking at dynlibs.pas you can use

  Function GetLoadErrorStr: string;

here. Or simply dlerror() like in the other program, should work.


> end;
> 
> --> result:
> 
> loadlibrary() is OK
> getprocedureaddress() is NOT OK
> 
> 
>  
> Conclusion: Maybe getprocedureaddress() has problems.

-- 
Marc Santhoff 

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal