Re: 64 bit Linux support

[John Yodsnukis]

Here's a patch that allowed me to compile from svn source under 64 bit Linux.

Index: gears/tools/config.mk
===================================================================
--- gears/tools/config.mk (revision 142)
+++ gears/tools/config.mk (working copy)
@@ -40,11 +40,13 @@
# OSX builds will override this.
# Other platforms just need a value defined.
ARCH = i386
+ARCH = x86_64

# Set default build mode
# dbg = debug build
# opt = release build
MODE = dbg
+MODE = opt

# $(shell ...) statements need to be different on Win32 (%% vs %).
@@ -95,6 +97,7 @@
COMPILE_FLAGS_dbg = -g -O0
COMPILE_FLAGS_opt = -O2
COMPILE_FLAGS = -c -o $@ -fPIC -Wall -Werror $(COMPILE_FLAGS_$(MODE))
+COMPILE_FLAGS = -c -o $@ -fPIC -Wall $(COMPILE_FLAGS_$(MODE))

# NS_LITERAL_STRING does not work properly without this compiler option
COMPILE_FLAGS += -fshort-wchar
Index: gears/localserver/firefox/async_task_ff.cc
===================================================================
--- gears/localserver/firefox/async_task_ff.cc (revision 142)
+++ gears/localserver/firefox/async_task_ff.cc (working copy)
@@ -441,7 +441,8 @@
Abort();
break;
default:
- OnListenerEvent(msg_code, reinterpret_cast<int>(msg_param));
+// OnListenerEvent(msg_code, reinterpret_cast<int>(msg_param));
+ OnListenerEvent(msg_code, reinterpret_cast<long>(msg_param));
break;
}
}
Index: gears/third_party/gecko_sdk/1.8/linux/lib/libxpcomglue_s.a
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: gears/third_party/gecko_sdk/1.8/linux/lib/libnspr4.so
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: gears/third_party/gecko_sdk/1.8/linux/lib/libxpcom.so
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: gears/third_party/gecko_sdk/1.8/linux/bin/xpidl
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: gears/third_party/gecko_sdk/1.8/linux/bin/xpt_dump
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: gears/third_party/gecko_sdk/1.8/linux/bin/regxpcom
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: gears/third_party/gecko_sdk/1.8/linux/bin/xpt_link
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream

[Chris Prince]

Very cool, John. So if I'm reading this right, "x86_64" was the key
change to the source code? The other changes seem to be related to
typecast warnings -- is that right?

Did the binaries also change, or just a flag on the binaries? I can't
tell from the diff.

[JohnY]

The COMPILE_FLAGS and the "reinterpret_cast<long>" were both show
stoppers for me at compile time.

I needed to copy the 64bit binaries from a manual firefox build to
replace the 32bit ones in CVS.

So far it's working fine with Google Reader.

On Jul 16, 7:25 pm, "Chris Prince" <cpri...@google.com> wrote:
> Very cool, John. So if I'm reading this right, "x86_64" was the key
> change to the source code? The other changes seem to be related to
> typecast warnings -- is that right?
>
> Did the binaries also change, or just a flag on the binaries? I can't
> tell from the diff.
>

[John Yodsnukis]

On Dec 25, 2007 9:37 PM, sathiya <getsa...@gmail.com> wrote:
> I have modified all three files.
> But when compile the code, i received the following errors,
> /usr/bin/ld: skipping incompatible third_party/gecko_1.8/linux/
> gecko_sdk/lib/libxpcom.so when searching for -lxpcom
> /usr/bin/ld: cannot find -lxpcom
> collect2: ld returned 1 exit status
> make[1]: *** [bin-opt/linux-x86_64/ff/libgears.so] Error 1
> make: *** [default] Error 2
>

<snip>

You must replace the below files with 64bit versions. You can
probably find them in /usr/lib/...
or in the 64 bit gecko sdk.

[sathiya]

