[cairo] Build system b0rkage and pthread

[M Joonas Pihlaja]

On Wed, 11 Aug 2010, Behdad Esfahbod wrote:

>   - In configure.ac.pthread:
> 
>     * Please add "static" to all the C functions you define.

Why, does the compiler complain that the functions are unused or 
something?

>     * Use of CAIRO_CC_TRY_LINK_WITH_ENV_SILENT() in pthread check or for ANY
> OTHER REASON is B0RKED.  There is no way that you can write code that does not
> generate warnings with my compiler.  Just don't make such stupid assumptions.  Ok?

While I agree that CAIRO_CC_TRY_LINK_WITH_ENV_SILENT() _may_ be 
overkill for the pthread checks, it is most definitely not for the 
purpose it was made for: checking that some random flag or feature 
thrown at the compiler doesn't produce errors or warnings.

> Right now master simply doesn't succeed configuring on my machines.  Have to
> change that stupid check.

Thanks for the heads up.  If you describe the problem with specifics 
we can probably come up with an acceptable solution.

> What's wrong with just checking that the linking succeeds again?

Some compilers produce spurious output or code when given flags or 
pragmas/attributes which weren't meant for them.  They may be ignored 
with nothing but a "hey, I didn't really grok this flag/feature but 
never mind, gonna pretend I didn't see it" warning to stderr, causing 
a link-only test to yield a false positive when checking for some 
feature.

This wouldn't be such a problem if we weren't trying to throw fifteen 
million random flags and features at the compiler at configure time 
which are really only useful for developers (especially all the 
warning flags, __attributes__, and even pthread flags, I'm looking at 
you lot.)

*All* compilers manage to compile hello-world.c without moaning, so 
our tests should be at the level of hello-world.c + the feature under 
test.  If it can't compile that without warnings, it may not be safe 
to use the feature on that system.  If our tests don't fit that 
template for some reason, we need to modify them until they do.

> Please, please, please, avoid creative solutions to build problems.  
> Kick me hard and I'll come up with a good way to do it.

Welcome back. :)

Cheers,

Joonas