Bug 888805 - tritonus: incorrect placement of JNI *so files and jars
Summary: tritonus: incorrect placement of JNI *so files and jars
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: tritonus
Version: 18
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Stanislav Ochotnicky
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-12-19 14:41 UTC by Stanislav Ochotnicky
Modified: 2013-03-18 16:54 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-03-18 16:37:28 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Stanislav Ochotnicky 2012-12-19 14:41:30 UTC
While current guidelines are not clear, JNI files should be placed as follows:
*so JNI files go into %_libdir/%{name} private subdirectory
*jar files using System.load/loadLibrary go into _jnidir (/usr/lib/java)

You are free to synlink between _libdir/%{name} and _jnidir if you feel that's best approach for you.

Any use of System.loadLibrary is patched to instead use System.load for example of such modification see https://fedoraproject.org/wiki/User:Akurtakov/JavaPackagingDraftUpdate#Example

Comment 1 Gwyn Ciesla 2012-12-19 19:49:29 UTC
I can't even get it to build, and my java-fu is weak.  Who might be a good person(s) to ask for help?

Comment 2 Stanislav Ochotnicky 2013-01-03 11:07:48 UTC
I can have a look and hope I won't completely break it :-)

Comment 3 Florian Weimer 2013-03-17 18:41:32 UTC
With tritonus-fluidsynth-0.3.7-0.13.20101108cvs.fc17.x86_64, I see a further oddity: The file /usr/lib64/java/tritonus/libtritonusfluid.so is marked as ET_EXEC, not ET_DYN (as one would expect from a DSO).  It does not export any symbols, so it is difficult to see how it could be loaded by a JVM.

Comment 4 Stanislav Ochotnicky 2013-03-18 16:37:28 UTC
I have built version of tritonus in rawhide/F19 that should fix the issues. I've tested with freecol and it looks like it was able to decode vorbis files. That said there are probably other bugs but I'd say my work here is done.

Comment 5 Gwyn Ciesla 2013-03-18 16:54:22 UTC
Excellent, thank you!


Note You need to log in before you can comment on or make changes to this bug.