Thank you replying .
I have replace the following files under lib,
libplc4.so libxpcom.so
libnspr4.so libplds4.so

but now i received different error,
/usr/bin/ld: skipping incompatible third_party/gecko_1.8/linux/
gecko_sdk/lib/libxpcomglue_s.a when searching for -lxpcomglue_s
/usr/bin/ld: cannot find -lxpcomglue_s

collect2: ld returned 1 exit status
make[1]: *** [bin-opt/linux-x86_64/ff/libgears.so] Error 1
make: *** [default] Error 2

On Dec 27, 12:14 am, "John Yodsnukis" <john.yodsnu...@gmail.com>
wrote:

[JohnY]

On Dec 26, 9:04 pm, sathiya <getsath...@gmail.com> wrote:
> Thank you replying .
> I have replace the following files under lib,
> libplc4.so libxpcom.so
> libnspr4.so libplds4.so
>

No, you must replace them in the gears build/source tree. And you
don't have all the right files.

You need these 7 files replaced with 64 bit gecko sdk versions:

gears/third_party/gecko_sdk/1.8/linux/lib/libxpcomglue_s.a
gears/third_party/gecko_sdk/1.8/linux/lib/libnspr4.so
gears/third_party/gecko_sdk/1.8/linux/lib/libxpcom.so
gears/third_party/gecko_sdk/1.8/linux/bin/xpidl
gears/third_party/gecko_sdk/1.8/linux/bin/xpt_dump
gears/third_party/gecko_sdk/1.8/linux/bin/regxpcom
gears/third_party/gecko_sdk/1.8/linux/bin/xpt_link

[sathiya]

i donot have those files in my system, could you tell where can i
download ?

[JohnY]

Check your distributions packages. On mine they are in the firefox-
dev package.

[Scott Wolchok]

Here is a better (IMO) patch.

Pros:
* Cross-platform approach to 64-bit maintainability.
* No penalty on 32-bit architectures.
* Enables an easy convention going forward: use ptrasint_t as an
integral type that can hold a pointer.

Cons:
* Introduces a build dependency on Boost. Developers must either
install Boost headers, or we must "deboostify" boost/integer.hpp as
was done with scoped_ptr.
* Patch does not fix base/firefox/install.rdf.m4 to output
Linux_x86_64-gcc3 as the target platform (I don't know m4)

The following patch links against Debian's libxpcomglue.so because
libxpcomglue_s does not seem to be available in Debian testing
(lenny). I simply installed libxul-dev instead of building firefox by
hand.

Index: localserver/firefox/async_task_ff.cc
===================================================================
--- localserver/firefox/async_task_ff.cc (revision 1121)
+++ localserver/firefox/async_task_ff.cc (working copy)
@@ -469,7 +469,9 @@
break;
default:
assert(IsListenerThread());

- OnListenerEvent(msg_code, reinterpret_cast<int>(msg_param));

+ //technically can't reinterpret_cast to int if sizeof(int>) <
+ //sizeof(void*), but we are really sure this is an int.
+ OnListenerEvent(msg_code, static_cast<int>(
+
reinterpret_cast<ptrasint_t>(msg_param)));
break;
}
}
Index: tools/config.mk
===================================================================
--- tools/config.mk (revision 1121)
+++ tools/config.mk (working copy)
@@ -49,7 +49,7 @@

# Set default build mode
# dbg = debug build
# opt = release build

-MODE = dbg
+MODE = opt

# Set default OS architecture
# OSX builds will override this value (see rules.mk).
@@ -57,7 +57,7 @@
ifeq ($(OS),wince)
ARCH = arm
else
- ARCH = i386
+ ARCH = x86_64
endif

# $(shell ...) statements need to be different on Windows (%% vs %).
@@ -124,7 +124,7 @@

COMPILE_FLAGS_dbg = -g -O0
COMPILE_FLAGS_opt = -O2

