11587 2017-05-27 19:46:21 +0000 add "fence flag" to cross toolchain 2017-08-30 23:24:06 +0000 1 1 7 Build System, Metadata & Runtime OE-Core devtools / tool chain 2.4 x86 Multiple RESOLVED WORKSFORME Medium+ enhancement 2.4 M3 1 brian.avery juro.bystricky meta.mr.watcher meta.watcher randy.macleod --- --- No (bug/feature does not impact docs) oldest_to_newest 73541 0 brian.avery 2017-05-27 19:46:21 +0000 Suppose we have an autotools project that looks like it is using the cross compiler but is actually reaching out to the host compiler instead. On an x86-64 build, you may not even notice. Option: add a "fence flag" like --using-cross-compiler to the cross compiler we build and add it to the default flags. host gcc will die on this, allowing us to catch cross contamination. This is also part of the binary reproducibility push. 73611 1 juro.bystricky 2017-06-01 15:42:47 +0000 We already have a GCC flag in poky/oe-core that is pretty much guaranteed not to exist in the host GCC (we patch the GCC to get this functionality). So if all we want is the host GCC to barf when it is invoked by a mistake, we can use the flag ffile-prefix-map. Something like this should have no additional side effects (remapping a string into itself): -ffile-prefix-map=string=string 73615 2 juro.bystricky 2017-06-01 15:50:17 +0000 If the overall goal is to achieve binary reproducibility, then the recipes should use the flag -file-prefix-map anyway. It allows remapping the string as specified by __FILE__ macro. The purpose is to get rid off the host build system references from __FILE__. For example, calling GCC with : -ffile-prefix-map=${S}=/kernel-source/ will replace the (to be embedded) string /​data/​master/​build-​repro/​tmp/​work-​shared/​qemux86/​kernel-​source/​drivers/​media/​v4l2-​core/​videobuf2-​core.​c with a reproducible value: /kernel-source/drivers/media/v4l2-core/videobuf2-core.c. 73616 3 juro.bystricky 2017-06-01 15:52:04 +0000 see http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=jurob/reproducible_binaries&id=5bd62e7b2f5f61c26ea0ca679c2d4db65e376102 73624 4 randy.macleod 2017-06-01 19:38:03 +0000 Since Hongxu has submitted this patch to gcc and opened a gcc bug [1] as well, the flag -ffile-prefix-map=from-string=to-string *could* show up in the version of gcc used on the host. It's not clear what will be implemented [2]. An explicit flag that is only present if the compiler was configured as a cross-compiler would be better. Playing devil's advocate, I'll point out that this only catches the common case of a single toolchain being installed on the host. I don't think that we can or should make this impervious to arbitrary build host configurations with, for example, additional cross-compilers available. [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70268 [2] https://reproducible-builds.org/specs/build-path-prefix-map/ 73631 5 juro.bystricky 2017-06-01 22:23:59 +0000 (In reply to comment #4) > Since Hongxu has submitted this patch to gcc and opened a gcc bug [1] as > well, the flag -ffile-prefix-map=from-string=to-string *could* show up in > the version of gcc used on the host. It's not clear what will be implemented > [2]. > > An explicit flag that is only present if the compiler was configured as a > cross-compiler would be better. > > Playing devil's advocate, I'll point out that this only catches the common > case of a single toolchain being installed on the host. I don't think that > we can or should make this impervious to arbitrary build host configurations > with, for example, additional cross-compilers available. > > [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70268 > [2] https://reproducible-builds.org/specs/build-path-prefix-map/ Yes, there is a non-zero possibility the host compiler supports the flag. This can be tested by querying the gcc: $ gcc -Q --help=joined | grep ffile-prefix-map I suspect the patch, if accepted, will be not backported and will end up in gcc 7.x . My point was, that in order to achieve binary reproducibility (which was an implied objective here), they should have used the flag anyway. If the host gcc dies in the process, even better. But I will come up with a gcc-cross specific/unique flag patch as well. 75124 6 juro.bystricky 2017-07-18 22:48:05 +0000 sent a patch to the mailing list: http://lists.openembedded.org/pipermail/openembedded-core/2017-July/139806.html 75145 7 juro.bystricky 2017-07-19 17:17:35 +0000 Implemented as a new warning flag in GCC "Wnot-cross-compiler". In cross-compiler it does absolutely nothing, the warning will be triggered if used not in cross-compiler. It can be used to force an error when used as host compiler: -Wnot-cross-compiler -Werror=not-cross-compiler If the host uses (unpatched) GCC, it will also generate an error: gcc -Wnot-cross-compiler hello_world.c gcc: error: unrecognized command line option ‘-Wnot-cross-compiler’ So far the feedback from the mailing list is not very positive, the concern seems to be that if the host compiler is not GCC, it MAY silently ignore any unknown command line options. 76369 8 juro.bystricky 2017-08-30 23:24:06 +0000 The patch was sent to the mailing list. It does what it is supposed to do. The final verdict regarding inclusion has not been done yet. For now, I am closing this as RESOLVED/WORKSFORME. The ticket can be re-opened if needed.