linux/poky.git/meta/recipes-devtools/gcc/gcc-cross.inc, branch 2.7_M2

recipes: Drop virtual/libc-for-gcc

2018-12-26T11:19:54+00:00

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

gcc: Drop the -initial versions of the compiler

2018-12-26T11:19:54+00:00

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

gcc: Drop gcc-cross-initial and use gcc-cross instead

2018-12-26T11:19:54+00:00

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

gcc: Remove unnecessary --with-mpfr and --with-mpc when cross compiling

2018-10-09T18:04:02+00:00

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 8800d8be25295dd7c7d84dde62c3be4df8e43346 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 Signed-off-by: Richard Purdie

newlib: Adds newlib and libgloss recipes

2018-06-15T16:56:24+00:00

Newlib is a C library that is intended to be used on embedded systems. It is a conglomeration of several library parts, all under free software licenses that make them easily usable on embedded products. Newlib provides a C library alternative that can run on baremetal, mainly for resource constrained devices. Libgloss is the BSP part of the C library, which can be easily modified to port for new hardware platforms. (From OE-Core rev: fe490ff829440b94124317759d856e2e2daf5047) Signed-off-by: Alejandro Enedino Hernandez Samaniego Signed-off-by: Richard Purdie

gcc-cross: Fix linker and fortran symlinks

2017-07-17T13:01:38+00:00

If we used -fuse-ld gcc option, then it does not work ending in collect2: fatal error: cannot find 'ld' compilation terminated. This is because we are not creating proper symlinks for BFD and Gold linker in gcc installation Secondly, we end up with dangling fortran compiler symlinks if fortran is not enabled when confguring gcc, therefore create these symlinks only when fortran support is enabled in gcc (From OE-Core rev: f84614c082406287e608860741a82edd2f3c9bca) Signed-off-by: Khem Raj Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

gcc: Add recipes for gcc-7

2017-06-14T09:23:27+00:00

Switch default compiler to gcc 7 (From OE-Core rev: 03bb12008891cf1a023aaddb6547da6d41d0cab0) Signed-off-by: Khem Raj Signed-off-by: Richard Purdie

bitbake.conf: Add COMPONENTS_DIR for ${STAGING_DIR}-components

2017-05-11T15:55:59+00:00

The path to where to install and find the sysroot components is used in many places. This warrants it to get its own variable. (From OE-Core rev: 70a84b525470f72339568409daf84845904e4cab) Signed-off-by: Peter Kjellerstedt Signed-off-by: Richard Purdie

recipes/*-cross recipes: ignore TARGET_ARCH sstate hash

2017-04-12T14:09:58+00:00

"yocto-compat-layer.py --machines" showed that shared packages like gcc-cross-powerpc64 have a sstate signature that depends on TUNEFLAGS. As a result, there are unnecessary rebuilds and potential conflicts in a multiconfig. That's due to the way how TARGET_ARCH is set. Richard Purdie suggested setting TARGET_ARCH[vardepvalue] as fix, which works. It would be shorter to do that in cross.bbclass instead of repeating the relevant line in different recipes, but Richard was concerned about potential side-effects in other usages of cross.bbclass. TARGET_GOARM as used in go.inc is still causing signature differences for go-cross-powerpc64 and machines b4420qds-64b and p5020ds-64b. This needs further investigation. (From OE-Core rev: 39bfa0dd3237cbca47e7fca1075d521f9d073f25) Signed-off-by: Patrick Ohly Signed-off-by: Richard Purdie

gcc-cross: Avoid races with gcc_stash_builddir

2017-02-23T20:49:49+00:00

Its sad we need to do this but do_install and do_populate_sysroot appear to change the files in ${B} and this breaks if something works in parallel like gcc_stash_builddir. We've seen a few too many race errors on the autobuilder which appear to be from this so make things run in sequence deterministically for now. An example failure was this from do_populate_sysroot whilst stash_builddir was running in parallel: ERROR: gcc-cross-initial-arm-6.3.0-r0 do_populate_sysroot: split_and_strip_files: 'file /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-arm-lsb/build/build/tmp/work/x86_64-linux/ gcc-cross-initial-arm/6.3.0-r0/sysroot-destdir/home/pokybuild/yocto-autobuilder/yocto-worker/ nightly-arm-lsb/build/build/tmp/work/x86_64-linux/gcc-cross-initial-arm/6.3.0-r0/recipe-sysroot-native/ usr/bin/arm-poky-linux-gnueabi.gcc-cross-initial-arm/arm-poky-linux-gnueabi-gcov' failed Exception: subprocess.CalledProcessError: Command '('patchelf-uninative', '--set-interpreter', '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-arm-lsb/build/build/tmp/sysroots-uninative/ x86_64-linux/lib/ld-linux-x86-64.so.2', '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-arm-lsb/ build/build/tmp/work/x86_64-linux/gcc-cross-initial-arm/6.3.0-r0/sstate-build-populate_sysroot/ recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi.gcc-cross-initial-arm/arm-poky-linux-gnueabi-gcov')' returned non-zero exit status 1 Subprocess output: missing section headers (From OE-Core rev: 75b76eb08c7e344142f0326605aeb6b24e61e38e) (From OE-Core rev: 7265e99d0b4b662ca7f23d480f2845a309ac57fc) Signed-off-by: Richard Purdie