-COMPILE_FLAGS = -c -o $@ -fPIC -fmessage-length=0 -Wall -Werror $
(COMPILE_FLAGS_$(MODE))
+COMPILE_FLAGS = -c -o $@ -fPIC -fmessage-length=0 -Wall $

(COMPILE_FLAGS_$(MODE))
# NS_LITERAL_STRING does not work properly without this compiler
option
COMPILE_FLAGS += -fshort-wchar

@@ -142,7 +142,7 @@

GECKO_SDK = third_party/gecko_1.8/linux

-FF_LIBS = -L $(GECKO_SDK)/gecko_sdk/bin -L $(GECKO_SDK)/gecko_sdk/lib
-lxpcom -lxpcomglue_s -lnspr4
+FF_LIBS = -L $(GECKO_SDK)/gecko_sdk/bin -L $(GECKO_SDK)/gecko_sdk/lib
-lxpcom -lxpcomglue -lnspr4
endif


######################################################################
Index: base/common/int_types.h
===================================================================
--- base/common/int_types.h (revision 1121)
+++ base/common/int_types.h (working copy)
@@ -26,6 +26,15 @@
#ifndef GEARS_BASE_COMMON_INT_TYPES_H__
#define GEARS_BASE_COMMON_INT_TYPES_H__

+#include <boost/integer.hpp>
+#include <climits>
+
+//intptr_t would clash with C99 stdint.h if it got included somehow.
+//CHAR_BIT is bits/char, and void * must be big enough to hold all
+//pointers to objects.
+typedef boost::int_t<CHAR_BIT * sizeof(void*)>::fast ptrasint_t;
+
+
#ifdef _MSC_VER
#include <float.h> // for _isnan() on VC++
#define isnan(x) _isnan(x) // VC++ uses _isnan() instead of isnan()
Index: base/common/js_runner_ff_marshaling.cc
===================================================================
--- base/common/js_runner_ff_marshaling.cc (revision 1121)
+++ base/common/js_runner_ff_marshaling.cc (working copy)
@@ -553,7 +553,7 @@
//
// We must use PRIVATE_TO_JSVAL (only works on pointers!) to
prevent the
// garbage collector from touching any private data stored in JS
'slots'.
- assert(0 == (0x01 & reinterpret_cast<int>(function_data.get())));
+ assert(0 == (0x01 &
reinterpret_cast<ptrasint_t>(function_data.get())));
function_wrappers_.push_back(
linked_ptr<JsWrapperDataForFunction>(function_data.get()));
jsval pointer_jsval =
PRIVATE_TO_JSVAL((jsval)function_data.release());

[Dennis]

Could someone please post the compiled plugin?

That would be great!

Oh and please send me an email, I'm not on the list.

Thanks!
Dennis

[Scott Wolchok]

I posted my build from last night at:
http://www-personal.umich.edu/~swolchok/gears/gears-linux-opt-0.3.8.0.xpi

Please note that you shouldn't install this unless you trust me, some
random guy on the Internet, as the XPI contains native code. Also,
this is SVN rev 1121 right now, though I'll probably update to 1127
later today. If I decide to post builds regularly, a web page
detailing what's going on will appear at http://www-personal.umich.edu/~swolchok/gears/

[Brad Neuberg]

Hi Scott; thanks for posting this. The best place for patches is actually the google-gears-eng list where the Gears plugin is developed by folks. That list is here:

http://groups.google.com/group/google-gears-eng/

--
Best,
 Brad

 bradn...@google.com
 http://codinginparadise.org

[Chris Prince]

No need to re-post, we got it. :)

We are really excited to have a clean patch that enables 64-bit
support. Right now the eng team is pushing to stabilize the code and
push a new release, but I hope we can take another look at the patch
after that.

Thanks, Scott!
--Chris

[Aaron Boodman]

If there's not a bug already open for this, you could open one and add
the patch there. That would be the best shot to make sure it doesn't
get forgotten.

- a

[Chris Prince]

Yep, I'm already on it.

[John Ripley]

