3.5.2 -> 4.0.0 strange failure relating to current directory?

[caprica]

Hi,

I have been using LibVLC successfully via JNA for many years.

With 4.0.0 I am seeing a new failure. It is specifically to do with how LibVLC loads its plugins.

When the native libvlc.dll is loaded, it uses the directory that the dll is located in as a root for a recursive search of the child "plugins" directory, and loads all the found plugins.

What I think is happening with JNA 4.0.0 is that it is somehow using the current directory of the Java process to do this recursive search, not the current directory that the DLL was loaded from.

If I use jNA 4.0.0 and leave the current directory as that of my project, it find and loads libvlc.dll, but libvlc fails to find the plugins.

If I use JNA 4.0.0 *and* set the current directory to the directory that contains the libvlc.dll, it works.

If I use 3.5.2 the exact same code works as expected no matter what I do with the current directory.

It is 100% repeatable showing it working and failing if I simply swap the versions of the JNA jar files.

So this behaviour has definitely changed with JNA 4.0.0.

Any ideas please?

[caprica]

A small correction in-line below...

On Sunday, 12 January 2014 19:42:33 UTC, caprica wrote:

If I use jNA 4.0.0 and leave the current directory as that of my project, it find and loads libvlc.dll, but libvlc fails to find the plugins.

If I use JNA 4.0.0 *and* set the current directory to the directory that contains the libvlc.dll, it works.

This second statement above is not true, it does not work under those conditions.

[Timothy Wall]

This is just a shot in the dark, but what if you rename “libvlc.dll” to “vlc.dll”, using “Native.loadLibrary(‘vlc’)”?

T.

> --
> You received this message because you are subscribed to the Google Groups "Java Native Access" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jna-users+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[caprica]

Hi,

Sadly the same problem is still observed.

-M.

[Timothy Wall]

With 4.0, you can run with -Djna.debug_load=true to see the specific loading steps taken by JNA.

I don’t think this is available prior to 4.0, but it might be.

[caprica]

Hi,

Thanks for the tip.

I tried it.

I can see that the libvlc dll is definitely itself being loaded correctly with JNA 4.0.0, I get a valid JNA proxy reference to the library - it's only going wrong *after* library initialisation when some code in libvlc itself attempts to discover its own plugins. So I think something is missing or changed from the environment/process/something that the dll is operating in as compared with JNA 3.5.2.

I can only think to try and build vlc for Win32 with some more debug in it to check precisely what the plugin loading code is doing - but building vlc for Windows is not so simple sadly.

Thanks!

-M.

[Dell Green]

I can confirm the same problem with my own experimental vlc binding swapping from 3.5.2 to 4.1.0. Mac os x and linux are fine just affects windows.

Will have to stay on jna 3.5.2 for now until its fixed or project panama in openjdk emerges whichever comes first :)

[Timothy Wall]

The only difference I can see between library loading on 3.5.2 and 4.x is that JNA attempts to convert the library path name into its “short” version via GetShortPathNameW.

Are you able to recompile JNA for windows? If so, changing this line should revert the change and see if that’s the issue.

+#define NAME2CSTR(ENV,JSTR) newWideCString(ENV,JSTR)
-#define NAME2CSTR(ENV,JSTR) w32_short_name(ENV,JSTR)

On Jun 18, 2014, at 2:51 PM, Dell Green <si.galaxy...@gmail.com> wrote:

> I can confirm the same problem with my own experimental vlc binding swapping from 3.5.2 to 4.1.0. Mac os x and linux are fine just affects windows.
>
> Will have to stay on jna 3.5.2 for now until its fixed or project panama in openjdk emerges whichever comes first :)
>

> --
> You received this message because you are subscribed to the Google Groups "Java Native Access" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jna-users+...@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

[Timothy Wall]

Here’s a version built without the path name size reduction. Some folks have reported that VLC can’t handle long path names. Perhaps the problem is that it is just ignorant of the path duality on windows.

[caprica]

Hello,

