[SOLVED] Java problem (I think) with libreoffice on slackware-current
Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
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.
Java problem (I think) with libreoffice on slackware-current
I am slowly moving from Slackware-14 to Slackware-current (aka Slackware-15-rc2). Yesterday I installed libreoffice-7.2.2 (from the alien repo) and Oracle jdk (repackaged as per the Slackware Howto). But it aborts while trying to put up the splash screen.
This gets weirder. The jdk tarball that I downloaded from oracle is called jdk-17_linux-x64_bin.tar.gz. So it should be 64-bit, right? But evidently it isn't because I just checked the product of the slackbuild and it's actually a 32-bit (jdk-17_linux-i586-1.txz). Well, that explains why it doesn't work. I should have checked the name more carefully before installing it. But then where do I get the correct java from??
And weirder...I checked some of the actual installed libraries in /usr/lib/java/lib and got
Code:
$ file libjava.so
libjava.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped
hazel@bigboy.localdomain:/usr/lib/java/lib
$ file libjawt.so
libjawt.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped
There's a doc called "Oracle JDK 17 Certified System Configurations" where it says only x64 versions are supported.
It seems unlikely that jdk-17_linux-i586-1.txz is something they would distribute, maybe your source repository is out of date.
There's a doc called "Oracle JDK 17 Certified System Configurations" where it says only x64 versions are supported.
It seems unlikely that jdk-17_linux-i586-1.txz is something they would distribute, maybe your source repository is out of date.
No, it's a script problem. I checked how the slackbuild script identifies the architecture and it turns out that it doesn't match the mix of hyphens and underlines that oracle uses in its package names. It expects hyphens only. And i586 is simply the default architecture for use in the final package name if x86_64 wasn't detected.
Code:
JAVA_ARCH=$(basename $SOURCETGZ | cut -f 4 -d - | cut -f 1 -d .)
if [ "$JAVA_ARCH" = "x64" ]; then
LIB_ARCH=amd64
ARCH=x86_64
LIBDIRSUFFIX="64"
else
LIB_ARCH=i386
ARCH=i586
LIBDIRSUFFIX=""
fi
So it is the correct architecture, once installed. It just has a silly name. So why isn't it working?
No, it's a script problem. I checked how the slackbuild script identifies the architecture and it turns out that it doesn't match the mix of hyphens and underlines that oracle uses in its package names. It expects hyphens only. And i586 is simply the default architecture for use in the final package name if x86_64 wasn't detected.
Should be reported to maintaner, but SBo seems frozen at rc time so there might be a long delay.
There's possibly a working script somewhere in ponce repository, but I don't use JDK so I did not check.
In the meantime, something like this could set the architecture, though I'm not sure if the variables are correct here;
There are some features that require Java, chiefly Base and a few wizards. To compile without Java, use the flag --without-java (how else?) For the details, see https://wiki.documentfoundation.org/Development/Java
LibreOffice can be built without Java. It does not appear to be missing any essential functionality.
Yep, it's required for Base (the database application), and it allows the use of Java-based plugins, but for the vast majority of people it's not necessary.
(No idea whether it would be enough to uninstall Oracle JDK or if LibreOffice needs re-building with a specific flag.)
Following advice in another thread, I removed jdk and installed the alien version of openjre instead. I hoped that as my libreoffice comes from the same repo, I'd get better results. But it still crashes. I've got a working LO on Slackware 14, so for the time being I can go on using that..
Did you make a 64bit package? If you have 64bit libs in 32bit package, installpkg will install 64bit libs in /usr/lib and that is why I assume it does not work.
Do you have multilib? It would be only reason to even have anything in /usr/lib.
Do you have multilib? It would be only reason to even have anything in /usr/lib.
Not yet. I shall need a 32-bit glibc for my printer eventually but I don't aim to install that until after the release date. Oddly enough, the slackbuild that I got from Slackware64-current/extras/java did name the package -i586- but the java libraries that I checked with the file command were definitely 64-bit. I assume the script was confused by the rather weird way that Oracle name their packages, using a mixture of "-" and "_" separators.
Anyway, I've removed all that and replaced it with Eric's openjre 64-bit package and LO still crashes.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
