This is  bug 30356 . I don't think we provide any support for chrome-linux.zip?

Still true:
 wget http://build.chromium.org/buildbot/continuous/linux/LATEST/chrome-linux.zip
 unzip chrome-linux.zip
 readelf -d chrome-linux/chrome | grep libbz2
outputs
 0x00000001 (NEEDED)                     Shared library: [libbz2.so.1.0]

Yeah, we don't support chrome-linux.zip. We still want this to work, though.
The underlying problem may be that libbz2 isn't in LSB yet?
See http://bugs.linuxbase.org/show_bug.cgi?id=404

Should we mark this as a dup of  bug 30356 ?
Assigning to thestig since he owns that bug.

The 9th comment in the lsb bug sums it up - Debian follows upstream, and use 
libbz2.so.1.0 as the SONAME. RPM distros, Gentoo, and Slackware changed it to 
libbz2.so.1. The Linux distros need to come to an agreement on this.

I guess I can add a workaround to the chrome-wrapper script.

Hmm, I just tried running chrome-linux.zip on a Fedora box, and it's missing all the 
libnss/nspr symlinks too. So the continuous builds has never worked out of the box on 
Fedora.

Yes, that has always been the case. I'm not sure why I didn't file a bug report on 
this earlier, but probably because I only tried on Fedora 8 and didn't expect it to 
work out of the box on an older distro anyway. Only when libbz2 changed I noticed this 
is also the same on recent Fedora versions.

I changed the wrapper script in r35727 to automatically create the symlinks if needed.

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

------------------------------------------------------------------------
r35727 | thestig@chromium.org | 2010-01-07 12:57:33 -0800 (Thu, 07 Jan 2010) | 5 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/tools/build/linux/chrome-wrapper?r1=35727&r2=35726

Linux: Change the generic chrome-wrapper script to look for missing libs and create symlinks.

BUG= 30810 
TEST=Continuous builds work out of the box on RPM distros.
Review URL: http://codereview.chromium.org/518052
------------------------------------------------------------------------

Just want to confirm it works. Thanks.

There is still a slight problem. The requirements have been updated a bit recently 
and the following message appeared.

FATAL:/b/slave/chromium-rel-linux/build/src/base/nss_util.cc(84)] Check failed: 
NSS_VersionCheck("3.12.3"). We depend on NSS >= 3.12.3

So I updated to nspr and nss of a more recent Fedora version, but the location of 
libnss3.so and other files changed from /usr/lib to /lib. The wrapper picks that up, 
but cannot update the symlinks. I suggest to use ln -fs instead of ln -s here.

I didn't think distros would move stuff around, but ok.

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

------------------------------------------------------------------------
r36915 | thestig@chromium.org | 2010-01-22 14:59:15 -0800 (Fri, 22 Jan 2010) | 5 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/tools/build/linux/chrome-wrapper?r1=36915&r2=36914

Linux: Change the generic chrome-wrapper script to overwrite symlinks it creates.

BUG= 30810 
TEST=none
Review URL: http://codereview.chromium.org/548113
------------------------------------------------------------------------

[3362:3370:1813557400976:FATAL:/b/slave/chromium-rel-linux/build/src/base/nss_util.cc(84)]
Check failed: NSS_VersionCheck("3.12.3"). We depend on NSS >= 3.12.3
zsh: trace trap  ./chrome

I'm seeing this on Ubuntu, with libnss3-1d version 3.12.3.1-0ubuntu0.8.04.2
installed. This is both with the chrome-linux 36997 and the PPA build of 36973
(current 32-bit hardy build). Ideas?

@palfrey: I'm not sure why that check is failing for you. Since you're using the PPA 
and not the snapshots, you probably have a slightly different problem. I recommend 
filing a new bug.

You'll probably want to check the following:
Run "ldd /path/to/chrome | grep libnss3"
which should output:  libnss3.so.1d => /path/to/libnss3.so.1d (0xdeadbeef)

Then run: "objdump -p /path/to/libnss3.so.1d" and make sure "NSS_3.12.3" is in the 
Version definitions.

@thestig: Both versions point towards /usr/lib/libnss3.so.1d, which has a rather long
version definitions, containing lots of things including NSS_3.12.3, so hence I'm
stumped. The PPA already has a version check to make sure I've got a sufficiently
recent libnss, hence my confusion here.

Version definitions:
1 0x01 0x08a15b64 libnss3.so.1d
2 0x00 0x03892642 NSS_3.2
3 0x00 0x09264891 NSS_3.2.1
4 0x00 0x03892643 NSS_3.3
5 0x00 0x09264791 NSS_3.3.1
6 0x00 0x03892644 NSS_3.4
7 0x00 0x03892645 NSS_3.5
8 0x00 0x03892646 NSS_3.6
9 0x00 0x03892647 NSS_3.7
10 0x00 0x09264b91 NSS_3.7.1
11 0x00 0x03892648 NSS_3.8
12 0x00 0x03892649 NSS_3.9
13 0x00 0x09264992 NSS_3.9.2
14 0x00 0x09264993 NSS_3.9.3
15 0x00 0x08926470 NSS_3.10
16 0x00 0x02647b82 NSS_3.10.2
17 0x00 0x08926471 NSS_3.11
18 0x00 0x02647c81 NSS_3.11.1
19 0x00 0x02647c82 NSS_3.11.2
20 0x00 0x02647c87 NSS_3.11.7
21 0x00 0x02647c89 NSS_3.11.9
22 0x00 0x08926472 NSS_3.12
23 0x00 0x02647d81 NSS_3.12.1
24 0x00 0x02647d83 NSS_3.12.3

Please file a new bug report. Thanks!

palfrey: please cc me (wtc) and evan in your bug report.  Thanks.

New report now opened at http://code.google.com/p/chromium/issues/detail?id=33163.
Currently installing debug symbols to see if a better stack trace is useful.

This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.