[OE-core] [PATCH] gcc-7.inc: add new warning "Wnot-cross-compiler"

Khem Raj raj.khem at gmail.com
Thu Jul 20 18:51:27 UTC 2017


On Thu, Jul 20, 2017 at 12:38 PM, Brian Avery <avery.brian at gmail.com> wrote:
>
>
> On Wed, Jul 19, 2017 at 6:35 PM, Khem Raj <raj.khem at gmail.com> wrote:
>>
>> On Wed, Jul 19, 2017 at 7:26 PM, Andre McCurdy <armccurdy at gmail.com>
>> wrote:
>> > On Wed, Jul 19, 2017 at 2:57 PM, Bystricky, Juro
>> > <juro.bystricky at intel.com> wrote:
>> >>> precisely, the problem is that some host compiler may silently ignore
>> >>> unknown warnings and some host may not be using gcc as default system
>> >>> compiler at all e.g. mageia distro and may be more in future.
>> >>
>> >> Yes, it does not nor it attempts to solve all toolchain issues.
>> >> The expectation is that a compiler will choke on an unrecognized
>> >> option.
>> >> For example, gcc will do the following:
>> >>
>> >> $ gcc -Wnot-cross-compiler hello_world.c
>> >> gcc: error: unrecognized command line option ‘-Wnot-cross-compiler’
>> >>
>> >> As for non-gcc compilers: yes, they may silently ignore unrecognized
>> >> options
>> >> (which IMHO is just wrong). In that case the new options does not work
>> >> as intended,
>> >> but it does no harm either.
>> >> Anyway, the intended use was to add something like this a .conf file:
>> >>
>> >> TARGET_CC_ARCH_append_class-target = " -Wnot-cross-compiler
>> >> -Werror=not-cross-compiler"
>> >
>> > Personally, I think we already try to pass too much via CC or the
>> > compiler command line (e.g. -fdebug-prefix-map=XXX). Has there ever
>> > been any thought of OE providing a toolchain wrapper, which could pass
>> > these kinds of housekeeping options to the underlying toolchain while
>> > keeping build logs clean and without the worry that CC, CFLAGS, etc
>> > get ignored or clobbered by a custom Makefile somewhere?
>>
>> we could do it by providing customized spec file
>> but this will not be good for external toolchains
>> --
>
>
> I understand that it will only addresses the case where your target = host,
> though as Ross points out this can apply to more than x86.
>
> I also get that it will not help if the host compiler just eats the warning
> rather than erroring.


>
> However, there are actual cases where this is an issue and I only noticed it
> because I happened to be building on an old gcc version that choked on some
> new flags.
>
> I think a customized spec file could be an even better approach, but in the
> meantime, it seems like this would help and could be added to distributions
> that want it (in an overridable way, so you can turn them off in config if
> you are using an external toolchain).

I would suggest to run it via gcc mailing lists.

>
> Also, it doesn't cause harm unless the distro or recipe decides to turn it
> on. Very Hippocratic compliant!

it does cause harm, by making the behaviour inconsistent and highly dependent
upon build host.



More information about the Openembedded-core mailing list