this mostly depends on getting v8 to be 64 bit. I can't find another open bug for 
this, although I would have thought there was one.

 Issue 16077  has been merged into this issue.

So, grabbing the Chromium source and compiling it as 64 bit will not work?

A 64 bit build would be cool to have.

This applies to Linux, too.

It applies to Mac OS X as well. Indeed it would apply to any OS that supports 64-bit 
and Chromium; though I bet the Chromium team will focus primarily on Windows, Linux, 
and OS X.

 Issue 18398  has been merged into this issue.

On 64 bit Ubuntu 9.04 the 'amd64' .deb package is unable to load many libraries.  A
native 64 bit build would be great.

/usr/lib/gio/modules/libgioremote-volume-monitor.so: wrong ELF class: ELFCLASS64
Failed to load module: /usr/lib/gio/modules/libgioremote-volume-monitor.so
/usr/lib/gio/modules/libgiogconf.so: wrong ELF class: ELFCLASS64
Failed to load module: /usr/lib/gio/modules/libgiogconf.so
/usr/lib/gio/modules/libgvfsdbus.so: wrong ELF class: ELFCLASS64
Failed to load module: /usr/lib/gio/modules/libgvfsdbus.so
[31872:31877:173302809314:ERROR:/b/slave/chrome-official-linux/build/src/base/native_library_linux.cc(19)]
dlopen failed when trying to open /home/gregc/.mozilla/plugins/libflashplayer.so:
/home/gregc/.mozilla/plugins/libflashplayer.so: wrong ELF class: ELFCLASS64
[31872:31877:173302809398:ERROR:/b/slave/chrome-official-linux/build/src/base/native_library_linux.cc(19)]
dlopen failed when trying to open /home/gregc/.mozilla/plugins/libflashplayer.so.old:
/home/gregc/.mozilla/plugins/libflashplayer.so.old: wrong ELF class: ELFCLASS64
[31872:31877:173302809442:ERROR:/b/slave/chrome-official-linux/build/src/base/native_library_linux.cc(19)]
dlopen failed when trying to open /home/gregc/.mozilla/plugins/libnpjp2.so:
/home/gregc/.mozilla/plugins/libnpjp2.so: wrong ELF class: ELFCLASS64
[31872:31877:173302809540:ERROR:/b/slave/chrome-official-linux/build/src/base/native_library_linux.cc(19)]
dlopen failed when trying to open /opt/google/chrome/plugins/libflashplayer.so:
/opt/google/chrome/plugins/libflashplayer.so: wrong ELF class: ELFCLASS64
[31872:31877:173302809617:ERROR:/b/slave/chrome-official-linux/build/src/base/native_library_linux.cc(19)]
dlopen failed when trying to open /usr/lib/mozilla/plugins/libskypebuttons.so:
/usr/lib/mozilla/plugins/libskypebuttons.so: wrong ELF class: ELFCLASS64

@gergnz

This is because currently there is no native 64-bit chromium.  It is 32-bit version, 
thus the ELFCLASS64 trying to auto load plugins from mozilla which are 64-bit.

 Issue 18608  has been merged into this issue.

Hi Guys,
if someone is interested, I'm just uploaded on my site (http://ansani.it/chrome) a 
fresh build of Linux Chrome 64bit (you can use all mozilla 64 bit plugins - flash 
too!!).

My project is to create an automated build system and a .deb package (I mostly use a 
64bit experimental debian).

You can download it and unpack on /opt/google dir (it's a tar.bz2 package - tar jxvf 
chrome64_....._.bz2).

I currently use it and all is OK.

Hope this is usefule for someone.

Regards,
Salvatore

ansani's build is working fine on my Ubuntu 9.04 amd64 box.  And yes, Flash is working 
fine.  Thank you!

(No comment was entered for this change.)

@ansani

What distro you used to compile? Have dependencies from mozilla with .1d or .0d
extension on NSS libs.

@reinaldo

I used an experimental debian distro. NSS libs depends on .1d.

(No comment was entered for this change.)

Just to note, Chrome Linux is building / running / passing tests on 64-bit.

https://code.google.com/p/chromium/wiki/LinuxChromium64

There will be more work involved to have it running on Windows or Mac.

If you're on Ubuntu, the best bet is to use the Chromium Daily build PPA:

https://launchpad.net/~chromium-daily/+archive/ppa

The description says:

"The amd64 package is no longer using ia32-libs. It contains *native* 64bit debs."

I tried it, and it works as advertised (Flash, etc.).  A nice touch in the package is 
the using of system-wide configuration in /etc/chromium-browser/default, where you can 
configure the "--enable-plugins" flag.

fyi this also works on Debian. I used the jaunty repo for Debian Sid and that worked 
like a charm.

Google Chrome is native 64-bit on Linux as of 4.0.203.2 
(http://googlechromereleases.blogspot.com/2009/08/dev-channel-update-linux-true-64-
bit.html)

FYI version 4.0.203.2 is running fine on Slackware64 13. Need only creation of
symbolic links for NSS libs with .1d or .0d extensions and install GConf.

 Issue 20468  has been merged into this issue.

