In Ubuntu, i'm building with the so-called hardening-wrapper.
It means having the hardening-wrapper package installed at build-time,
and building the using the debian/ubuntu tools with DEB_BUILD_HARDENING=1
(it diverts the toolchain to add flags so packages don't have to be tweaked
further).
Details are here: https://wiki.ubuntu.com/Security/HardeningWrapper

===
I build trunk and all the channels (in PPAs) with that wrapper, on:
- {maverick,lucid,karmic} x {i386,amd64}
- {jaunty,hardy} x {i386,amd64,lpia}

I also build the stable releases on {maverick,lucid} x {i386,amd64,armel} (for the official distributions, not PPAs)
===

It works reasonably well except:
- on amd64 for both jaunty and hardy

http://launchpadlibrarian.net/55436522/buildlog_ubuntu-hardy-amd64.chromium-browser_6.0.472.55~r58392-0ubuntu1~ucd1~hardy_FAILEDTOBUILD.txt.gz

  LINK(target) out/Release/chrome
/usr/bin/ld.real: out/Release/obj.target/native_client/src/trusted/service_runtime/arch/x86_64/libservice_runtime_x86_64.a(nacl_tls_64.o): relocation R_X86_64_TPOFF32 against `nacl_thread_index' can not be used when making a shared object; recompile with -fPIC
out/Release/obj.target/native_client/src/trusted/service_runtime/arch/x86_64/libservice_runtime_x86_64.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[1]: *** [out/Release/chrome] Error 1

- on armel (probably all dists, just tested with maverick and lucid)

http://launchpadlibrarian.net/55522699/buildlog_ubuntu-maverick-armel.chromium-browser_6.0.472.55~r58392-0ubuntu1_FAILEDTOBUILD.txt.gz

  LINK(target) out/Release/chrome
/usr/bin/ld.bfd.real: out/Release/obj.target/skia/libskia.a(SkBlurDrawLooper.o)(.text._ZN16SkBlurDrawLooper10CreateProcER23SkFlattenableReadBuffer[SkBlurDrawLooper::CreateProc(SkFlattenableReadBuffer&)]+0x6): unresolvable R_ARM_THM_CALL relocation against symbol `operator new(unsigned int)@@GLIBCXX_3.4'
/usr/bin/ld.bfd.real: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
make[1]: *** [out/Release/chrome] Error 1

(you may want to copy the logs here, i can't guaranty their stability)

The R_X86_64_TPOFF32 is a linker bug: http://sourceware.org/bugzilla/show_bug.cgi?id=10434

As for the ARM build: it's coming from a static non-POD object, which always suggests problems. I can't see any explicit |new| calls however, and I don't have an ARM build setup to be able to play around.

apparently, the R_ARM_THM_CALL issue is on maverick only, not lucid.

We build with some of these on the Mac now. I think we already have bugs covering everything else we can add.

For example, PIE confused Valgrind, so we had to turn it off.

There could be build switch, which enables PIE. PIE should have better performance than PIC. Average user doesn't use Valgrind.

 Issue 67821  has been merged into this issue.

Not going to get to this before I go on leave, sorry.

(Un-ccing myself from bugs.)

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

------------------------------------------------------------------------
r168889 | phajdan.jr@chromium.org | 2012-11-20T22:35:25.500644Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/build/common.gypi?r1=168889&r2=168888&pathrev=168889

Use more hardening flags:

-D_FORTIFY_SOURCE=2
-Wl,-z,now (aka BIND_NOW)
-Wl,-z,relro (read-only relocation tables)

BUG= 55439 

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

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

------------------------------------------------------------------------
r172225 | phajdan.jr@chromium.org | 2012-12-11T01:54:58.179229Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/build/common.gypi?r1=172225&r2=172224&pathrev=172225

Only build with _FORTIFY_SOURCE in Release mode.

This prevents build failures on Fedora.

BUG= 16257 ,  55439 

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

Should we close this bug and eventually open a new one for the remaining flags?

Yup, closing.