2008/3/6 Scott Wolchok <evilsp...@gmail.com>:

>
> Here is a better (IMO) patch.

...

> Cons:
> * Introduces a build dependency on Boost. Developers must either
> install Boost headers, or we must "deboostify" boost/integer.hpp as
> was done with scoped_ptr.

...

It strikes me that this gains a dependency on the boost library just
to compile 1 typedef and 1 assert. Is this preferable to just using a
#define or two?

John.

[Scott Wolchok]

On Mar 10, 7:06 am, "John Ripley" <jrip...@google.com> wrote:
> 2008/3/6 Scott Wolchok <evilspork...@gmail.com>:

The rationale is that getting this to work across platforms and, more
importantly, across compilers is hard and requires us to keep up with
a variety of compilers or limit the set of usable compilers
artifically. To lose the Boost dependency, we would have to duplicate
the effort of finding the best type to use when casting pointers to
integers, and I think it's pretty clear that this is not as simple as

#ifdef 64BIT
typedef long ptrasint_t;
#else
typedef int ptrasint_t;
#endif

It's not this simple because there are no guarantees about the sizes
of int and long relative to pointer sizes, which means that each
version of each compiler is free to change this. Because the project
does not officially support 64-bit Linux, I felt that Boost had the
minimum impact on the build process given my personal goal of support
without commitment to any particular compiler. Boost is especially to
use on any sane Linux distribution (something like "$PACKAGE_MGR
install libboost-dev" should be sufficient). I freely admit, however,
that I am not familiar with 1) the best way to use third-party
libraries on Windows and 2) Google's process for handling that issue.

It seems like the process is to check libraries into the version
control system. However, I think that Boost determines some system-
specific things during the install process, so you might simply check
a Boost install into your version control system for each officially
supported platform, and then set the include path appropriately
depending on the build system. Unfortunately, Subversion does nothing
to help with the space overhead of this solution.

[Scott Wolchok]

From: Scott Wolchok <evilsp...@gmail.com>
Date: Sat, Jun 14, 2008 at 8:33 PM
Subject: Re: 64 bit Linux support
To: Scott Wolchok <evilsp...@gmail.com>

Updated patch has been posted at
http://code.google.com/p/gears/issues/detail?id=335
. Binary is at http://www-personal.umich.edu/~swolchok/gears/gears-linux-opt-0.3.25.0.xpi
. It passes the unit tests, but other than that I haven't done any
testing.

[Brandon Kruger]

It seems your link to the binary is broken. I look forward to testing
it. Thank you for your work!

On Jun 14, 11:35 pm, "Scott Wolchok" <evilspork...@gmail.com> wrote:
> From: Scott Wolchok <evilspork...@gmail.com>

> Date: Sat, Jun 14, 2008 at 8:33 PM
> Subject: Re: 64 bit Linux support

> To: Scott Wolchok <evilspork...@gmail.com>

>
> Updated patch has been posted athttp://code.google.com/p/gears/issues/detail?id=335

> . Binary is athttp://www-personal.umich.edu/~swolchok/gears/gears-linux-opt-0.3.25....

[Ben Lisbakken]

It looks like this is the link in his directory:

http://www-personal.umich.edu/~swolchok/gears/gears-linux-opt-0.3.8.0.xpi

-Ben

[Brandon Kruger]

The only file there is an older version that isn't compatible with
FF3.

[Scott Wolchok]

I've fixed the link. The binary is now actually at
http://www-personal.umich.edu/~swolchok/gears/gears-linux-opt-0.3.25.0.xpi
. I've upgraded to Firefox 3 just now and the unit tests seem to pass,
so I guess that's good too.

On Jun 17, 6:52 pm, Brandon Kruger <bmk...@gmail.com> wrote:
> The only file there is an older version that isn't compatible with
> FF3.
>
> Ben Lisbakken wrote:
> > It looks like this is the link in his directory:

> >http://www-personal.umich.edu/~swolchok/gears/gears-linux-opt-0.3.8.0...

