I'm having trouble similar to Unable to build pdftk from source on fedora machine, but I'm having it on Ubuntu 13.04.
I've install gcc-gcj, which provides gcj-4.8.
I opened Makefile.Debian, and modified it as follows. So it finds the proper version of some of the GCC build tools:
export VERSUFF ?=-4.6
Next, I tried to make:
$ VERSUFF="-4.8"; make -f Makefile.Debian
make -f Makefile -iC /home/jwalton/pdftk-2.02-dist/pdftk/../java all
...
make[1]: Entering directory `/home/jwalton/pdftk-2.02-dist/java'
gcjh-4.8 -force --classpath="/usr/share/java/libgcj-4.8.jar:/home/jwalton/pdftk-2.02-dist/java:."
pdftk/com/lowagie/text/Anchor
/bin/sh: 1: gcjh-4.8: not found
...
gcjh-4.8 -force --classpath="/usr/share/java/libgcj-4.8.jar:/home/jwalton/pdftk-2.02-dist/java:."
pdftk/org/bouncycastle/crypto/engines/AESFastEngine
/bin/sh: 1: gcjh-4.8: not found
Though I have installed gcc-gcj, it appears I don't have gcjh:
$ find /usr/bin -name gcjh
$ find /usr/local/bin -name gcjh
$
There is no gcc-java or gcc-gcjh packages:
$ apt-cache pkgnames | grep -i gcc-java
$ apt-cache pkgnames | grep -i gcc-gcjh
$ apt-cache pkgnames | grep -i gcjh
$
What is gcjh, and where can I find it for Ubuntu 13?
For anyone in recent years trying to compile pdftk or otherwise looking for gcj
The pdftk package relied on gcj, which is the GCC compiler for Java. GCJ was officially removed from GCC in September 2016, and by extension, discontinued by the package repositories themselves for the various distros. As a result of this, many notable systems have officially dropped the no-longer-buildable pdftk package itself from their repositories, including Fedora, Ubuntu and Cygwin.
I gave up attempting to build pdftk for my own Cygwin system because of the gcj dependency and because I couldn't trust a tool from developers who insist on using dependencies that have been deprecated for 4 years now. An email exchange here from 2014 - two years before GCJ was finally dropped by GCC - cites the developer of pdftk as saying:
Yes, I've heard that they're dropping support for libgcj. We have been
working on a new pdftk that doesn't depend on libgcj, but it is
currently pre-beta.
However, it seem nothing came from this "pre-beta", since the last time pdftk had an update at all was in 2013.
I personally had two options available to me: to install the Windows binary of the pdftk, which would result in an installation separate to the rest of my Cygwin environment, or to use a different but similar tool such as qpdf. Given what I now knew of the last time that pdftk had been updated, I opted to use qpdf and so far haven't been disappointed. The one criticism I have of qpdf is that the website and documentation looks a lot less prettier compared to pdftks, but the tool itself appears to have all of the same functionality as pdftk.
qpdf is also available and actively maintained on most other major Unix-like systems, including Ubuntu and Fedora.
For anyone who's still desperate to compile pdftk for a Linux distribution, for either workflow or legacy reasons, the above-linked Github thread has some instructions that seem like they still work for a few people.
Use http://packages.ubuntu.com/ to search, and I get http://packages.ubuntu.com/search?searchon=contents&keywords=gcjh&mode=exactfilename&suite=saucy&arch=any suggesting that the answer is gcj-jdk.
Related
I have several .jar files that run successfully when opened with Mac's built in 'Jar Launcher' (Version 15.0.1) but when ran from terminal they error out.
Looking online the error messages might be down to the incorrect version of Java being linked to the terminal version, so I'd like to check if the options set for 'Jar Launcher' and the Java used within terminal are the same.
Does there exist any way to do this?
This question is two years old, but as there is no answer to it, I thought I'd put my two cents here since I've had issues myself, and have made some observations.
It seems that the Jar Launcher doesn't necessarily use the same JVM version as the one shown by the command /usr/libexec/java_home: If there is a JRE /Library/Internet Plug-Ins/JavaAppletPlugin.plugin, then the Jar Launcher will use it and ignore anything in /Library/Java/JavaVirtualMachines.
I've solve my problem of version mismatch between the Jar Launcher and the terminal by removing the JRE:
Go to /Library/Internet Plug-Ins.
Remove the JavaAppletPlugin.plugin directory by executing the rm command as a root user or by using the sudo tool.
Go to /Library/PreferencePanes.
Remove JavaControlPanel.prefpane by executing the rm command as a root user or by using the sudo tool.
Source: https://docs.oracle.com/javase/9/install/installation-jdk-and-jre-macos.htm
I'm trying to build AOSP from source (With a few modifications) but my build stops with
[ 0% 1/35196] JarJar: out/target/common/obj/JAVA_LIBRARIES/conscrypt_intermediates/classes-jarjar.jar
FAILED: /bin/bash -c "java -jar out/host/linux-x86/framework/jarjar.jar process external/conscrypt/jarjar-rules.txt out/target/common/obj/JAVA_LIBRARIES/conscrypt_intermediates/classes-full-debug.jar out/target/common/obj/JAVA_LIBRARIES/conscrypt_intermediates/classes-jarjar.jar"
Error: Could not find or load main class com.tonicsystems.jarjar.Main
ninja: build stopped: subcommand failed.
make: *** [build/core/ninja.mk:149: ninja_wrapper] Error 1
and i can't get to fix it. My source is hosted here and the path of external/jarjar is the stock one on googlesource.
Can anyone help?
I had the same problem until I realized that it's due to the wrong path where com.tonicsystems.jarjar.Main is located. At ~/android/system, JarJar's com.tonicsystems.jarjar class is located in:
external/jarjar/src/main/com/tonicsystems
When it should be
external/jarjar/src/main/java/com/tonicsystems
Like it's source (from GitHub)
src/main/java/com/tonicsystems/jarjar
P.S: I had to create the external/jarjar/src/main/java directory and then move the source.
I've run into this with an AOSP fork (I think Qualcomm's tree) before - that was caused by the Makefile fragments that generate the file lists for the jar files not dealing properly with localized versions of the "sort" utility (causing removal of important class files in addition to the duplicates that were supposed to be removed).
I don't remember all the details or the proper fix, but the workaround that got me going initially was simply disabling localization while building.
rm -rf out
export LANG=C
export LC_ALL=C
export LC_COLLATE=C
. build/envsetup.sh
lunch whatever
make droidcore -j8
What fixed this for me was something completely unrelated to jarjar itself.
I was building AOSP 7.1.1 on Ubuntu 20.04. The default python command on Ubuntu 20.04 points to python3 [1], but AOSP 7.1.1 builds using python (which is really python 2.7.5).
I updated my system with sudo apt install python which linked the python command to python2 correctly instead of python3. After this, I built successfully.
AOSP is shipped with python under the prebuilts/python directory and I'm still confused as to why the build system doesn't point to that python version.
Edit
I had more trouble with adjusting my system to use the correct version of python, ultimately I had to add python and python3 as alternatives.
$ sudo update-alternatives --install /usr/bin/python python /usr/bin/python2 1
$ sudo update-alternatives --install /usr/bin/python python /usr/bin/python3 2
$ sudo update-alternatives --config python
Select python2
javapackager and javafxpackager don't seem to be recognised on the command line for me. They don't show up in the terminal, even after I installed the latest 1.8 SDK. (Even 'echo $JAVA_HOME' seems to be drawing a blank, though java -version seems to work fine.)
If I look under /Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/bin/ I can see the javapackager and javafxpackager tools are present, but if I follow /usr/libexec/java_home back to it's origin in /System/Library/Frameworks/JavaVM.framework/Versions/A/Commands/ , there's no sign of them.
The only other discussions I could find on the subject were a blog post and mailing list from about a year and a half back:
https://devreboot.wordpress.com/2014/11/26/java-desktop-app-packaging-automation/
http://lists.apple.com/archives/java-dev/2015/Nov/msg00009.html
I realise OSX hasn't come with java 'by default' for some time, but that's kinda why I was hoping to release my application as a self-contained bundle with it's own VM. Would it be standard procedure to update my bash profile to point at the tool explicitly? Is there something screwy about my personal setup, or is there some gap in the tool support on OSX?
PS: I realise there's an older thread on this subject below:
What is the best way to deploy JavaFX application, create JAR and self-contained applications and native installers
However, that describes javapackager as a .jar file, and whatever I've got doesn't seem to be a .jar file. I'm legitimately confused about what I'm supposed to do with it.
EDIT: Thanks to everyone for the tips- I think I have enough info to go on for now.
You could try this gist for building, packaging and running a test install on Java client apps from the OS X command line. No guarantees it will work for you, it was just something I whipped up for personal development purposes a long time ago. But, the info in there may help in resolving packager tool locations from the command line and also in performing other packaging related functions.
The key part for locating (and using) the javapackager is:
# select java version
export JAVA_HOME=`/usr/libexec/java_home -v 1.8`
$JAVA_HOME/bin/java -version
...
# make an executable jar file
$JAVA_HOME/bin/javapackager -createjar -srcdir . -appclass start.HelloWorldSwing -srcfiles HelloWorldSwing.jar -outdir . -outfile HelloWorld.jar
# package the jar and java runtime as a native application with installer
$JAVA_HOME/bin/javapackager -deploy -srcdir . -srcfiles HelloWorld.jar -outdir . -outfile HelloWorld -appclass start.HelloWorldSwing -native -name HelloWorld
Note, the above is for packaging a Swing application. Packaging a JavaFX application will use slightly different command line options for the packager.
Doing things this way from command line scripts is decidedly old school, usually maven or gradle is used.
My personal preference would be to just use Ant, but I guess that's only slightly less old-school?
Yes, not that there is anything wrong with that. Documentation on using Ant to package java client applications is provided by Oracle.
I need java 1.7 and server has only got 1.6. I have no root privileges. I tried to google out something but it seems like nobody was doing it. Can I somehow compile it or get ready binaries so I could put those into my PATH. Could you help? System is Redhat.
It is quite easy...
Download the JDK as a tarball from Oracle (a simple google search will yield the link).
Unzip it somewhere in your $HOME (for instance, $HOME/jdk).
Set JAVA_HOME to the path of the root JDK install; then prepend $JAVA_HOME/bin to your PATH.
And off you go.
Here I have a particular setting insofar as I run three different major versions of the JDK: 6, 7, 8. For instance, here is my source file for setting the current shell to use Java 8:
$ cat ~/.jdk/8
export JAVA_HOME=/opt/sunjdk/1.8/current
export PATH="$JAVA_HOME/bin:$PATH"
And in /opt/sunjdk/1.8 (given that /opt/sunjdk is writable by my user hence I don't need to be root):
$ ls -l /opt/sunjdk/1.8/* -d
lrwxrwxrwx 1 fge fge 11 Oct 30 10:09 /opt/sunjdk/1.8/current -> jdk1.8.0_25
drwxr-xr-x 1 fge fge 274 Mar 18 2014 /opt/sunjdk/1.8/jdk1.8.0_05
drwxr-xr-x 1 fge fge 274 Sep 18 02:44 /opt/sunjdk/1.8/jdk1.8.0_25
(and yes, I was root to begin with so as to grant write permissions for /opt/sunjdk to "my" user; if you have no such liberty, just create another directory in your home)
Oracle offers JRE and JDK also as *.tar.gz for Linux. I usually had success just downloading such a package, untarring/unzipping it (tar -xzvf jdk-8u25.tar.gz) and then running it, using the absolute path.
I was able to accomplish this using conda.
Conda is an open-source package-manager by Anaconda, that according to the website:
You do not need administrative or root permissions to install Anaconda if you select a user-writable install location.
You can search the package repo from a browser at anaconda.org or command line, for example here are the results for JDK.
For Linux, you would download this installer. Here is a command line that will start the installer for convenience:
wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh && bash Miniconda3-latest-Linux-x86_64.sh
Once conda is installed, you can install packages. For example, to install the JetBrains Runtime OpenJDK build:
conda install -c anaconda openjdk
Other builds may be available from other channels in the repository.
The instructions above should give a working install, but the Getting started guide is a good place to get started. Conda uses the concept of environments to help manage versions and paths in a fairly simple and straightforward manner.
I hope this helps someone.
export JAVA_HOME=/opt/sunjdk/1.8/current
export PATH="$JAVA_HOME/bin:$PATH"
For me this option only worked when I changed linux to use bash instead ksh. I don't know if this is some kind of configuration in my company, but when I tried to run via ksh using "set" command instead "export" to define path, It was set correctly with the path of my new Java installation, but when I typed which java the old version was showed. But, when I executed bash, and typed the "export", it worked. So, if someone have the same problem to configure it using set command, try to use bash with export command. I am using Redhat 6.2.
I try to use the sun grid engine with the DRMAA api by following the tutorial found at: http://gridscheduler.sourceforge.net/howto/drmaa_java.html. For this I need to load the c library located in /srv/sge/lib/lx24-amd64/drmaa.so. Now I execute my command with this code: java -jar scriptName.jar -Dshared.library.path=/srv/sge/lib/lx24-amd64/ as described in https://blogs.oracle.com/templedf/entry/drmaa_and_the_shared_library. But still I get the this exception:
Exception in thread "main" java.lang.UnsatisfiedLinkError: no drmaa in
java.library.path
This exception is thrown when trying to retrieve the session:
session = SessionFactory.getFactory().getSession();
OS is linux 64 bit, java is 64 bit and SGE is 64 bit, so this is all compatible.
Does anyone know what is going wrong?
You will want to change shared.library.path to java.library.path (I believe that is a mistake in the blog post you referenced.
Also, place the -D switch before the -jar switch in your command, otherwise it is interpreted as an argument to the main function in the jar file rather than an argument to the JVM.
So, your example command should now look like this:
java -Djava.library.path=/srv/sge/lib/lx24-amd64/ -jar scriptName.jar
The case seems to be that in some distributions the libdrmaa.so has a library version number libdrmaa.so.1.0 while the libdrmaa.so without version number is missing. The drmaa.jar seems to just look for the one without. You can check which of the libdrmaa.so libraries are available in your system using
# ldconfig -p | grep libdrmaa
Which (in my case) either says
libdrmaa.so.1.0 (libc6,x86-64) => /lib64/libdrmaa.so.1.0
or
libdrmaa.so.1.0 (libc6,x86-64) => /lib64/libdrmaa.so.1.0
libdrmaa.so (libc6,x86-64) => /lib64/libdrmaa.so
The second case is the good one!
For Fedora distributions I reported this as a bug and it seems that they fix it in F18 and F19 soon. https://bugzilla.redhat.com/show_bug.cgi?id=671880
It is an easy fix in Fedora to simply install the package "gridengine-devel" where this soft-link is included.
If the libdrmaa.so without version number is not there and you are on another distribution, you can fix it manually as system administrator by typing
# cd /usr/lib64
# sudo ln -sf libdrmaa.so.1.0 libdrmaa.so
# sudo ldconfig
None of the previous answers worked for me. I've managed to solve this problem defining in my environment the following variable
export LD_LIBRARY_PATH=<path to the drmaa lib>