SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
cp -a $PKG1/usr/lib${LIBDIRSUFFIX}/java/jre/lib/fontconfig.{Ubuntu,}.properties.src
This line create the file /usr/lib/java/jre/lib/fontconfig..properties.src
Is this correct or is a bug?
notice: the fontconfig.properties.src (with one only dot) already exists.
Some other notices:
I'm building in bootstrap mode, using gcc-java. In this mod gcc give me an error linking a library.
I correct this adding before "make" row:
Code:
sed -i -e 's/-o native-ecj/-lgcj -o native-ecj/' Makefile
Compiling on -current also there is not the "keytool" tools, so:
Code:
# Generate a cacerts file from the certificates installed through our
# ca-certificates package - the "cacerts" in the OpenJDK sources is empty.
# This will only work if we already have a proper JDK/JRE installed:
if which keytool 1>/dev/null 2>&1 ; then
...
else
echo "** Not installing a proper cacerts file !"
echo "** Missing keytool program (do you really have a Java installed?)"
fi
# Symlinks are present in Slackware historically:
( cd $PKG2/usr/lib${LIBDIRSUFFIX}/java
ln -sf jre jre${VERSION}
) || exit 1
should be
Code:
# Symlinks are present in Slackware historically:
( cd $PKG2/usr/lib${LIBDIRSUFFIX}
ln -sf java jre${VERSION}
) || exit 1
as the slackware 13.37 jre6:
lrwxrwxrwx 1 root root 4 Apr 20 20:51 /usr/lib/jre1.6.0_27 -> java/
Not a bug. Do not compare the old Slackware package using Oracle binaries and my OpenJDK. I did this for a reason. There are some wrapper scripts that expect these directories. I did this on purpose.
cp -a $PKG1/usr/lib${LIBDIRSUFFIX}/java/jre/lib/fontconfig.{Ubuntu,}.properties.src
This line create the file /usr/lib/java/jre/lib/fontconfig..properties.src
Is this correct or is a bug?
notice: the fontconfig.properties.src (with one only dot) already exists.
Yes, that is a bug. There is a dot too many, I wanted to let the Ubuntu properties file overwrite the default one.
Quote:
Some other notices:
I'm building in bootstrap mode, using gcc-java. In this mod gcc give me an error linking a library.
I correct this adding before "make" row:
Code:
sed -i -e 's/-o native-ecj/-lgcj -o native-ecj/' Makefile
Never noticed this on Slackware 13.37 which was where I built the bootstrap version. I can add this to the SlackBuild if that helps people bootstrapping on Slackware-current. Now that there is a "final" version of OpenJDK there should not be a need for a bootstrap. I will see what happens when I bootstrap OpenJDK on ARM again sometime later.
Quote:
Compiling on -current also there is not the "keytool" tools, so:
Code:
# Generate a cacerts file from the certificates installed through our
# ca-certificates package - the "cacerts" in the OpenJDK sources is empty.
# This will only work if we already have a proper JDK/JRE installed:
if which keytool 1>/dev/null 2>&1 ; then
...
else
echo "** Not installing a proper cacerts file !"
echo "** Missing keytool program (do you really have a Java installed?)"
fi
For the bootstrap package, you do not need the cacerts file, so I did not bother with this. You don't want to run the bootstrap package on a daily basis. You should use the OpenJDK which is compiled against itself, because that is the only version which allows you to use icedtea-web. Once you have a proper OpenJDK package, you also have keytool.
Do not compare the old Slackware package using Oracle binaries and my OpenJDK
I compare it becouse:
Code:
# Symlinks are present in Slackware historically:
Sound strange that a program expect the JRE in $JAVA_HOME/jre$VERSION/bin/java
Quote:
Never noticed this on Slackware 13.37 which was where I built the bootstrap version.
Slackware 13.37 does not use gcc 4.7
This is a common problem for many software (and for many software are needed patch for gcc4.7). Now gcc require to explicitly specify some library to link.
Quote:
Now that there is a "final" version of OpenJDK
who install slackware-current have no a jdk/openjdk installed.
Quote:
For the bootstrap package, you do not need the cacerts file, so I did not bother with this. You don't want to run the bootstrap package on a daily basis. You should use the OpenJDK which is compiled against itself, because that is the only version which allows you to use icedtea-web. Once you have a proper OpenJDK package, you also have keytool.
After build openjdk with bootstrap I MUST to rebuild it with the newer openjdk?
I see that, when I start in bootstrap mode, that icedtee create openjdk.build-boot containing the openjdk compiled with gcc-java and then the openjdk.build compiled with the bootstrapped openjdk.
Sound strange that a program expect the JRE in $JAVA_HOME/jre$VERSION/bin/java
You are interpreting that comment incorrectly. Slackware has versioned symlinks historically. But the location is not dictated by history. I only added a versioned symlink.
Quote:
Slackware 13.37 does not use gcc 4.7
This is a common problem for many software (and for many software are needed patch for gcc4.7). Now gcc require to explicitly specify some library to link.
Yes. And the "sed" fix was mentioned in a comment by David Spencer on my blog post for the Update5: http://alien.slackbook.org/blog/upda...k-7-available/ . It will be present in the openjdk.SlackBuild when I compile the next JDK release.
Quote:
who install slackware-current have no a jdk/openjdk installed.
Yes, but you do not have to build this from source. Why do you think I provide a package already? If you want to bootstrap the build you have to respect the fact that that is not meant to be used in production.
Quote:
After build openjdk with bootstrap I MUST to rebuild it with the newer openjdk?
I see that, when I start in bootstrap mode, that icedtee create openjdk.build-boot containing the openjdk compiled with gcc-java and then the openjdk.build compiled with the bootstrapped openjdk.
Which are the differences with a version compiled without bootstrap?
For now I'd not compiled icedtea-web, so I can't verify
A bootstrap build uses the java compiler of the GCC suite, which does not implement the full Java API as does the Oracle java compiler. Once you have the bootstrap build, you can rebuild OpenJDK and know that all the tools you need are installed. That is all I want to do. I have no real interest to keep building bootstrap packages. Once I had one JDK7 package, the bootstrap build was no longer needed. That will change once again, when OpenJDK moves to version 8 - OpenJDK can only be built using an existing OpenJDK of the same version, or else you have to do a bootstrap build.
I will see what happens when I bootstrap OpenJDK on ARM again sometime later.
I've tried but failed to do a bootstrap build on ARM because gcj needs so much memory. So I stole the Debian binaries and used them for a non-bootstrap build. This actually builds ok on x86_64! But on ARM it dies when something or other can't find JVM_SetNativeThreadName. Upstream is working on this, see http://blog.fuseyism.com/index.php/2...-zero-sort-of/, where your work has been noticed I tried to build with this fix from the Mercurial repo but got another build error when cacao rejected the -client control arg. Any further progress will probably be slow and painful.
TL;DR: if you value your time and sanity wait for icedtea 2.3 before you try it.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.