>
> > -Ben
>
> > On Sun, Jun 15, 2008 at 1:40 PM, Brandon Kruger <bmk...@gmail.com> wrote:
>
> > > It seems your link to the binary is broken.  I look forward to testing
> > > it.  Thank you for your work!
>
> > > On Jun 14, 11:35 pm, "Scott Wolchok" <evilspork...@gmail.com> wrote:
> > > > From: Scott Wolchok <evilspork...@gmail.com>
> > > > Date: Sat, Jun 14, 2008 at 8:33 PM

> > > > Subject: Re:64 bitLinux support

> > > > > does not officially support64-bitLinux, I felt that Boost had the

[Ben Lisbakken]

Scott --

Thanks for your work on this!

-Ben

[Helio MC Pereira]

Why isn't this 64pkg official in google gears?

[Chris Prince]

There have been a lot of questions about 64-bit Linux support in
Gears, so let me try to answer those questions:

First of all, we don't hate 64-bit users. Really, we don't!! In a
perfect world, we would officially support 64-bit Linux, and every
other platform as well.

The problem is simply one of resources. For the officially supported
platforms, we do a *lot* of testing before every release. As users
ourselves, we hate poorly tested software.

So adding 64-bit Linux isn't simply a matter of submitting the patch
(which is something we *will* do). For official support, we would
need to add 64-bit Linux to our test matrix. And that would be a
non-trivial amount of work.

But all is not lost. :) This is one of the great things about
open-source projects. Anybody in the community can build and host
64-bit Linux builds of Gears. Scott has done this for 0.3.25.0, and
hopefully he or somebody else will do so for future builds of Gears on
64-bit Linux. I think this is a great way to get 64-bit Linux support
in the short term.

I hope that gives a little more insight into the 64-bit Linux situation.
--Chris

[Aaron Hayman]

I installed it and it seemed to install fine but it does nothing.
Clicking on Options pulls up nothing and google docs doesn't recognize
it. I'm using Ubuntu 8.04 x64 and FF3 (final release). Have any
ideas?

[Michael M]

Same for me on Fedora 9 (x64).
(Meanwhile, though, thanks for the work.)

[Scott Wolchok]

You might try unzipping the XPI with unzip and running ldd on
libgears.so...if it can't find a shared library perhaps that might
explain the weird behavior? This is a total guess; "it doesn't work"
is not much to go on. =) (interesting that it doesn't work on ubuntu,
though, as I built it on Debian testing)

[raphael]

great Scott, that worked on Fedora 9:
/lib64/libxul.so.0d -> /usr/lib64/xulrunner-1.9/libxul.so

[Christoph Langner]

On 19 Jun., 04:05, "Chris Prince" <cpri...@google.com> wrote:
> But all is not lost. :)  This is one of the great things about
> open-source projects.  Anybody in the community can build and host
> 64-bit Linux builds of Gears.  Scott has done this for 0.3.25.0, and
> hopefully he or somebody else will do so for future builds of Gears on
> 64-bit Linux.  I think this is a great way to get 64-bit Linux support
> in the short term.

Without official support from google the 64-bit version of Gears won't
gain much momentum. Installing unsupported code patched by unkown
people isn't something what i would recommend. This is a "chicken or
the egg" problem. Without a 64-bit version you won't find users who
are able to install the patched version, and without 64-bit testers
there will be no official 64-bit Gears version. So please, publish a
official 64-bit version. Call it alpha. But publish a version which we
can install and test.

[hardawayd]

I have installed Scott's gears for 64 bit just fine. Now when i click
offline in my Google Docs it trys to download gears from Google. What
i am trying to do is install the desktop and synchronize my documents
on my machine. How can you synchronize the documents without
downloading and installing the gears that wont work.

