Post by Joachim SchrodPost by Marc ChamberlinPost by Joachim SchrodAfterwards call
update-alternatives --config java
and select the 32bit Sun Java (that's the one in /usr/lib and not
in /usr/lib64).
Yes I ran this command. I remain amazed/disgusted at all the broken
links that remain for java related stuff in /etc/alternatives so suspect
the packagers are being awfully careless about keeping this directory
clean and free from potential problems...
"All the broken links"?
I have only javaws as a broken link.
Well, at my installation jre_1.6.0, jre_1.6.0_exports, jre_openjdk,
jre_openjdk_exports remain links to 64bit openjdk, as I kept that
for the sake of those openSUSE programs that want Java.
I would guesstimate that approx 30 links in /etc/alternatives were
broken, most pointing to non-existent things in /usr/lib64... I have
gone through and fixed most of them by hand (UGH!!!) and that has fixed
a lot of problems I have been experiencing... (Which in turn fixed a
lot of broken links elsewhere....)
To add salt to the wound, YaST did NOT remove the Java code/links from
the /usr/lib64/jvm directory with the
uninstall of the openJDK_x64 version of Java. That caused the script in
/etc/profile.d/alljava.sh to incorrectly set Java environment variables
to point at x64 things, which led to further problems.
Post by Joachim SchrodPost by Marc ChamberlinPost by Joachim SchrodIt works very good, very few problems up to now. A few 32bit
package versions of Java-related libraries are missing; we
recognized libtcnative (for Tomcat) and libsvnjavahl (for
Subversion). If you really need them, you have to compile them
yourself, or learn OBS usage, or learn to use /usr/lib/mkbaselibs.
I have both of these packages you mentioned, installed on my server as I
need both Tomcat and Subversion. But I checked in Yast and noted that
the x64 bit versions are installed and have no idea whether I need to
reinstall with the x32 bit versions?
There are no 32bit versions that one can install properly. (Such
packages would be named libtcnative-1-0-32bit etc.) Installing
libtcnative-1-0.i586 was a no-go since it would pull in 32bit
Apache via its dependency to libapr1.
As I wrote, you have to make these packages yourself. Installing
them forcefully breaks your system in a way that it would be better
to install 32bit-PAE from the start, IMHO.
At the moment, Tomcat seems to be running OK so I am going to leave it
alone and not install the x32 versions of these packages.. (Probably
setting myself up for hell later on...) As for re-installing openSuSE, I
will do so only if I am backed into a wall and have no other options.
Setting up things so far has been a huge investment of my time and will
make a few other people around here very unhappy campers if I re-install
openSuSE. Sure wish I had known this was going to be such a big mess
when I first installed openSuSE, but hindsight as you know.....
Post by Joachim SchrodPost by Marc ChamberlinHow far do I need to go in tracking
down what packages need to be switched to the x32 bit versions, now that
I have the x32 bit version of Java installed? Doesn't YaST (and the
packages dependencies check this for me, or is the packaging broken?)
I use zypper, not YaST, but the dependency checks should be the
same. So far, zypper recognized when a 32bit-version of some
mandatory library was missing and either installed the respective
package or complained about it, when it was missing.
I have more the other problem, that zypper sometimes wants to
install a 32bit library package and I have no idea at all what
pulls in that dependency.
An other issue, which resembles more your situation, is that
YaST/zypper do these installations only for mandatory dependencies.
Both libtcnative and libsvnjavahl are not mandatory; Tomcat and
SVN-Java work without them. So, if no fitting packages are found,
none are installed.
So, to answer your question: You have to hunt down all optional JNI
stuff or all JNI stuff that is used by software that you install
besides the openSUSE packaging system. You probably have to make
familiar yourself with creating local rpm packages or with OBS,
since some of the needed packages are definitively not there.
UGH!
Post by Joachim SchrodIf that is too complicated or too much work, make an openSUSE
32-bit installation; that's my best advice I can give.
UGH! UGH! And my understanding of PAE, makes me leery... I believe I
have tried it in the past, and ran into other difficulties, so gave up
on it, and have not revisited it since...
Post by Joachim SchrodPost by Marc ChamberlinPost by Joachim Schrodmozilla-xulrunner20.i586
mozilla-xulrunner20-gnome.i586
Yes, I had the x64 version of these installed also.. So decided to be
pre-emptive and switch them over to the i586 (x32) versions also. Again,
I have no idea how much I am going to have to chase down, in the
packages, to switch over to an x32 bit version...
This is a case where you installed software (Eclipse) besides the
openSUSE packaging software. How shall YaST know that Eclipse needs
the Mozilla runtime in i586 architecture, to be loaded by JNI, when
it doesn't know about the Eclipse installation at all? Here you are
responsible to chase down the dependencies yourself.
I understand/agree. But I still feel that openSuSE (or perhaps Linux in
general) should have better support/processes in place, in case the user
decides to switch from one Java version to another. It use to be the
case that one could even have multiple VMs installed at the same time,
but it looks like it is going to become a real PITA to rely on and
support such now. (And YaST certainly does not encourage/allow it
because of the way they are using a toggle switch to choose only one
version.)
I am not fond of having to learn a whole new installation procedure,
especially a command line tool such as Zypper with all the &*$%! options
one has to memorize, when a GUI based tool is lying around that can
simply guide me to a solution. But I suppose I had better learn to use
the damn thing....
Post by Joachim SchrodPost by Marc ChamberlinThis in part is why I
originally asked the question - Is changing from an x64 version of a
java vm to an x32 version supported in openSuSE?
I would say that it is not is supported in openSUSE in the sense
that it's certainly not a use case that any developper tested. (In
a was, nothing is "supported"; this is a community distribution.)
It's available for those who are willing to spend some time with
their system setup, but they should preferebly be familiar with
system setup and packaging beyond usage of YaST.
If ONLY I had 64 hours in a day, lots of time and energy to become a
guru in understanding how to use all the various tools that come with
openSuSE! But no, in this real world, I have to be able to move quickly
in finding solutions and must rely on other experts to deliver a usable
system. This is a case where I feel openSuSE has let me down, and I have
no qualms about letting the community know how and why.... My usage of
the word "supported" is just that.... And my contribution towards
openSuSE is to take the time to tell the community when, what, where and
how a particular component, design etc., has failed me...
Post by Joachim SchrodPost by Marc ChamberlinOr do I need to scrap
the installation entirely and see if I can re-install openSuSE for an
x32 architecture. This would be a REAL PITA!!! (I dunno/remember if the
installation even allowed me the choice, so much of this sort of
decision making has been automated these days.. Sigh... )
It is possible to install x32 on 64bit hardware. On the
installation screen, there is some F? key where you can change the
architecture.
Post by Marc Chamberlin(As an aside, I am apparently having troubles now with our Apache James
email server handling crypto communications with email clients. I kinda
suspect it may be related also to having an x64 version of some java
package installed, which should be an x32 bit version... SO will have to
try and track that one down also...)
crypto is also not mandatory, IIRC. You'll probably need to install
one or several of the x86_64 openssl packages whose names end with
-32bit.
Fixing the links in /etc/alternatives seems to have made James a happy
camper again....
Thanks again for your time and thoughts Joachim.... Marc..
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org