host-gcc: exclude -lgcc to fix -mx32 [qemu_]x86_64 regression

PR #9522 series ending with commit c2c9265b7d ("tests: cmsis: Disable
two cmsis portability tests on x86_64") added -mx32 support for the
x86_64 ARCH and qemu_x86_64. While this was implemented in
"compiler/gcc/target.cmake" as fall back from cross-compilation to the
host compiler, it worked with a direct ZEPHYR_TOOLCHAIN_VARIANT=host
too.

Later, -lgcc was added to "compiler/host-gcc/target.cmake" by PR #12674
to fix the -m32 x86 build. This broke the x86_64 build when using
ZEPHYR_TOOLCHAIN_VARIANT=host because even "multilib" packages usually
don't feature the -mx32 version of libgcc.

Fix this by excluding -lgcc in compiler/host-gcc/target.cmake just like
compiler/gcc/target.cmake always did for x86_64.

Signed-off-by: Marc Herbert <marc.herbert@intel.com>
This commit is contained in:
Marc Herbert 2019-01-28 16:15:00 -08:00 committed by Anas Nashif
commit e526a2b80a
3 changed files with 31 additions and 13 deletions

View file

@ -17,6 +17,8 @@ find_program(CMAKE_NM ${CROSS_COMPILE}nm PATH ${TOOLCHAIN_HOME} NO_
# x86_64 should pick up a proper cross compiler if one is provided,
# but falling back to using the host toolchain is a very sane behavior
# too.
# As an alternative to this fall back try ZEPHYR_TOOLCHAIN_VARIANT=host
# directly.
if(CONFIG_X86_64)
if(CMAKE_C_COMPILER STREQUAL CMAKE_C_COMPILER-NOTFOUND)
find_program(CMAKE_C_COMPILER gcc )

View file

@ -9,10 +9,19 @@ find_program(CMAKE_RANLILB ranlib )
find_program(CMAKE_READELF readelf)
find_program(CMAKE_GDB gdb )
set(CMAKE_ASM_FLAGS -m32 )
set(CMAKE_C_FLAGS -m32 )
set(CMAKE_CXX_FLAGS -m32 )
set(CMAKE_SHARED_LINKER_FLAGS -m32 ) # unused?
# -march={pentium,lakemont,...} do not automagically imply -m32, so
# adding it here.
# There's only one 64bits ARCH (actually: -mx32). Let's exclude it to
# avoid a confusing game of "who's last on the command line wins".
# Maybe the -m32/-miamcu FLAGS should all be next to -march= in the
# longer term?
if(NOT CONFIG_X86_64)
set(CMAKE_ASM_FLAGS -m32 )
set(CMAKE_C_FLAGS -m32 )
set(CMAKE_CXX_FLAGS -m32 )
set(CMAKE_SHARED_LINKER_FLAGS -m32 ) # unused?
endif()
if(CONFIG_CPLUSPLUS)
set(cplusplus_compiler g++)
@ -28,19 +37,25 @@ else()
endif()
find_program(CMAKE_CXX_COMPILER ${cplusplus_compiler} CACHE INTERNAL " " FORCE)
# This libgcc code is partially duplicated in compiler/*/target.cmake
execute_process(
COMMAND ${CMAKE_C_COMPILER} ${CMAKE_C_FLAGS} --print-libgcc-file-name
OUTPUT_VARIABLE LIBGCC_FILE_NAME
OUTPUT_STRIP_TRAILING_WHITESPACE
)
assert_exists(LIBGCC_FILE_NAME)
# The x32 version of libgcc is usually not available (can't trust gcc
# -mx32 --print-libgcc-file-name) so don't fail to build for something
# that is currently not needed. See comments in compiler/gcc/target.cmake
if (NOT CONFIG_X86_64)
# This libgcc code is partially duplicated in compiler/*/target.cmake
execute_process(
COMMAND ${CMAKE_C_COMPILER} ${CMAKE_C_FLAGS} --print-libgcc-file-name
OUTPUT_VARIABLE LIBGCC_FILE_NAME
OUTPUT_STRIP_TRAILING_WHITESPACE
)
assert_exists(LIBGCC_FILE_NAME)
# While most x86_64 Linux distributions implement "multilib" and have
# 32 bits libraries off the shelf, things like
# "/usr/lib/gcc/x86_64-linux-gnu/7/IAMCU/libgcc.a" are unheard of.
# So this does not support CONFIG_X86_IAMCU=y
LIST(APPEND TOOLCHAIN_LIBS gcc)
# So this fails CONFIG_X86_IAMCU=y with a "cannot find -lgcc" error which
# is clearer than "undefined reference to __udivdi3, etc."
LIST(APPEND TOOLCHAIN_LIBS gcc)
endif()
# Load toolchain_cc-family macros
# Significant overlap with freestanding gcc compiler so reuse it

View file

@ -9,6 +9,7 @@ set(arch_list
riscv32
posix
x86
x86_64
xtensa
)