GWT on 64-bit Linux
AethelJack
I'm in a 64-bit linux environment. I have a 32-bit JDK in use.
On run, I get:
** Unable to find a usable Mozilla install **
You may specify one in mozilla-hosted-browser.conf, see comments in
the file for details.
I've found little on the net beyond a mention of needing /lib64 in my
path. Having added that:
LD_LIBRARY_PATH="/opt/gwt/mozilla-1.7.12:/lib64"
... I still get the same error.
Thoughts? Solutions?
Cheers,
AethelJack
adam
Huh, I see a lot of results when I search:
http://groups.google.com/group/Google-Web-Toolkit/search?group=Google-Web-Toolkit&q=64-bit+linux&qt_g=Search+this+group
> Thoughts? Solutions?
You need to have a 32-bit version of Firefox installed, and in your
IDE you need to use a 32-bit JRE.
AethelJack
I wasn't searching in Google Groups, and clearly this was a mistake.
Thanks for the pointer, I've been reading.
> You need to have a 32-bit version of Firefox installed, and in your
> IDE you need to use a 32-bit JRE.
I do have a 32-bit JRE (jdk-6u2-linux-i586). I don't have a separate
32-bit version of Firefox installed. I (perhaps stupidly) assumed that
the
mozilla-1.7.12 directory inside the GWT was enough.
Perhaps I should back up one step and ask for some installation
advice. Let's assume I have a relatively fresh AMD64 Ubuntu 7.04
install. I have GWT and my JDKs in /opt (old habits). I'd like to use
Eclipse and GWT.
Ubuntu sources have Eclipse 3.2 - if you recommend a different version
(3.3?), where/how did you install it?
I'm running the x86_64 version of Firefox (with the nspluginwrapper
for 32-bit plugin compatibility). Do I need a separate 32-bit Firefox
install, or can I point to mozilla-1.7.12 in the GWT?
If this has become discussion more appropriate for email, then it's
fine to move there. If this groups needs a "how to get started with
GWT and Eclipse on amd64 Ubuntu" thread, then I'm happy to play along.
Cheers,
Jack
bwtaylor
has been a problem for a while and it appears to be stalled. x86_64
based systems are extremely common on developer's desktops now. It's
rather annoying to have to switch to the non-default JVM with GWT
work.
I note that the GWT build contains the binaries for a number of
libraries. I think part of the problem here is that this is not really
a good open source practice. I imagine somebody who wants 64 bit could
examine how the 32 bit builds are created and customize accordingly,
but with the 32 bit libraries close to being a black box, the itch
cannot be scratched easily.
The open source model should have lots to offer to the hosted mode
browser, which is a little spartan. I'd like to encourage the GWT team
to try to open this part of the project up more.
Dan Morrill
Hi, Bryan!
This keeps coming up, though I just realized the answer is kind of
hard to find. (I think the original explanation was in a bug report
that is apparently well-hidden, since I can't find it now.) So, sorry
about the apparent mystery, and here's the answer!
Simply put, the problem is much more than just a recompile of some
libraries; if it were that simple, there would have been a 64-bit
build long ago, because all of our desktops here are 64-bit as well.
The ultimate problem is that JNI and SWT conspire to force you to
either write 32-bit code, or 64-bit code. That is, you can assume a
pointer is either an int, or is a long -- but not interchangeably.
You can actually see this in the SWT code, where you'll see things
like "int /* long */ returnsAPointer(int /* long */ aPointer)".
(Switching from 32 to 64 bit involves uncommenting the longs and
commenting the ints.) This idiom gets pushed into the hosted mode
code that touches these libraries. Since Java has no preprocessor or
equivalent of #ifdef, there is no clean way to programmatically switch
between the 32-bit and 64-bit versions of the code.
This means that maintaining a 64-bit version of hosted mode implies
multiple copies of some hosted mode source files and changes to the
build, and thus means doubling the amount of work for some changes
made to hosted mode. (There are other issues, too, which I won't go
into for the sake of brevity.)
Altogether, it means this: a 64-bit build is a lot of work, simply to
support 64-bit hosted mode on a platform where the 32-bit build can
also be used with minimal, well-understood effort. A 64-bit build
also offers no particular benefits over 32-bit except reducing the
disk space footprint required by the multiple JVM installations.
Despite that, we still want and plan to support 64-bit anyway.
However we won't do so with the current hosted mode implementation. A
future version is planned to introduce an out-of-process hosted mode,
eliminating SWT from the picture and along with it most of the hurdles
to 64-bit hosted mode. The new model is planned to function as a Java
background process communicating with a browser plugin via system
IPC. This has a lot of other advantages than just a 64-bit hosted
mode, too.
Of course -- patches are always welcome. There's nothing particularly
"black box" about any of this, and I'm sure that John Tamplin (who
does a lot of the hosted mode work) would be happy to answer your
questions over on the GWT Contributors' forum. Unfortunately, a 64-bit
build (for the current hosted mode) would need a maintainer, rather
than just a one-time contribution, so it would be a bit of time sink
for you. Your time would probably be better spent helping out with
the new out-of-process model, so I'd like to gently steer you in that
direction. :)
As always -- for all the gory details, visit the Contributors' forum
(http://groups.google.com/group/Google-Web-Toolkit-Contributors)!
Best Regards,
- Dan
On Sep 11, 6:47 pm, bwtaylor <bryan.w.tay...@gmail.com> wrote:
> I don't understand what the reason for not supporting64-bits is. This
> has been a problem for a while and it appears to be stalled. x86_64
> based systems are extremely common on developer's desktops now. It's
> rather annoying to have to switch to the non-default JVM with GWT
> work.
>
> I note that the GWT build contains the binaries for a number of
> libraries. I think part of the problem here is that this is not really
> a good open source practice. I imagine somebody who wants64bitcould
> examine how the 32bitbuilds are created and customize accordingly,
> but with the 32bitlibraries close to being a black box, the itch
bwtaylor
difficulties and it makes more sense. Here's some thoughts/ideas:
Using a template engine or a scripting language is much more powerful
than preprocessing or #ifdef. Velocity, Freemarker, and Groovy all
could do this well. You just need to put an expression like $
{arch.pointerType} in the text wherever you want "int" or "long". When
the gen step of the build runs, sets up the template context and
outputs regular .java files which compile normally.
Regarding out of process hosted mode: this sounds like a good
approach. What I want from hosted mode is:
- Rapid development (minimize the edit-run loop)
- Java side tools (debugging, etc...)
- Browser side tools
- Transparency: make it easy for people with itches to add features to
any of the above
- "Just works" / Bullet proof installs
One thing I disagree with is the benefit of a 64 bit library set has
little to do with disk space savings. It's really more of a question
of managing my software environment and having bullet proof installs
and easing administration. It probably takes 10 minutes to hunt for,
download, install, and configure a second JVM, but since this part of
the first impression a new developer has with your product it's
pretty important.
Consider what happens to a 64-bit guy when he starts out with GWT:
1) I read the getting started guide and confirm that I "have a recent
version of the Java SDK installed"
2) I go to the GWT downloads page and am not told I must run on a 32
bit JVM
3) I run the applicationCreator and am not told I must run on a 32 bit
JVM when I write code or grab a demo
4) I run the nice script that applicationCreator made for me,
confident I'm on the happy-path
5) I get a nice Exception: in thread "main"
java.lang.UnsatisfiedLinkError: /local/opt/gwt-linux-1.4.60/libswt-pi-
gtk-3235.so error
6) I read carefully through the error and see the "wrong ELF class:
ELFCLASS32" which maybe I've seen before, maybe not
7) I start troubleshooting: recheck the instructions, google the
error, etc..., and eventually I figure out the problem
You have a good chance to lose folks interest at steps 5, 6, or 7.
Note it isn't obvious to somebody new to GWT that there even are
native libraries. Also, most 64-bit folks are not going to switch the
system default JVM to accommodate GWT. Which means that every single
script created by applicationCreator has to be hand edited.
One thing that I recommend is putting code in the application creator
that checks to make sure you are using 32 bit and if it not, asks you
for the location of the 32-bit JVM and sets JAVA_HOME to this within
the hosted mode launcher script. Even if it finds a 32 bit JVM, it
should put a prominent comment that you need 32-bit in there. Note
that this still sucks, because every time I upgrade my JVM I have to
do it twice AND I have to edit a multitude of hosted mode launcher
scripts.
AethelJack
> Thanks for shedding some light on this.
Thanks from this direction too.
> One thing I disagree with is the benefit of a 64 bit library set has
> little to do with disk space savings. It's really more of a question
> of managing my software environment and having bullet proof installs
> and easing administration. It probably takes 10 minutes to hunt for,
> download, install, and configure a second JVM, but since this part of
> the first impression a new developer has with your product it's
> pretty important.
>
> Consider what happens to a 64-bit guy when he starts out with GWT:
> 1) I read the getting started guide and confirm that I "have a recent
> version of the Java SDK installed"
> 2) I go to the GWT downloads page and am not told I must run on a 32
> bit JVM
> 3) I run the applicationCreator and am not told I must run on a 32 bit
> JVM when I write code or grab a demo
> 4) I run the nice script that applicationCreator made for me,
> confident I'm on the happy-path
> 5) I get a nice Exception: in thread "main"
> java.lang.UnsatisfiedLinkError: /local/opt/gwt-linux-1.4.60/libswt-pi-
> gtk-3235.so error
> 6) I read carefully through the error and see the "wrong ELF class:
> ELFCLASS32" which maybe I've seen before, maybe not
> 7) I start troubleshooting: recheck the instructions, google the
> error, etc..., and eventually I figure out the problem
Let me echo this as well.
Adding extra JVMs wasn't too big a hurdle, but I'm still not up
and running the way I'd like to be.
Cheers,
Jack