I can confirm swapping out the 4.1.0 jna.jar for the custom-built one you attached *did* work for me.

-M.

[Timothy Wall]

Apparently loading livlc using its windows short name results in it being unable to find its own plugins. Technically this is probably a bug in vlc.

One alternative is to attempt loading the “long” name prior to attempting the short name. The short name fix was to address issues with loading failures due to unicode in path names and/or long path names.

> --
> You received this message because you are subscribed to the Google Groups "Java Native Access" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jna-users+...@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

[caprica]

So what's the best way forward here?

I'm not a VLC developer although I have contributed to that project, but I have no idea how to create a patch that fixes this in VLC, and building VLC on Windows is not something I can do (Linux yes, Windows no). I think the VLC developers would likely be quite resistant to change this critical core functionality that has worked for them for a long time.

Staying with an older version of JNA is a possibility of course.

[Timothy Wall]

I’ll push out another release that “restores” the old behavior while also retaining the new. Might take me a couple of days to get to it, though.

[Dell Green]

Cool nice one ☺

[Timothy Wall]

Please try out the latest windows binaries from master.

Long filenames are attempted first, with the short version attempted only if the long one fails.

On Jul 31, 2014, at 5:50 PM, Dell Green <si.galaxy...@gmail.com> wrote:

> Cool nice one ☺

[caprica]

I only managed to get this working by deleting the jnidispatch.dll from the jna jar and replacing it with the one in the master jar. Just adding the 'patch' jar to the classpath first did not work for me, I'm not sure if it's supposed to or not.

Anyway, after manually patching the jar file, I was able to test this successfully.

[Eray Hangül]

Hi all,

I can not solve the problem although i changed the core source code of JNA. Please advice me something, i will be mad..:)

I downloaded source of JNA 4.0.0 and VLC4J 3.0.0. I open a new Eclipse project and with  -Djna.debug_load=true, I can see that JNA saw the VLC installed path if i put it to Windows System PATH environment variable. 

Although it saw the path of libvlc.dll, the Native.open(filePath, openFlag) returns no handle reference for openFlag = -1.

Interestingly, handle becomes a valid reference for built-in kernel32.dll and Advapi32.dll.

Anyway. So i put the open flag option as "2" hardcoded, and this gives me a valid handle refrence. 

I also changed the code in Library.java to put the options listed below :

* function-mapper

* type-mapper

But again result is negative..:( 

Although LibVlcFactory class has a LibVlc instance, there is no function on its Hashmap. So, the line indicated below normally says error that "There is no method like 'libvlc_get_version()' "

String nativeVersion = instance.libvlc_get_version();

So, any ideas? My debug info is like that :

Looking in classpath from sun.misc.Launcher$AppClassLoader@58644d46 for /com/sun/jna/win32-x86-64/jnidispatch.dll

Found library resource at jar:file:/D:/JavaWorkspace/VLC4J-3.0.0-Source/lib/jna-4.0.0.jar!/com/sun/jna/win32-x86-64/jnidispatch.dll

Looking for library 'Advapi32'

Adding paths from jna.library.path: C:\Program Files (x86)\VideoLAN\VLC

Trying Advapi32.dll

Found library 'Advapi32' at Advapi32.dll

Looking for library 'kernel32'

Adding paths from jna.library.path: C:\Program Files (x86)\VideoLAN\VLC

Trying kernel32.dll

Found library 'kernel32' at kernel32.dll

Looking for library 'libvlc'

Adding paths from jna.library.path: C:\Program Files (x86)\VideoLAN\VLC

Trying C:\Program Files (x86)\VideoLAN\VLC\libvlc.dll

Found library 'libvlc' at C:\Program Files (x86)\VideoLAN\VLC\libvlc.dll

Exception in thread "main" java.lang.RuntimeException: Failed to load the native library.

The error was "Error looking up function 'libvlc_get_version': The specified module could not be found.

".

Regards,

Eray / ISTANBUL

[Eray Hangül]

Hello again,

When i inspect the detail exception i see the error like that : "java.lang.UnsatisfiedLinkError: %1 is not a valid Win32 application."

So the error seems compatibility. My OS is Win7 64 bit. The libvlc.dll and libvlccore.dll is working with VLC player itself on OS without any problem.

Any ideas?

Eray

[Eray Hangül]

Hi again,

Although i tried vlcj-2.4.1 and jna-3.5.2 again the error is same : "java.lang.UnsatisfiedLinkError: %1 is not a valid Win32 application."

I also tried patched JNA 4.0.0 jar linked to this message loop with the changed DLL (jnidispatch @ 16 November), again no change. So, i wil try on my ubuntu. windows gave me only 3 days effort and an argument with my wife..:)

