On Wed, Jul 19, 2017 at 6:35 PM, Khem Raj <raj.k...@gmail.com> wrote:
> On Wed, Jul 19, 2017 at 7:26 PM, Andre McCurdy <armccu...@gmail.com> > wrote: > > On Wed, Jul 19, 2017 at 2:57 PM, Bystricky, Juro > > <juro.bystri...@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
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
