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.
On 7/16/07, John Yodsnukis <john.yodsnu...@gmail.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.
> On 7/16/07, John Yodsnukis <john.yodsnu...@gmail.com> wrote:
> > 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
On Dec 25, 2007 9:37 PM, sathiya <getsath...@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
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:
> On Dec 25, 2007 9:37 PM, sathiya <getsath...@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>
> > > > On 7/16/07, John Yodsnukis <john.yodsnu...@gmail.com> wrote:
> > > > > Here's a patch that allowed me to compile from svn source under 64 bit Linux.
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
+#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());
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/
On Mar 6, 3:47 am, Dennis <D.G.Jan...@googlemail.com> wrote:
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:
> 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.
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.
On Fri, Mar 7, 2008 at 5:04 PM, Brad Neuberg <bradneub...@google.com> wrote: > 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:
> On Wed, Mar 5, 2008 at 11:06 PM, Scott Wolchok <evilspork...@gmail.com> > wrote:
> > 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.
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.
On Fri, Mar 7, 2008 at 5:09 PM, Chris Prince <cpri...@google.com> wrote:
> 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
> On Fri, Mar 7, 2008 at 5:04 PM, Brad Neuberg <bradneub...@google.com> wrote: > > 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:
> > On Wed, Mar 5, 2008 at 11:06 PM, Scott Wolchok <evilspork...@gmail.com> > > wrote:
> > > 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.
On Fri, Mar 7, 2008 at 5:10 PM, Aaron Boodman <a...@google.com> wrote:
> 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
> On Fri, Mar 7, 2008 at 5:09 PM, Chris Prince <cpri...@google.com> wrote:
> > 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
> > On Fri, Mar 7, 2008 at 5:04 PM, Brad Neuberg <bradneub...@google.com> wrote: > > > 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:
> > > On Wed, Mar 5, 2008 at 11:06 PM, Scott Wolchok <evilspork...@gmail.com> > > > wrote:
> > > > 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.
> 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. ... > --- 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());
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?
> 2008/3/6 Scott Wolchok <evilspork...@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.
> ...
> > --- 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());
> 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.
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.
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>
> On Mar 10, 7:06 am, "John Ripley" <jrip...@google.com> wrote:
> > 2008/3/6 Scott Wolchok <evilspork...@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. > > ... > > > --- 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());
> > 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.
> 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.
> 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>
> On Mar 11, 1:02 pm, Scott Wolchok <evilspork...@gmail.com> wrote:
> > On Mar 10, 7:06 am, "John Ripley" <jrip...@google.com> wrote:
> > > 2008/3/6 Scott Wolchok <evilspork...@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.
> > > ...
> > > > --- 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());
> > > 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.
> > 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.
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 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.... > > . It passes the unit tests, but other than that I haven't done any > > testing.
> > On Mar 11, 1:02 pm, Scott Wolchok <evilspork...@gmail.com> wrote:
> > > On Mar 10, 7:06 am, "John Ripley" <jrip...@google.com> wrote:
> > > > 2008/3/6 Scott Wolchok <evilspork...@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. > > > > ... > > > > > --- 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
> > > > 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.
> > > 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
> > > 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.
> 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 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....
> > > . It passes the unit tests, but other than that I haven't done any
> > > testing.
> > > On Mar 11, 1:02 pm, Scott Wolchok <evilspork...@gmail.com> wrote:
> > > > On Mar 10, 7:06 am, "John Ripley" <jrip...@google.com> wrote:
> > > > > 2008/3/6 Scott Wolchok <evilspork...@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.
> > > > > ...
> > > > > > --- 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
> > > > > 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.
> > > > 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
> > > > 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.
> > 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....
> > > > . It passes the unit tests, but other than that I haven't done any
> > > > testing.
> > > > On Mar 11, 1:02 pm, Scott Wolchok <evilspork...@gmail.com> wrote:
> > > > > On Mar 10, 7:06 am, "John Ripley" <jrip...@google.com> wrote:
> > > > > > 2008/3/6 Scott Wolchok <evilspork...@gmail.com>:
> > > > > > 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.
> > > > > 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
> > > > > 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 support64-bitLinux, 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.
> > > 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..> > .. > > > > > . It passes the unit tests, but other than that I haven't done any > > > > > testing.
> > > > > On Mar 11, 1:02 pm, Scott Wolchok <evilspork...@gmail.com> wrote:
> > > > > > On Mar 10, 7:06 am, "John Ripley" <jrip...@google.com> wrote:
> > > > > > > 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.
> > > > > > 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
> > > > > > 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 support64-bitLinux, 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.
>> > > 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..> >> .. >> > > > > . It passes the unit tests, but other than that I haven't done any >> > > > > testing.
>> > > > > On Mar 11, 1:02 pm, Scott Wolchok <evilspork...@gmail.com> wrote:
>> > > > > > On Mar 10, 7:06 am, "John Ripley" <jrip...@google.com> wrote:
>> > > > > > > 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.
>> > > > > > 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
>> > > > > > 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 support64-bitLinux, 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.
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 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.... >>> > > > > . It passes the unit tests, but other than that I haven't done >>> > > > > any >>> > > > > testing.
>>> > > > > On Mar 11, 1:02 pm, Scott Wolchok <evilspork...@gmail.com> wrote:
>>> > > > > > On Mar 10, 7:06 am, "John Ripley" <jrip...@google.com> wrote:
>>> > > > > > > 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.
>>> > > > > > 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
>>> > > > > > 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 support64-bitLinux, 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.
|