On Jun 18, 9:05 pm, "Chris Prince" <cpri...@google.com> wrote:
> There have been a lot of questions about 64-bit Linux support in
> Gears, so let me try to answer those questions:
>
> First of all, we don't hate 64-bit users.  Really, we don't!!  In a
> perfect world, we would officially support 64-bit Linux, and every
> other platform as well.
>
> The problem is simply one of resources.  For the officially supported
> platforms, we do a *lot* of testing before every release.  As users
> ourselves, we hate poorly tested software.
>
> So adding 64-bit Linux isn't simply a matter of submitting the patch
> (which is something we *will* do).  For official support, we would
> need to add 64-bit Linux to our test matrix.  And that would be a
> non-trivial amount of work.
>
> But all is not lost. :)  This is one of the great things about
> open-source projects.  Anybody in the community can build and host
> 64-bit Linux builds of Gears.  Scott has done this for 0.3.25.0, and
> hopefully he or somebody else will do so for future builds of Gears on
> 64-bit Linux.  I think this is a great way to get 64-bit Linux support
> in the short term.
>
> I hope that gives a little more insight into the 64-bit Linux situation.
> --Chris
>
> On Thu, Jun 19, 2008 at 1:24 AM, Helio MC Pereira
>

> <helio.mc.pere...@gmail.com> wrote:
> > Why isn't this 64pkg official in google gears?
>

> > On Wed, Jun 18, 2008 at 3:53 PM, Ben Lisbakken <lisba...@google.com> wrote:
>
> >> Scott --
>
> >> Thanks for your work on this!
>
> >> -Ben
>

> >> On Tue, Jun 17, 2008 at 9:44 PM, Scott Wolchok <evilspork...@gmail.com>

> >> wrote:
>
> >>> I've fixed the link. The binary is now actually at
>

> >>>http://www-personal.umich.edu/~swolchok/gears/gears-linux-opt-0.3.25....

[Ben Lisbakken]

Google Docs only supports offline mode through Gears -- there is no desktop client for Google Docs.

-Ben

[hardawayd]

I have gears now installed thanks to Scott. But, how do I install the
desktop icon and synchronize my documents now that it is installed?

On Jun 17, 11:44 pm, Scott Wolchok <evilspork...@gmail.com> wrote:
> I've fixed the link. The binary is now actually athttp://www-personal.umich.edu/~swolchok/gears/gears-linux-opt-0.3.25....

[hardawayd]

When i installed gears on my Mac it gave me the option of installing a
desktop icon for google docs and then synchronized all of my google
documents to my local drive. How do i do that on Linux now that i have
gears installed?

On Jul 18, 12:54 pm, Ben Lisbakken <lisba...@google.com> wrote:
> Google Docs only supports offline mode through Gears -- there is no desktop
> client for Google Docs.
>
> -Ben
>

> >http://www-personal.umich.edu/~swolchok/gears/gears-linux-opt-0.3.25..<http://www-personal.umich.edu/%7Eswolchok/gears/gears-linux-opt-0.3.25..>
> > ..

> > > >>> . I've upgraded to Firefox 3 just now and the unit tests seem to
> > pass,
> > > >>> so I guess that's good too.
>
> > > >>> On Jun 17, 6:52 pm, Brandon Kruger <bmk...@gmail.com> wrote:
> > > >>> > The only file there is an older version that isn't compatible with
> > > >>> > FF3.
>
> > > >>> > Ben Lisbakken wrote:
> > > >>> > > It looks like this is the link in his directory:
>

> >http://www-personal.umich.edu/~swolchok/gears/gears-linux-opt-0.3.8.0.<http://www-personal.umich.edu/%7Eswolchok/gears/gears-linux-opt-0.3.8.0.>
> > ..