[caprica]

It seems to me the error you are experiencing is not related to this particular topic. This topic concerns loading of LibVLC's *plugins*, after LibVLC itself has been loaded.

Anyway...

Make sure that your JVM and your installation of VLC are both the same architecture, i.e. make sure they are both 32-bit or both 64-bit.

Use vlcj-3.1.0 and jna+platform 3.5.2.

Other than that I can't say what your problem might be, vlcj+JNA is a combination that has mostly worked very well on all platforms for >5 years. I test it regularly on Linux, OSX and Windows.

[Eray Hangül]

On Ubuntu 12.04 vlcj2.4.1 and JNA3.5.2 works perfectly. I will continue on Linux platform. Thanks for your suggestion but i am sure about my platform and its settings on Windows. 

Regards,

Eray

[Jannemann]

Hi,

I have a little Project using JNA 3.5.2 on Windows 7 64 bit.

I set the librarySearchPath relative to the working Directory ".\lib". This worked with JNA 3.5.2.

Then I changed to JNA 4.1.0 and the Library wasn't found anymore. I debugged the Library loading process in JNA and noticed, that it constructed a strange absolute Path for the dll.

It was:

C:\foo\workingdirectory\.\lib

The dot was interpreted as a Directory.

As soon as I changed the library search path to "lib" ist worked with JNA 4.1.0.

Maybe this has something to do with the plugin-loading-problem. Maybe the vlc-plugins-folder ist configured as relative path and resolved incorrectly??

Jan

[Eray Hangül]

Hi,

Currently i can run VLCJ on Win7 64 bit Linux with 32 bit installation of JVM and VLC natives.

You may follow these steps :

0-) Create your project and put jna-3.5.2.jar, platform-3.5.2.jar and vlcj-2.4.1.jar under your library directory (mostly it is "lib") and reference them.

1-) Download 32 bit jdk-6u45-windows-i586 from oracle.com. (http://www.oracle.com/technetwork/java/javase/downloads/java-archive-downloads-javase6-419409.html)

2-) Download 32 bit VLC player for example vlc-2.1.5-win32. (http://download.videolan.org/pub/videolan/vlc/2.1.5/win32/)

3-) After setup of 0 and 1, create a win32-x86 folder under source (mostly it is "src") folder of your project.

4-) Copy the libvlc.dll and libvlccore.dll from XXX\VideoLAN\VLC\ folder (The path where you choosed at step 2)

5-) Choose one of the test classes of VLCJ with main method or write your own code and set the VM arguments before running it :

-Djna.library.path="XXX@Step2\VideoLAN\\VLC"

-Djna.boot.library.path="XXX@Step2\VideoLAN\\VLC"

-Djna.debug_load=true

-Djna.no_sys=true

Then it will work.

If you want to distribute your running code as JAR, on export option choose "Extract required libraries..."

I tried, again tried, again tried; read lots of forums, write custom JNA codes and after lots of time, i found that the best and determined running approach for win7 64 bit platform likes as above.

Regards,

Eray

--
You received this message because you are subscribed to a topic in the Google Groups "Java Native Access" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jna-users/tQqiMLjJDC8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jna-users+...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Eray HANGÜL
The Ultimate Ex Coder @ ISTANBUL

[Eray Hangül]

Win7 64 bit Linux..:) I was joking sorry

Win7 64 bit only..:)