Created attachment 528274 [details, diff] Patch fixing the environment variables meson gets the build flags from the environment. When cross compiling it will get the host flags from the cross file. The ebuild was not passing the correct build flags when cross compiling. By using tc-env_build the build environment flags are set when calling meson. This results in not mixing host and build flags: Example output: Native C compiler: x86_64-pc-linux-gnu-clang (clang 7.0) Appending CFLAGS from environment: '-O1 -pipe' Appending LDFLAGS from environment: ' ' Appending CPPFLAGS from environment: ' ' Cross C compiler: armv7a-cros-linux-gnueabi-clang (clang 7.0) Host machine cpu family: arm Host machine cpu: armv7a Target machine cpu family: arm Target machine cpu: armv7a Build machine cpu family: x86_64 Build machine cpu: x86_64 tc-env_build does not seem to load the actual build flags, but it's better than using host flags as build flags. Patch attached.
I tested this, and for native (non-cross) builds this change leaves CC/CXX/etc unset in the environment. That's not good. For a native build, we still need to have CC=${CHOST}-gcc by default. This ensures that ccache isn't automagically enabled by meson, and makes sure the right compiler is used on remote nodes if distcc is in use.
Oh, interesting. I guess I assumed CC/CXX/etc were set by portage. I printed the env for the non-cross case and I can see CC/CXX, etc set: CBUILD=x86_64-pc-linux-gnu CC=x86_64-pc-linux-gnu-clang CCACHE_DISABLE=1 CDEFINE_amd64=__x86_64__ CDEFINE_x86=__i386__ CFLAGS=-O2 -pipe CFLAGS_x86=-m32 CHOST=x86_64-pc-linux-gnu Are you saying that the environment variables aren't always set? Shouldn't portage take care of that? The default src_configure function just calls ./configure without exposing any other variables. Why is this any different?
(In reply to Raul Rangel from comment #2) > Are you saying that the environment variables aren't always set? No, portage does not automatically set variables like CC. I suspect you have CC=x86_64-pc-linux-gnu-clang in make.conf or some similar config file. > Shouldn't portage take care of that? The default src_configure function just calls ./configure without exposing any other variables. Why is this any different? Nope, Portage doesn't take care of it, and never has to my knowledge. The default src_configure function calls econf, which calls ./configure --host="${CHOST}". autoconf then looks for "$HOST-gcc" if CC is unset in the environment. So this just automatically works for autoconf-based build systems. For other build systems, we generally have to use toolchain-funcs.eclass to get the compiler variables set appropriately. That's why meson.eclass was doing those "local -x CC=$(tc-getCC)" calls.
Ah, thanks for the explanation. Would it make sense to have something like tc-env_build but that sets the host vars? i.e., tc-env_host() { AR=$(tc-getAR) \ AS=$(tc-getAS) \ CC=$(tc-getCC) \ CPP=$(tc-getCPP) \ CXX=$(tc-getCXX) \ LD=$(tc-getLD) \ NM=$(tc-getNM) \ PKG_CONFIG=$(tc-getPKG_CONFIG) \ RANLIB=$(tc-getRANLIB) \ "$@" } So then meson can look like: if tc-is-cross-compiler; then tc-env_build "$@" || die else tc-env_host "$@" || die fi
So I think vapier has the right idea. We should always use tc-env_build. https://chromium-review.googlesource.com/c/chromiumos/overlays/portage-stable/+/1028220/2/eclass/meson.eclass#222 This requires fixing tc-export_build_env. If we are cross compiling it should keep the same behavior. If we are not cross compiling we should set BUILD?_FLAGS = ?FLAGS. This way when tc-env_build sets ?FLAGS, it's a noop. The meson eclass then just has: tc-env_build "$@" || die
(In reply to Raul Rangel from comment #5) That makes sense to me. We'll need to run that change by the toolchain project. Please create a new bug/patch and I can send it their way.
I can file a bug/patch. In the mean time, in order to unblock this bug can I just do a tc-export AR AS CC CPP CXX LD NM PKG_CONFIG RANLIB in the non-cross case?
Yes, that should be fine.
Created attachment 529282 [details, diff] Patch rebased on #654424
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c8570bc0e2618e502c2fdab7ff972786a12899e0 commit c8570bc0e2618e502c2fdab7ff972786a12899e0 Author: Raul E Rangel <rrangel@chromium.org> AuthorDate: 2018-04-23 16:15:59 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2018-05-05 20:15:55 +0000 meson.eclass: Don't mix host *FLAGS with build *FLAGS meson gets the build flags from the environment. When cross compiling it will get the host flags from the cross file. The ebuild was not passing the correct build flags when cross compiling. By using tc-env_build the build environment flags are set when calling meson. This results in not mixing host and build flags: Example output: Native C compiler: x86_64-pc-linux-gnu-clang (clang 7.0) Appending CFLAGS from environment: '-O1 -pipe' Appending LDFLAGS from environment: ' ' Appending CPPFLAGS from environment: ' ' Cross C compiler: armv7a-cros-linux-gnueabi-clang (clang 7.0) Host machine cpu family: arm Host machine cpu: armv7a Target machine cpu family: arm Target machine cpu: armv7a Build machine cpu family: x86_64 Build machine cpu: x86_64 tc-env_build does not seem to load the actual build flags, but it's better than using host flags as build flags. See https://bugs.gentoo.org/653902 for upstream patch BUG=b:78351764 BRANCH=none TEST=emerge-grunt and verified mosys runs Change-Id: I802b58cb089b27b9253a034ac00dd183e0f1955a Signed-off-by: Raul E Rangel <rrangel@chromium.org> Closes: https://bugs.gentoo.org/653902 eclass/meson.eclass | 29 +++++++---------------------- 1 file changed, 7 insertions(+), 22 deletions(-)
