Avraham Rosenberg wrote:
> Hi,
> Still struggling with my new amd64 system and with its 32-bit
> chroot environement.
>
Here it works mostly fine. Sometimes it needs some tweaks, mainly
related to changing behaviour of the dchroot utility (between new
releases of the package).
> I installed it according to the HOWTO, and installed a couple of
> programs (most notably xv, opera and ImageJ).
>
To avoid trouble, I try to run everything in the pure 64 environment,
with minimal stuff on the 32bit chroot.
Can you give the specific reasons why you need these apps to be 32bit?
ImageJ: Can't it run on a 64bit Java (isn't Sun's Java available for 64
bit Linux?, can ImageJ run on gcc's gij)?
xv: AFAIK this comes with sources. Did not try compiling it myself but
I guess it should have no trouble compiling for 64bit. (I'm almost
certain I've used xv on a 64bit IRIX machine some years ago).
Opera: I don't know the browser, but I do use 32bit firefox (for the
proprietary binary plugins...). I guess similiar reasoning apply to Opera.
Other stuff I have on the 32bit chroot:
OpenOffice (I'm not sure of the reasons, but it seems that the 64bit
debian packages are not ready yet), and all of it's dependencies.
Acrobat Reader, printer driver for my old Lexmark, and mplayer (again,
for the proprietary win32 codecs).
> While xv seems to work flawlessly, opera is only partly
> functional and ImageJ accepts to work only if started from within
> the chroot.
>
What do you mean exactly:
a) What jvm you are using? (sun? gij? blackdown?)
(use "/usr/sbin/update-alternatives --list java" in the two environments)
b) Do you mean you have both 64bit jvm and a 32bit one, but only the
32bit installation is able to run the jar?
or
c) You want to run the 32bit java from the 64bit commandline (or
desktop launcher, etc.) using dchroot-based script.
In this case, then the most common scenario is that dchroot is
configured to only allow running binaries or only scripts (this changes
once in a while - seems like the package maintainers can't make up their
mind...)
* If it only allows binaries, you should give dchroot the java
executable as command, specifying the path to your class/jar as
commandline parameter (read the source of your launcher script to find
that info)
* If it only allows scripts, just create a launcher script yourself
(on the 32bit chroot /usr/local/bin) and give this script as the command
name for dchroot.
* Another possible source of trouble - bash quoting mess: you have
a launcher script containing the dchroot command on the 64bit side, plus
the "original" launcher script on the 32bit chroot, so launching the app
causes the parameters to be passed around through two shells plus the
dchroot command, which might cause havoc if you have special chars in
them (especially tricky to debug if these parameters are auto-generated
by cups. My lesson for today: never rely on proprietary 32bit printer
drivers :-( )
> I would be very grateful for any hint to explain what is the root
> of the difference in behaviour between the three.
> That may have to do with the fact that ImageJ is written in Java.
> (As I do not know a thing about java, I tend to accuse it of any
> misbehaviour of the system! Most probably that my next trouble
> will have a different cause...).
>
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
