/usr/lib/jni support in Fedora
by Florian Weimer
As far as I can tell, currently, System.loadLibrary() is mostly unusable
for Java libraries because they cannot influence the library search
path. If you want to transparently load a DSO, you need to use
System.load() and hard-code the path. This probably means patching
upstream sources.
Debian patches the default search path so that System.loadLibrary()
searches /usr/lib/jni for DSOs with native code. This means that
classes which call System.loadLibrary() just work, assuming that the
Debian package installs its DSOs into /usr/lib/jni.
Can we do something similar in Fedora? We probably want /usr/lib/jni
and /usr/lib64/jni, for consistency with the rest of the system.
The upstream default search path starts with
"/usr/java/packages/lib/amd64" (and variants for other architectures),
but this isn't mentioned in the Fedora guidelines. I'm also not sure if
we want to use this file system location because it doesn't look
particularly FHS-compliant. But the proprietary JDKs could install a
symlink there so that /usr/lib{,64}/jni is searched as well.
--
Florian Weimer / Red Hat Product Security
8 years, 10 months
Re: [fedora-java] /usr/lib/jni support in Fedora
by Florian Weimer
On 07/29/2014 01:17 PM, Jiri Vanek wrote:
> On 07/29/2014 01:05 PM, Florian Weimer wrote:
>> As far as I can tell, currently, System.loadLibrary() is mostly
>> unusable for Java libraries because
>> they cannot influence the library search path. If you want to
>> transparently load a DSO, you need to
>> use System.load() and hard-code the path. This probably means
>> patching upstream sources.
>>
>> Debian patches the default search path so that System.loadLibrary()
>> searches /usr/lib/jni for DSOs
>> with native code. This means that classes which call
>> System.loadLibrary() just work, assuming that
>> the Debian package installs its DSOs into /usr/lib/jni.
>>
>> Can we do something similar in Fedora? We probably want /usr/lib/jni
>> and /usr/lib64/jni, for
>> consistency with the rest of the system.
>
> Then the most simple way is to provide symlinks in
> java-1.{7,8}.0-openjdk spec
>
> from /usr/lib/jni | /usr/lib64/jni, -to> /usr/lib/jvm/java..../... ?
(Cc:ing the mailing list again.)
Is it a good idea to install files from RPMs through a symbolic link? I
suspect it's not, which would mean we'd have to use the upstream default
"/usr/java/packages/lib/amd64" in spec files (probably using a macro).
If that path is acceptable, it would be fine with me as well, but it
looks a bit ugly to me. It certainly has the advantage of being
compatible with both the proprietary JDKs and the Debian packaging
(which keeps this search path entry, it only adds /usr/lib/jni).
--
Florian Weimer / Red Hat Product Security
8 years, 10 months
Re: [fedora-java] /usr/lib/jni support in Fedora
by Florian Weimer
On 07/29/2014 04:09 PM, Christopher wrote:
> As far as I can tell, currently, System.loadLibrary() is mostly
> unusable for Java libraries because they cannot influence the
> library search path. If you want to transparently load a DSO, you
> need to use System.load() and hard-code the path. This probably
> means patching upstream sources.
>
>
> To be clear, you can use LD_LIBRARY_PATH, or -Djava.library.path to
> influence the search path in any launch scripts, just like you'd control
> the bootstrap classpath in those same scripts. By choosing to use
> System.loadLibrary(), instead of System.load(), the developer has
> already decided to defer any influence over the search path to something
> external, like a script (or the system's ld cache), so I've not found
> this to be much of a limitation. I'm sure there are arguments against
> doing this, but it is imprecise to say that it's not possible.
It's not possible from a library (unless you provide your own class
loader, as David explained). A library cannot influence how the
launcher is invoked.
> Debian patches the default search path so that System.loadLibrary()
> searches /usr/lib/jni for DSOs with native code. This means that
> classes which call System.loadLibrary() just work, assuming that the
> Debian package installs its DSOs into /usr/lib/jni.
>
>
> Forgive my ignorance, but what exactly is wrong with just using
> /usr/lib[64], and how does putting them in a separate directory from
> other system shared libraries offer any greater degree of control?
These Java DSOs are not for general system use. Programmers are not
supposed to link against them, for instance. ldconfig processing of
files in /usr/lib{,64} is potentially harmful as well.
The (non-Java) Fedora Packaging Guidelines seem to imply to me that such
DSOs should not be put into /usr/lib{,64}, but the wording isn't
completely clear. See
<http://fedoraproject.org/wiki/Packaging:Guidelines#Devel_Packages> and
the paragraph starting with “As an additional complication, some
software generates unversioned shared objects which are not intended to
be used as system libraries.”
The Debian Policy does not explicit prevents using /usr/lib, either but
I assume that putting the JNI DSOs there (or the equivalent multi-arch
directory) would be problematic.
--
Florian Weimer / Red Hat Product Security
8 years, 10 months
Request for help packaging PyCharm for the Fedora Workstation
by Christian Schaller
Hi everyone,
I am part of the Fedora Workstation working group and and one application I would love to have included and easily available
for the workstation is PyCharm (http://www.jetbrains.com/pycharm/).
It is probably the best Python IDE available currently and thus can be a great tool for python developers on our platform. Especially with the rising importance of OpenStack I would love it if the Fedora Workstation would be able to offer this application. It also supports GTK3 module imports so it is a also great choice for desktop Python development.
Despite being a Python IDE it is written in Java, so I am asking if there are any volunteers on this list willing to help with packaging
it. I exchanged some emails with Stanislav Ochonicky and Mikolaj Izdebski and they suggested I send an email to this list requesting volunteers.
There are some licensing challenges with PyCharm as can be seen in this
bug tracker : http://youtrack.jetbrains.com/issue/PY-11008
But Stanislav had a quick look and it seems we should have most of the
libraries covered already:
javahelp - Fedora has javahelp2
oromatcher - Fedora has jakarta-oro
sqljet - packaged in Fedora
svnkit - packaged in Fedora
Mikolaj has offered to help, but he doesn't want to be the sole maintainer, so I am hoping to get some more volunteers here.
Myself and Kalev Lember are also both available to help anyway
we can, and if someone is willing to work with us on the core packaging
we can handle creating appdata files etc., for PyCharm.
Sincerely,
Christian Schaller
8 years, 11 months
Fwd: [Bug 1115920] New: FTBFS on AArch64: java.lang.OutOfMemoryError: Java heap space
by Orion Poplawski
It appears that on the aarch64 koji builders:
uintx MaxHeapSize := 268435456
{product}
(see http://arm.koji.fedoraproject.org//work/tasks/8913/2478913/build.log)
compared to 2623537152 (x86_64), 1073741824 (i686), 268435456 (armv7hl)
(http://koji.fedoraproject.org/koji/taskinfo?taskID=7114637).
Is this just a side-effect of the RAM size of the builders or something
else? Seems like this might cause issues elsewhere as well and am
wondering if a proper fix belongs elsewhere.
- Orion
-------- Original Message --------
Subject: [Bug 1115920] New: FTBFS on AArch64:
java.lang.OutOfMemoryError: Java heap space
Date: Thu, 03 Jul 2014 10:43:40 +0000
From: bugzilla(a)redhat.com
To: orion(a)cora.nwra.com
https://bugzilla.redhat.com/show_bug.cgi?id=1115920
Bug ID: 1115920
Summary: FTBFS on AArch64: java.lang.OutOfMemoryError: Java
heap space
Product: Fedora
Version: rawhide
Component: vtk
Assignee: axel.thimm(a)atrpms.net
Reporter: mjuszkie(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: axel.thimm(a)atrpms.net, fdc(a)fcami.net,
jonathan.underwood(a)gmail.com, mrceresa(a)gmail.com,
orion(a)cora.nwra.com
Description of problem:
Building of vtk on AArch64 fails with:
The system is out of resources.
Consult the following stack trace for details.
java.lang.OutOfMemoryError: Java heap space
at com.sun.tools.javac.code.Scope$ImportScope.makeEntry(Scope.java:526)
at com.sun.tools.javac.code.Scope.enter(Scope.java:220)
at com.sun.tools.javac.code.Scope.enter(Scope.java:202)
at
com.sun.tools.javac.code.Scope$StarImportScope.importAll(Scope.java:549)
at com.sun.tools.javac.comp.MemberEnter.importAll(MemberEnter.java:163)
at
com.sun.tools.javac.comp.MemberEnter.visitImport(MemberEnter.java:549)
at com.sun.tools.javac.tree.JCTree$JCImport.accept(JCTree.java:571)
at
com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:435)
at
com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:447)
at
com.sun.tools.javac.comp.MemberEnter.visitTopLevel(MemberEnter.java:526)
at
com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:518)
at
com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:435)
at com.sun.tools.javac.comp.MemberEnter.complete(MemberEnter.java:1038)
at com.sun.tools.javac.code.Symbol.complete(Symbol.java:560)
at
com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1024)
at com.sun.tools.javac.comp.Enter.complete(Enter.java:497)
at com.sun.tools.javac.comp.Enter.main(Enter.java:475)
at
com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:985)
at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:860)
at com.sun.tools.javac.main.Main.compile(Main.java:523)
at com.sun.tools.javac.main.Main.compile(Main.java:381)
at com.sun.tools.javac.main.Main.compile(Main.java:370)
at com.sun.tools.javac.main.Main.compile(Main.java:361)
at com.sun.tools.javac.Main.compile(Main.java:56)
at com.sun.tools.javac.Main.main(Main.java:42)
Wrapping/Java/CMakeFiles/VTKJavaClasses.dir/build.make:1952: recipe for
target
'java/javac_stamp.txt' failed
make[2]: Leaving directory '/builddir/build/BUILD/VTK-6.1.0/build'
CMakeFiles/Makefile2:22685: recipe for target
'Wrapping/Java/CMakeFiles/VTKJavaClasses.dir/all' failed
make[2]: *** [java/javac_stamp.txt] Error 3
make[1]: *** [Wrapping/Java/CMakeFiles/VTKJavaClasses.dir/all] Error 2
make: *** [all] Error 2
make[1]: Leaving directory '/builddir/build/BUILD/VTK-6.1.0/build'
Makefile:120: recipe for target 'all' failed
Version-Release number of selected component (if applicable):
How reproducible:
always
Steps to Reproduce:
1. build package on aarch64 (use "arm-koji build rawhide")
2. watch it fail
3.
Actual results:
package fails to build
Expected results:
package builds
Additional info:
Increasing Java heap size with "JAVA_TOOL_OPTIONS=-Xmx2048m make
%{?_smp_mflags}" helps. 2048m size was randomly selected.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug
https://bugzilla.redhat.com/token.cgi?t=dfeLMxOcug&a=cc_unsubscribe
8 years, 11 months