>
> > > >>> > > -Ben
>
> > > >>> > > On Sun, Jun 15, 2008 at 1:40 PM, Brandon Kruger <
> > bmk...@gmail.com>
> > > >>> > > wrote:
>
> > > >>> > > > It seems your link to the binary is broken.  I look forward to
> > > >>> > > > testing
> > > >>> > > > it.  Thank you for your work!
>
> > > >>> > > > On Jun 14, 11:35 pm, "Scott Wolchok" <evilspork...@gmail.com>
> > > >>> > > > wrote:
> > > >>> > > > > From: Scott Wolchok <evilspork...@gmail.com>
> > > >>> > > > > Date: Sat, Jun 14, 2008 at 8:33 PM
> > > >>> > > > > Subject: Re:64 bitLinux support
> > > >>> > > > > To: Scott Wolchok <evilspork...@gmail.com>
>
> > > >>> > > > > Updated patch has been posted athttp://
> > > >>> > > > code.google.com/p/gears/issues/detail?id=335
> > > >>> > > > > . Binary is athttp://
>

> > www-personal.umich.edu/~swolchok/gears/gears-linux-opt-0.3.25..<http://www-personal.umich.edu/%7Eswolchok/gears/gears-linux-opt-0.3.25..>
> > ..

[Ben Lisbakken]

Are you having problems on Linux?  The process should be the same as on your Mac.

-Ben

[Scott Wegner]

Hi All,

I'd like to also test out Google Gears for 64-bit Linux. I just
downloaded Scott's patch, and it's complaining that it's not
compatible with Firefox 3.0.1-- anybody care to post an update?

I'm about to try to compile it myself on Ubuntu. Scott's patch is
written for revisions 1121, so that's what I'm updating to. Does that
revision represent some stable release point, or just happened to be
the latest at the time? Is it relatively safe to use the latest
revision?

Scott

On Jun 18, 9:05 pm, "Chris Prince" <cpri...@google.com> wrote:

> There have been a lot of questions about 64-bit Linux support in
> Gears, so let me try to answer those questions:
>
> First of all, we don't hate 64-bit users.  Really, we don't!!  In a
> perfect world, we would officially support 64-bit Linux, and every
> other platform as well.
>
> The problem is simply one of resources.  For the officially supported
> platforms, we do a *lot* of testing before every release.  As users
> ourselves, we hate poorly tested software.
>
> So adding 64-bit Linux isn't simply a matter of submitting the patch
> (which is something we *will* do).  For official support, we would
> need to add 64-bit Linux to our test matrix.  And that would be a
> non-trivial amount of work.
>
> But all is not lost. :)  This is one of the great things about
> open-source projects.  Anybody in the community can build and host
> 64-bit Linux builds of Gears.  Scott has done this for 0.3.25.0, and
> hopefully he or somebody else will do so for future builds of Gears on
> 64-bit Linux.  I think this is a great way to get 64-bit Linux support
> in the short term.
>
> I hope that gives a little more insight into the 64-bit Linux situation.
> --Chris
>
> On Thu, Jun 19, 2008 at 1:24 AM, Helio MC Pereira
>

> <helio.mc.pere...@gmail.com> wrote:
> > Why isn't this 64pkg official in google gears?
>

> > On Wed, Jun 18, 2008 at 3:53 PM, Ben Lisbakken <lisba...@google.com> wrote:
>
> >> Scott --
>
> >> Thanks for your work on this!
>
> >> -Ben
>

> >> On Tue, Jun 17, 2008 at 9:44 PM, Scott Wolchok <evilspork...@gmail.com>

> >> wrote:
>
> >>> I've fixed the link. The binary is now actually at
>

> >>>http://www-personal.umich.edu/~swolchok/gears/gears-linux-opt-0.3.25....

[Graingert]

@Scott Wolchok: Will you be compiling the gears 64bit release that is
compatible with 3.0.1?

[Scott Wolchok]

I've got *ahem* "Iceweasel" 3.0.1 now, but I'm getting burned by the
change in SVN repository so I'll have to do a build after I get some
sleep. Hopefully, there'll be a new binary up by 3 PM on July 27 PDT.
FWIW, I appreciate the attention but I don't even use Gears -- hence
the slow reaction time to Gears/browser changes.