> 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
> > > > 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

> > >  ===================================================================
> > > > > > >  --- 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

> > > > > #ifdef64BIT
> > > > > 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 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.