chrome_common.gypi: added dependency on bzip2.gyp, needed by following files:

chrome_common.gypi: added dependency on bzip2.gyp, needed by following files:

bzip2_unittest.cc
metrics_helpers.cc

The issue got detected while preparing the package for Gentoo Linux. We remove
the third party libraries completely, and without that dep the mentioned
files try to use the bundled headers instead of system-provided ones.

TEST=none
BUG=none

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=50254

[ananta, 2010-06-18 13:01:49]

LGTM

[agl, 2010-06-18 14:22:14]

LGTM

[TVL, 2010-06-18 14:26:56]

drive by:

if those targets need bzip2, why don't they depend on it?  ie-if you build those
targets directly (in a clean tree), won't they still fail due to the missing
dep?

[Paweł Hajdan Jr., 2010-06-18 17:22:36]

On 2010/06/18 14:26:56, TVL wrote:
> drive by:
> 
> if those targets need bzip2, why don't they depend on it?  ie-if you build
those
> targets directly (in a clean tree), won't they still fail due to the missing
> dep?

One thing is linking dependency (I think that base or some other low-level
library already depends on bzip2). Another is having USE_SYSTEM_BZIP2
preprocessor symbol defined. It is only defined for direct dependents, meaning
that if you're no a direct dependent, you don't get that symbol defined, but
still get linked with bzip2.

Now why wasn't it detected before? Because the third party bzip2 headers are
normally still there (physically). If one builds with system bzip2, but
something accidentally uses the bundled headers, it's hard to notice unless some
evil header mismatch causes trouble.

In Gentoo, the distro build scripts removes bundled code files (including
headers), just to be sure we really don't use them. I can do a more in-depth
investigation if you'd like.

[Evan Martin, 2010-06-21 15:29:41]

On 2010/06/18 17:22:36, Paweł Hajdan Jr. wrote:
> Now why wasn't it detected before? Because the third party bzip2 headers are
> normally still there (physically). If one builds with system bzip2, but
> something accidentally uses the bundled headers, it's hard to notice unless
some
> evil header mismatch causes trouble.

I wonder how many situations this problem comes up in.  :(

I wonder if there's a way to make it fail to compile rather than get mixed
headers?  I guess we have the source root in the -I flags and the includes look
like "third_party/whatever/", so moving the unused third_party bits out of the
way like you have done might be the best we can do...

I guess you could use the -H flag to gcc and grep the output for mentions of the
bad directories, but that would probably be kind of annoying to set up.