autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Testing for GCC-like attributes and compiler switches


From: Peter Rosin
Subject: Re: Testing for GCC-like attributes and compiler switches
Date: Sat, 16 Oct 2010 10:51:35 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4

Den 2010-10-16 10:39 skrev Ralf Wildenhues:
> Hello Václav,
> 
> * Václav Haisman wrote on Fri, Oct 15, 2010 at 08:56:51PM CEST:
>> I am having difficulty testing for compiler features like
>> __declspec(dllimport) and switches like -Wall or -Werror.
>>
>> The problem has started like this. I wanted to test compiler for
>> __declspec(dllimport) (for Windows) and if that fails for
>> __attribute__((visibility("default"))) (for *nix/GCC). With GCC this works
>> because it does support both, it supports __declspec(dllimport) even outside
>> Windows. But with e.g. Clang, this fails. Clang accepts the code of the
>> test-case with just warning like:
>>
>> "conftest.cpp:20:12: warning: 'dllexport' attribute ignored"
>>
>> The test-case passes but the compiler does not support the feature.
>>
>> I thought I could "fix" this by trying to test for -Werror first and giving
>> it to the compiler for the test-case. However there is the problem with
>> detecting/collecting -Werror equivalent switches for all the various
>> compilers. Before I started with that, I have noticed the Sun Studio C++
>> compiler happily accepts -Wall (the test for it passes) even though it warns
>> that it does not know such option. So this method is useless.
>>
>> How is one supposed to test these things with autoconf?
> 
> First by complaining to the compiler vendor about the hard-to-test
> command-line API.  APIs that don't lend themselves well to
> automatization (in the name of user friendliness) suck a lot in the long
> rung, even independently of Autoconf.
> 
> Then, you can do something similar to what Libtool does in its
> _LT_COMPILER_OPTION macro: compile once wihtout the thing that evokes
> the warning, and once with, compare stderr output of both and consider
> any differences as failure.  If you're sure that the tested code doesn't
> produce any warnings otherwise, you can instead use AC_LANG_WERROR to
> count any warnings as failure.

Err, well, no you can't.  The Microsoft C Compiler (cl.exe) outputs its
dang boilerplate crap on stderr and that's not a warning.  But it still
foils AC_LANG_WERROR.

Or is your weekend over yet, and a patch pending that fixes this
AC_LANG_WERROR deficiency in another way than my rejected attempt? :->

Cheers,
Peter



reply via email to

[Prev in Thread] Current Thread [Next in Thread]