Re: [fpc-pascal] Mangle name in fpc-FreeBSD ?
Am 21.03.2016 00:33 schrieb "fredvs" : > > Aargh. > > Indeed, the declaration of variable for the library-handle was wrong. > And FreeBSD is more strait than Linux and Windows. Even on Win64 that would have been wrong as there TLibHandle is 64-bit as well and it also defines MSWINDOWS. Regards, Sven ___ 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 ?
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 ?
>> 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 ?
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 ?
> 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 ?
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 ?
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 ?
> 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 ?
>> 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 ?
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 ..."
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 ?
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 ?
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 ?
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 ?
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
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 ?
>> 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)
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)
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 ?
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