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.
Regard
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.
>> 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 def
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.
> 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
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'));
> ...
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(PCh
> 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
>> 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(dle
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 e
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 trun
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
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:
>
> "I
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 does
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 wo
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
>> 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
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
"
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
IN
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, un
20 matches
Mail list logo
