[OE-core] [PATCH] gcc-7.inc: add new warning "Wnot-cross-compiler"
Brian Avery
avery.brian at gmail.com
Thu Jul 20 16:38:07 UTC 2017
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).
Also, it doesn't cause harm unless the distro or recipe decides to turn it
on. Very Hippocratic compliant!
-b
an intel employee
trivia - turns out "first, do no harm" isn't actually in the Hippocratic
Oath, my mistake! https://en.wikipedia.org/wiki/Hippocratic_Oath
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20170720/822e872b/attachment-0002.html>
More information about the Openembedded-core
mailing list