Process binaries within the build directory before stashing to be
relocatable with ORIGIN relative rpaths. This corrects issues with
rpaths being invalid when trying to use the binaries from an unstashed
build directory (e.g. gcc-runtime).
(From OE-Core rev: 34d9f60a8c2e98fdacbb799af11ec015bc5700f4)
Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
warrior only had one gcc so lets be consistent.
This will also reduce our maintenance overhead and we don't build this either
(From OE-Core rev: fa4ecadd980eff95eacd840ba0259f6272daa9aa)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The 'process_multilib_options' function of dejagnu also populates the
'multilib_flags' content from the '--target_board=' arguments. The
'ssh.exp' generated is missing this call ('user.exp' includes it).
(From OE-Core rev: 4d3d7cac012a1f53c61a997615a761a7f25dd33f)
Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a do_check task to implement execution of the gcc component test
suites. The component test suites require execution of compiled programs
on the target.
The implementation provided allows for execution testing against a host
via SSH or within the local build environment using qemu linux-user
execution. The selection of execution is done via the
TOOLCHAIN_TEST_TARGET variable, and configuration of the remote host is
done with the TOOLCHAIN_TEST_HOST, TOOLCHAIN_TEST_HOST_USER and
TOOLCHAIN_TEST_HOST_PORT variables.
By default the do_check task will execute all check targets, this can be
changed by setting MAKE_CHECK_TARGETS to the desired test suite target
(e.g. check-gcc or check-target-libatomic).
(From OE-Core rev: 9d5d680baa91b34dc97641f98856a51d1bb060c1)
Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
gcc's makefile can move files, replacing with the contents "timestamp". This
corrupts the headers and breaks things like the gcc testsuite.
Add in a fix to ensure the headers are not corrupted through their hardlink copies.
(From OE-Core rev: 7e75ed5aec86b94fe7fadbed606619f84a2e58e7)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Correct the 'staging_processfixme' call so that target sysroot and
native sysroot paths are corrected when extracting the stashed build
directory. This is required for 'make check' to work correctly due paths
used in configuration and scripts which point at the native sysroot.
(From OE-Core rev: 2c47ffb65ec16af50112f9c388dc85439c069848)
Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Let the patch trigger based on target triplet instead of passing via
configure, this lets gcc compile for 64bit otherwise it ends up with
libgcc build errors
error: unable to emulate 'TF'
(From OE-Core rev: 2259bf5366a9ff654dfaf15baa5df2d943383ce6)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
when compiling for ppc64, build emits additional
STANDARD_STARTFILE_PREFIX_1 and STANDARD_STARTFILE_PREFIX_2 into
gcc/defaults.h which is not conditional because it really want to
override others with this new value, but it ends up with two definitions
since it gets emitted _after_ the definition this patch moves to
default.h and ends up in duplicate defines.
(From OE-Core rev: 2ad649ee9027011ae7bf6fd95417237b86e394e5)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We had interesting failures where building gcc-cross-powerpc with 5.0 kernel
headers, then building eudev after moving to 5.2 headers failed.
gcc-cross doesn't rebuild when linux-libc-headers changes due to its
listing in SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS. This shouldn't matter but
fixincludes as adding asm-generic/socket.h to its filtered list which
was then replacing the real header with an older version. This mismatch
lead to build failures.
We trust the Linux kernel headers to be ANSI safe so lets just clear out
any headers and trust the originals to be correct.
(From OE-Core rev: f0fcaa88b7b2977c2cb35b060747442ee9ff3dcd)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We put gcclibir to be /usr/lib/<arch>/... and not default
usr/lib/gcc/<arch>, therefore make the include search path also look
into this directory, this should help in finding gcc headers like omp.h
(From OE-Core rev: 121ce09332099ab7ea695a3495daf4f904f69ae5)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Cc: Martin Jansa <martin.jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is a very old change as and be inferred from the name in the comment.
We've since had many changes to pkgdata including separating it
to its own sysroot now so the reasons for this blanket exclusion are
likely long gone.
If the shlib provides were really the problem I'd much rather have
a dedicated variable for that too.
Removing this fixes missing dependencies on nativesdk-libc and other
libs which would then happen automatically.
(From OE-Core rev: 096fa15efbcb704451b2f38ceab36508ef64f07e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
OE does not use the traditional /usr/lib/gcc prefix to store gcc-runtime
it basically is moved into libdir, however some newer files were
installed by newer versions of gcc especially libgomp ( omp.h openacc.h )
into gcclibdir, so we have content in both directories, this confuses
other tools which are trying to guess the gcc installation and its
runtime location, since now we have two directories, the tools either
choose one or other and we get inconsistent behavior, e.g. clang for
aarch64 uses /usr/lib but same clang for riscv64 chose /usr/lib/gcc
This change ensures that OE ends up with single valid location for gcc
runtime files
Move more common bits into common inc file
(From OE-Core rev: e9e5744ba8b0d43c8b874d365f83071ce20bf0a1)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* since
commit b071a1a209556158bcfcc20e3c8bd4b15373767c
Author: Changqing Li <changqing.li@windriver.com>
Date: Tue Jun 18 15:46:56 2019 +0800
gcc-runtime: fix C++ header mapping for n32/x32 tune
gcc-runtime.do_install is failing with:
ln: failed to create symbolic link 'work/aarch64-oemllib32-linux-gnueabi/lib32-gcc-runtime/9.1.0-r0/image/usr/include/c++/9.1.0/arm-oe-linux-gnueabi/bits': No such file or directory
WARNING: exit code 1 from a shell command.
ERROR: Function failed: do_install (log file is located at work/aarch64-oemllib32-linux-gnueabi/lib32-gcc-runtime/9.1.0-r0/temp/log.do_install.31049)
There is only empty directory without the -gnueabi suffix:
work/aarch64-oemllib32-linux-gnueabi/lib32-gcc-runtime/9.1.0-r0/image/usr/include/c++/9.1.0/arm-oe-linux/
and
work/aarch64-oemllib32-linux-gnueabi/lib32-gcc-runtime/9.1.0-r0/image/usr/include/c++/9.1.0/arm-oemllib32-linux-gnueabi/
bits ext
* make sure to create correct directory (with -${TARGET_OS suffix instead of -linux suffix)
before creating the symlinks in it
(From OE-Core rev: 41cbf5dc203ba74b06cb4890e1022f3f02fbd6fd)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The SDK was unable to find the C++ header pieces correctly since it's
using a generic compiler, not one specifically targeting the multilib
vendor prefix and default tune. This adds the right mapping to ensure
SDKs work as expected. And fix problem in below configurations:
multilib configuration 1:
MACHINE="qemumips64"
MULTILIBS ?= "multilib:lib32 multilib:libn32"
DEFAULTTUNE_virtclass-multilib-lib32 ?= "mips"
DEFAULTTUNE_virtclass-multilib-libn32 ?= "mips64-n32"
MULTILIB_GLOBAL_VARIANTS_append = " libn32"
require conf/multilib.conf
ignoring nonexistent directory "<path>/sysroots/mips64-poky-linux/usr/include/c++/8.2.0/mips64-poky-linux/32
multilib configuration 2:
MACHINE="qemumips64"
MULTILIBS = 'multilib:lib64 multilib:lib32'
DEFAULTTUNE = 'mips64-n32'
DEFAULTTUNE_virtclass-multilib-lib64 = 'mips64'
DEFAULTTUNE_virtclass-multilib-lib32 = 'mips32r2'
require conf/multilib.conf
For this configuration:
for target gcc-runtime, need to create symlink like mips64-poly-linux --> mips64-poky-linux-gnu32
for target lib64-gcc-runtime, need to create symlink like mips64-poly-linux/32 --> mips64-pokymllib64-linux
in order to avoid conflict during populate_sdk, create symlink for subfoler bits/ext for target gcc-runtime,
this is ugly, but seems no better way to cover all kinds of configuration.
single lib configuration:
MACHINE="qemumips64"
DEFAULTTUNE = "mips64-n32"
(From OE-Core rev: b071a1a209556158bcfcc20e3c8bd4b15373767c)
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This was added 9 years ago as a workaround for a problem with
gcc 4.5 on mips.
Building webkitgtk works for me without it for qemumips.
Debian also builds webkitgtk for 32/64 bit big/little endian mips
without using this workaround.
(From OE-Core rev: 7af322a995a9385f7f452c2988188de98db300c2)
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
ERROR: libgfortran-9.1.0-r0 do_package: QA Issue: libgfortran:
Files/directories were installed but not shipped in any package:
/usr/lib/gcc/x86_64-poky-linux/9.1.0/include
/usr/lib/gcc/x86_64-poky-linux/9.1.0/include/ISO_Fortran_binding.h
(From OE-Core rev: 8493fe87e241bb7aeb9075683d2e44dd1e2bc334)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These options are not needed on target infact since the defaults would
be good enough for compiler to find the relevant headers and libraries
from compiler runtime
with gcc9 it starts to strip the sysroot from gxx-include-dir which
means it tries to look for gxx headers in localdir
ignoring nonexistent directory "usr/include/c++/9.0.1"
ignoring nonexistent directory "usr/include/c++/9.0.1/arm-yoe-linux-gnueabi"
ignoring nonexistent directory "usr/include/c++/9.0.1/backward"
instead of sysroot
Removing these options make it behave normal
(From OE-Core rev: 2996640fb3577a3c28a22f1e25eae15e8e3d46b1)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When DEBUG_BUILD = "1" added in local.conf, there
comes below build error when "bitbake gcc-sanitizers":
| ./../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c: In function 'elf_is_symlink':
| ../../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c:772:21: error: 'st.st_mode' may be used uninitialized in this function [-Werror=maybe-uninitialized]
| return S_ISLNK (st.st_mode);
After commit[16643b0322 bitbake.conf: Use -Og in DEBUG_OPTIMIZATION]
introduced, "-Og" added to compiler when debug
build enabled.
Per https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00315.html,
the gcc upstream thinks the warning is a false
positive and suggests to use -O2 rather than -Og
or -O1 when compiling that file, so pass -Wno-error
to compiler when -Og is used to silence the error.
(From OE-Core rev: d8d657f082d4a86f93ce810e5d99eb5c93333d8a)
Signed-off-by: Mingli Yu <Mingli.Yu@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Java support was removed in upstream gcc 7.
(From OE-Core rev: 81551871b183f802ce3c1d0c8fb16479d9671a04)
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When we have hard-float ABI enabled, certain tools e.g. llvm/clang
expects the hf version of tuples for crt files from libgcc, therefore
create a symlink to help the cause.
This makes clang work with hard-float defaults on target
(From OE-Core rev: f58cf0d0ff05636a70330c54f7e537f9480674c4)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
libgfortran did not have the GCC exception in the same manner as
libgcc had.
Change-Id: If48ab6e6775da235c8fdd0ca4e835acf1e831252
(From OE-Core rev: 0b4a4b37260e719ae12fb9a8e6556759422bfc92)
Signed-off-by: Santhosh Nadig <santhosn@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This can save configure time since it runs configure multiple times:
$ time bitbake gcc-runtime -cconfigure
60s -> 54s
Saved 6s
(From OE-Core rev: 48cc7179ffeb89adf1ba5212338b958684e43962)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In OE we do not build mutlib like gcc does it by default, this ensures
that mutlilib is virtually disabled for OE, since we hardly use same gcc
to build for multiple ABIs
This fixes cases in SDK where g++ is not able to find standard c++
include headers
(From OE-Core rev: badbeb01dd642d9d647d3760a3ce2aa39c3567da)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We no longer have special "libc" for gcc so we can rely on plain
virtual/libc and reduce the complexity in the dependencies.
(From OE-Core rev: 122217b421f749b5fef52bea44ad6e04bc8f8d3a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Separated out from the previous commit for clarity, this simply drops
all the -inital pieces of gcc which are no longer needed after the
previous commit.
(From OE-Core rev: d84971928b68efddbdb6344b1021d998c9e26adb)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We need a libgcc to build glibc. Tranditionally we therefore build
a non-threaded and non-shared compiler (gcc-cross-initial), then use
that to build libgcc-initial which is used to build glibc which we can
then build gcc-cross and libgcc against.
Firstly, we can drop the glibc dependency from gcc-cross, *if* we make
two changes:
a) specify the minimum glibc version to support in a configure option
b) create a dummy limits.h file so that later when glibc creates one,
the headers structure has support for it. We can do this with a simple
empty file
Once gcc-cross is libc independent, we can use it to build both
libgcc-initial and then later libgcc.
libgcc-initial is tricky as we need to imitate the non-threaded and
non-shared case. We can do that by hacking the threading mode back to
"single" even if gcc reports "posix" and disable libc presence for the
libgcc-intial build. We have to create the dummy limits.h to avoid
compiler errors from a missing header.
glibc will fail to link with libgcc-initial due to a missing "exception
handler" capable libgcc (libgcc_eh.a). Since we know glibc doesn't need
any exception handler, we can safely symlink to libgcc.a.
With those changes, gcc-cross can be used in all places and we only need
one build of gcc for each architecture.
For some reason ifunc was being disabled on mips prior to these changes
but afterwards became enabled but caused assertion failures. This is
therefore disabled until we can debug that.
(From OE-Core rev: 62b7308b8c4d2b439a15a4f7cbc6f823077bb0be)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
libmpx is not supported any longer and infact has been removed
completely from gcc-9, see
1e42d5c637
(From OE-Core rev: 547174fc834273af67a2f7e50a3cf6c8e3b900f4)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For reasons lost in the depths of time, perhaps performane related,
we only have a dependency on libc at packaging time. This is too late,
as demonstrated by a recent build failure on non-IA builds where
the glibc 2.29 upgrade had been removed from the build:
ld: recipe-sysroot/usr/lib/../lib/libstdc++.so: undefined reference to `log@GLIBC_2.29'
libstdc++ should have been rebuilt but had not as the dependency
wasn't present.
Add the missing dependency to avoid this problem (and drop the other
form of dependency which is no longer needed).
(From OE-Core rev: 14c291e1fb6324da46885b69fbd7f01b3c6b053e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We've had gcc 8.2 around for long enough that 7.3 can be removed now.
(From OE-Core rev: 20aea61385e1a53ac245353899277ba20104ed2f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There are four functions using TFmode type (128bit) that isn't
available when building with musl. Move each of them from common
ppc64-fp.c to individual files referenced from t-float128 that used
when ldbl 128 enabled at configure time.
For gcc-7.3 if -mfloat128 is given -mfloat128-type must be given too.
Exclude ibm-ldouble.c when ldbl 128 isn't enabled at config time.
Build and boot tested with musl (no float128) and glibc (float128
and ibm128 on PowerPC64).
(From OE-Core rev: dec8e566810525563b33c2877d10db0a70965d6d)
Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When building for powerpc64 using musl as C library we get preprocessor
macro redefinition errors since gcc-configure-common.inc adds #define
of STANDARD_STARTFILE_PREFIX_1 and STANDARD_STARTFILE_PREFIX_2 to
gcc/defaults.h after ones added by a patch that ensures target gcc
headers included.
Since gcc-configure-common.inc included in every gcc recipe either
directly or indirectly, do_configure task is not disabled/deleted for
any of them (except gcc-source.inc) and there is no precondition that
skips gcc/defaults.h patching in
gcc-configure-common.inc::do_configure_prepend() we can just remove
conflicting parts of mentioned above patch to have single place where
start files prefixes defined in do_configure() task.
(From OE-Core rev: 0622a4168aac627b44547f72fe93589cf1050e42)
Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
By default GCC for ARC is configured with ARC700 CPU.
This means when we don't pass "-mcpu=xxx":
a) Code will be compiled for ARC700
b) Libs will used for ARC700
And if we happen to run on ARCv2 core like ARC HSxx we
won't be able to use target gcc w/o "-mcpu=xxx" which
is not very convenient as we want to build "target" toolchain
but not canadian-cross.
Note the trick here is we set TUNE_PKGARCH in just 2 values,
it is either "arc700" for all ARCompact cores (ARC750 & ARC770)
and "archs" for all ARCv2 cores (ARC HS38 & HS48), see [1].
This gives us usable defaults.
For cross-compilation we use TUNE_CCARGS for fine-tuning depending
on which HW features we have on the current target so that
we may have HW feature A & B or B & C or A & B & C, see [2].
[1] https://github.com/foss-for-synopsys-dwc-arc-processors/meta-synopsys/blob/master/conf/machine/include/tune-arcv2.inc#L4
[2] https://github.com/foss-for-synopsys-dwc-arc-processors/meta-synopsys/blob/master/conf/machine/include/tune-arcv2.inc#L34
(From OE-Core rev: 6d2e44db7ebada41ad1cfc1c98ce9012242ced11)
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Without this the build fails for armv6t targets due to invalid
assembler instructions in thumb mode.
[YOCTO #12929]
(From OE-Core rev: 801141be68e5c754f2cd1d80d13982f037fc03e5)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Passing --with-mpfr and --with-mpc when compiling the cross compiler
appears to be at best unnecessary, and at worst can cause build failures.
Firstly, the paths passed in gcc-cross-canadian are using the undefined
${layout_exec_prefix}. This results in configure passing
-I${STAGING_DIR_HOST}/include twice to the compiler when it's doing its
test builds. This is mostly pointless since that directory doesn't exist
with the default oe-core configuration - the correct path would be
-I${STAGING_DIR_HOST}/usr/include.
The path for mpfr passed in gcc-cross is correct, but unnecessary since it
is just the sysroot default.
I've gone back through the history, and it seems that these lines (or
similar ones) were originally added way back in
8800d8be25 for GCC 4.1.1 in 2006! I asked[1]
if anyone knew why this was necessary but received no response, so I can
only assume that no-one knows.
I've successfully built for various targets with this patch applied and
observed no problems.
[1] http://lists.openembedded.org/pipermail/openembedded-core/2018-September/155971.html
(From OE-Core rev: 2f9f02d5fda9884ccf9ae22ceb00d59b99036a49)
Signed-off-by: Mike Crowe <mac@mcrowe.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
GCC's built-in spec for LD is missing a space after
"--eh-frame-hdr" thus with the next option merged together they
are not understood by LD and so LD fails.
Back-port from upstream GCC, see:
892142379c
(From OE-Core rev: 0757187bdbed3025b022a82dd85ee35dc7b71f1f)
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