I added chromium ppa and use latest snapshot. Javatester screen withing chromium says 
using jre 12. Not sure if 64 or 32.  However, using jre 18 64 bit version on opera 
and ff on same ubuntu jaunty 64 machine. 

java version "1.6.0_18-ea"
Java(TM) SE Runtime Environment (build 1.6.0_18-ea-b02)
Java HotSpot(TM) 64-Bit Server VM (build 16.0-b09, mixed mode)

How can I get chromium to use this instead? Am being impatient but curious. Thanks.

Well, given Linux has native x64 builds now, what component is holding back Windows x64 
builds?

GYP work needs to be done first.

MSVS supports the concept of "platforms" (in its strictest MS-only sense) so you can 
have a platform(x86/x64/arm/ia64) x target(release/debug) matrix.

We just need to make the generator output the necessary .vcproj glue to generate the 
x64 build platform. That'd be nice but I don't have cycles to work on that.

This is not a requirement for mstone-4.

(No comment was entered for this change.)

Replacing labels:
   Area-BrowserBackend by Area-Internals

This is indeed a serious problem. Chrome on Win7 64bit does not run smoothly. I have 
what most would consider a monster machine in terms of specs and people with dinosaurs 
are running Chrome faster than me simply because their OS's are 32bit. 

@meoknet

There is likely some other issue with your computer. I have never heard anyone else 
complain about performance in a 64-bit OS, nor have I personally had any problems (Win 
7 64-bit).

(No comment was entered for this change.)

Now, since there are the first beta of Flash 64bit, the time should have come nevertheless for chrome 64bit. When can one count finally on one build?

"Comment 33 by heinrichwitt1961, Today (3 minutes ago)
Now, since there are the first beta of Flash 64bit, the time should have come nevertheless for chrome 64bit. When can one count finally on one build?
"

+1 for this. Also, would it use more ram then 32bit version?

This is not the place for such discussions. 173 people are getting each and every reply to this topic. This place is for chromium developers.

You are right. I'm sorry.

I thought it might be worth mentioning the sandbox instability on Win 7 Enterprise 64-bit which I reported here in case it's related to this. https://code.google.com/p/chromium/issues/detail?id=50491

Anything new for this issue?

(No comment was entered for this change.)

laforge: what's the story for 64-bit Chrome for Windows?

The list from maruel@

- fix sandbox
- 64 bit flash
- most of the hard work as been done; especially porting v8
- build support

 Issue 87532  has been merged into this issue.

Robert Shield also pointed out that there would be requirements on the installer and way we serve payloads.

(No comment was entered for this change.)

 Issue 140203  has been merged into this issue.

I may regret this.

(No comment was entered for this change.)

 Issue 159308  has been merged into this issue.

 Issue 160438  has been merged into this issue.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=167578

------------------------------------------------------------------------
r167578 | scottmg@chromium.org | 2012-11-14T02:48:04.306535Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/DEPS?r1=167578&r2=167577&pathrev=167578

roll gyp 1533:1534

r1534: ninja windows: Support x64 configuration platform

TBR=bradnelson@chromium.org
BUG=8606


Review URL: https://chromiumcodereview.appspot.com/11293262
------------------------------------------------------------------------

You can try to build chrome 64 with ninja with the change above now:

  python build\gyp_chromium -Dtarget_arch=x64
  ninja -C out\Debug_x64 chrome

With "-Dtarget_arch=x64", ffmpeg errors out because it lacks a config header.

Without "-Dtarget_arch=x64" some subprojects (v8, codecs) will build in x86 (so the end result is probably going to be quite wrong). However, much of the rest standard chrome code (try to) build normally, so that would be a way to work through some of the random other compile errors that need to be fixed.

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=177264

------------------------------------------------------------------------
r177264 | scottmg@chromium.org | 2013-01-16T23:34:04.434059Z

Changed paths:
   A http://src.chromium.org/viewvc/chrome/trunk/src/base/safe_numerics_unittest.cc?r1=177264&r2=177263&pathrev=177264
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/base.gyp?r1=177264&r2=177263&pathrev=177264
   A http://src.chromium.org/viewvc/chrome/trunk/src/base/safe_numerics.h?r1=177264&r2=177263&pathrev=177264
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/base.gypi?r1=177264&r2=177263&pathrev=177264
   A http://src.chromium.org/viewvc/chrome/trunk/src/base/safe_numerics_unittest.nc?r1=177264&r2=177263&pathrev=177264

Add numeric_cast for checked integral narrowing casts

In work on bringing up Windows x64, there are many places that need
to be safely narrowed to the types used for interacting with other
APIs (particularly when using containers). Rather than scatter these
CHECKs all over, numeric_cast<> CHECKs that the runtime value can be
safely converted to the target type.

BUG=8606, 167187, 166496

Review URL: https://codereview.chromium.org/11886037
------------------------------------------------------------------------

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

 Issue 224468  has been merged into this issue.

 Issue 233740  has been merged into this issue.

 Issue 239582  has been merged into this issue.

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

Wrong one.

(No comment was entered for this change.)

Thinning out some issues that have progressed far enough to not be blockers.

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

I'm going to call this fixed since we shipped to stable.

@wfh - do you want to look close out the three remaining blockers? Because you owned those and I'm pretty sure they're all fixed.