bug-autoconf
[Top][All Lists]
Advanced

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

Re: autoconf: feature request: test for GCC version


From: R0b0t1
Subject: Re: autoconf: feature request: test for GCC version
Date: Wed, 25 Jul 2018 14:05:14 -0500

On Wed, Jul 25, 2018 at 1:46 PM, Philip Prindeville
<address@hidden> wrote:
>
>
>> On Apr 13, 2011, at 3:59 PM, Eric Blake <address@hidden> wrote:
>>
>> On 04/13/2011 03:49 PM, Philip Prindeville wrote:
>>> It is sometimes useful to be able to detect the compiler version (as in the 
>>> case of GCC 4.2 doing some fairly aggressive optimization that breaks 
>>> fragile code).
>>
>> Thanks for the report.
>>
>>>
>>> How about something like:
>>>
>>> AC_GCC_VERSION(VER, MATCHING-VERSION, [ NON-MATCHING-VERSION ])
>>
>> Unfortunately, I don't think that a macro like this belongs in autoconf.
>> Why not instead follow the autoconf philosophy of feature tests rather
>> than version tests, and specifically compile a problematic program that
>> gets miscompiled by broken compilers and changes OPTIMIZE in that case.
>> For all you know, gcc 4.2 on one machine may have some vendor-specific
>> patches that don't cause the same breakage that you are seeing with
>> out-of-the-box gcc 4.2.  Or, fix your code to be standards-compliant so
>> that undefined code doesn't trip up a valid optimization; and if gcc is
>> still miscompiling your program in your eyes, then report that as a bug
>> to the gcc folks (who will help you either see where your program is
>> non-compliant or will fix gcc to avoid the miscompilation).
>>
>
>
> Well, because I do a lot of cross-compilation and never get to actually run 
> most of the programs…
>

So... to add to this, the vast majority of autoconf tests I see in the
wild are horribly broken and do not support cross compilation. The
ones that do for some reason check the software on the build machine
(as that is all that is available) and use it to infer what the target
machine will support. Running the binaries with qemu-user in a chroot
is an expensive solution in terms of time and not usually viable -
even if you did do this you are testing the features of qemu-user and
the chroot, not the target system.

The philosophy outlined by Mr. Blake doesn't work anymore. There are
an increasing number of systems that are not meant to self-host and
will probably never self-host. In this case it only makes sense to
specify the required features manually or to infer them from program
versions.

Cheers,
     R0b0t1



reply via email to

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