summaryrefslogtreecommitdiffstats
path: root/meta/recipes-devtools/gcc/gcc-multilib-config.inc
Commit message (Collapse)AuthorAgeFilesLines
* gcc-multilib-config: Fix i686 toolchain relocation issuesRichard Purdie2022-09-031-1/+1
| | | | | | | | | | | | | This code wasn't changing the linux.h on i686. Make the entry match that for i586 which was correct. This fixes problems where the wrong dynamic loader path was used by nativesdk-gcc on i686 SDK targets by ensuring SYSTEMLIBS_DIR is replaced by %r in the correct header files. (From OE-Core rev: d30eb681f41bf9e921f7f0d42747fff7a4be9229) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: also relocate the musl loaderRoss Burton2021-08-221-0/+8
| | | | | | | | | Alongside GLIBC and UCLIBC, also relocate the musl loader. (From OE-Core rev: 24c4e01892df1510e5ba64b89a0060f62f2384e6) Signed-off-by: Ross Burton <ross.burton@arm.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Fix nativesdk builds and multilib fixes with gcc 11Richard Purdie2021-08-221-9/+15
| | | | | | | | | | | | | | In newer gcc versions the headers changed locations and our multiconfig and nativesdk tweaks to loader paths wasn't working. The broke buildtools-extended-tarball, particularly on arm. Update to fix this. Ultimately we should dump the gcc specs and check for hardcoded paths. This isn't possible quite yet as this patch doesn't fix the musl ones as we don't use that in mutlilib or nativesdk scenarios at present. (From OE-Core rev: 4ed6505a18ac76c0aa148deabb143214ac0c4552) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Convert to new override syntaxRichard Purdie2021-08-021-1/+1
| | | | | | | | | | | | This is the result of automated script conversion: scripts/contrib/convert-overrides.py <oe-core directory> converting the metadata to use ":" as the override character instead of "_". (From OE-Core rev: 42344347be29f0997cc2f7636d9603b1fe1875ae) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* meta: remove True option to getVar callsJoshua Lock2016-12-161-10/+10
| | | | | | | | | | | | | getVar() now defaults to expanding by default, thus remove the True option from getVar() calls with a regex search and replace. Search made with the following regex: getVar ?\(( ?[^,()]*), True\) (From OE-Core rev: 7c552996597faaee2fbee185b250c0ee30ea3b5f) Signed-off-by: Joshua Lock <joshua.g.lock@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-multilib-config: make aarch64 support multilibRobert Yang2015-11-251-0/+7
| | | | | | | | | | | | | | | | | | | | | Fixed: MACHINE = qemuarm64 require conf/multilib.conf MULTILIBS = "multilib:lib32" DEFAULTTUNE_virtclass-multilib-lib32 = "armv7at-neon" $ bitbake core-image-minimal -cpopulate_sdk WARNING: gcc multilib setup is not supported for TARGET_ARCH=aarch64 WARNING: gcc multilib setup is not supported for TARGET_ARCH=aarch64 [YOCTO #8638] (From OE-Core rev: 9e0cad83eefae4c1a5e5e0334cc1cfdfc1f51057) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-multilib-config: Ensure SDK_ARCH doesn't change target sigsRichard Purdie2015-10-011-0/+1
| | | | | | | | | | | Changing SDKMACHINE (which changes SDK_ARCH) shouldn't cause target task signatures to change. Exclude the dependency on SDK_ARCH for this reason. It only affects nativesdk builds and those already account for SDK_ARCH in the build WORKDIR paths. (From OE-Core rev: dae7c45fac1d877203f173842d43abc4883b808b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-multilib-config: Expand ccargs variableYuanjie Huang2015-09-281-1/+1
| | | | | | | | | | | | | | | | | | The ccargs obtained from get_tune_parameters may not be fully expanded, so that the gcc_multilib_setup function can be confused, and generates invalid MULTILIB_OPTIONS in GCC Makefile fragment, which will break the multilib feature of target gcc. To address problems above, this patch modifies gcc_multilib_setup function to expand ccargs before use. Upstream-Status: Inappropriate [configuration] (From OE-Core rev: 02eddf9a0b89b0cbe0c83d95cedb3431899197d0) Signed-off-by: Yuanjie Huang <yuanjie.huang@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-multilib-config: Adapt mips for mips64 and different gcc versionsRichard Purdie2015-08-011-3/+7
| | | | | | | | | The location of some files for mips varies between gcc 4.9 and 5.2. Ensure that we cover both cases (and allow specified files to be optional). (From OE-Core rev: 5c33b0a752e6168200776da61dee7d4d807ddbb0) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cross-canadian/gcc: Various mips64 fixesRichard Purdie2015-08-011-0/+2
| | | | | | | | | "n32" is a mips64 variant we need to consider when processing the TARGET_OS extensions. Also add the multilib extensions for mips64. (From OE-Core rev: fe26f809aaad5d5d608e841c99b817316c5a59a0) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-multilib-config: Tweak naming of options to match gcc's expectationsRichard Purdie2015-08-011-1/+2
| | | | | | | | | gcc itself does not add the '-' of options to its multilib configuration. We should follow its example. (From OE-Core rev: e742eef3e1016a29f744341c17d1b421d318b40f) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Add support for nativesdk-gccRichard Purdie2015-07-311-9/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | Being able to build a nativesdk gcc is useful, particularly in cases where the host compiler may be of an incompatible version (or a 32 bit compiler is needed). Sadly, building nativesdk-gcc is not straight forward. We install nativesdk-gcc into a relocatable location and this means that its library locations can change. "Normal" sysroot support doesn't help in this case since the values of paths like "libdir" change, not just base root directory of the system. In order to handle this we do two things: a) Add %r into spec file markup which can be used for injected paths such as SYSTEMLIBS_DIR (see gcc_multilib_setup()). b) Add other paths which need relocation into a .gccrelocprefix section which the relocation code will notice and adjust automatically. This patch adds tweaks to the relocation script to handle the new section too. (From OE-Core rev: cd3d874fced2ee4c950d9964d30c0588fd8772e7) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: update i586 TARGET_ARCH tests to also handle i686Andre McCurdy2015-07-081-0/+2
| | | | | | | | (From OE-Core rev: 589bad6e9213136e7f30b4eafb7abfdd10070d1a) Signed-off-by: Andre McCurdy <armccurdy@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Fix gcc-multilib-config comparisonMark Hatle2014-08-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | Fix an issue on a multilib configuration that contains more then 1 multilib. I.e. on MIPS64: DEFAULTTUNE = "mips64" MULTILIBS = "lib32n:mips64_n32 lib32:mips32" While normally you'd use 'libn32', the above is legal. With the startswith code, the system will look to expand the 'lib32' element and find the 'lib32n' instead, and will result in a warning: lib32 doesn't have a corresponding tune. Skipping... (From OE-Core rev: ced919f6013fc0dbb8b8f75f87a8c0a4f416b1fe) Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-multilib: Simply/fix MULTILIB_OPTIONS handlingRichard Purdie2014-07-251-18/+9
| | | | | | | | | | | | | | | | | | | | | | MULTILIB_OPTIONS takes the parameters which trigger a given multilib to be selected. It supports *one* option per multilib, '/' separated. Spaces separate options used to generate additional multilib combinations. Adding in all of CFLAGS to this is therefore clearly a really bad idea but how do we fix things? The best option I've come up with so far is a list of whitelist variables to use to trigger the multilibs. Its populated with the standard multilibs we support, anyone setting up an advanced multilib can populate the variable with the correct trigger parameters. This has the advantage of simplifying the code and allowing us to remove the code filtering blocks since there is no longer option duplication. Testing after this change shows a much improved sdk toolchain functionality. (From OE-Core rev: 29202cd1b9d2e5d56e5b9f7a596e44e229c90492) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: update *LIBC_* linker relocation reglexTing Liu2014-07-191-2/+4
| | | | | | | | | | | | | | * GLIBC_DYNAMIC_LINKER64 reglex does not work for rs6000/linux64.h, update it. * it turns out that UCLIBC_DYNAMIC_LINKER reglex will strip the 32/64 chars from UCLIBC_DYNAMIC_LINKER64/UCLIBC_DYNAMIC_LINKER32, add '\b'. my two PCs: Centos 6.5 (python 2.7.5) and Fedora 13 (python 2.7.3) (From OE-Core rev: a0b408191d64804df1748163060313af31433ac8) Signed-off-by: Ting Liu <ting.liu@freescale.com> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Handle uclibc linker relocation for multilib supportRichard Purdie2014-05-081-1/+10
| | | | | | | | | We need to handle the UCLIBC_* linker variables in the same way as we do the GLIBC_* ones to allow uclibc multilib to work properly. (From OE-Core rev: 025ec5958b7e1fd71caa0079ec3c573126b30886) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: enable multilib setup for powerpc64 archAlexandru-Cezar Sardan2014-04-041-0/+2
| | | | | | | (From OE-Core rev: 99fadf2ff9f4379121fde6477383e7574519fba4) Signed-off-by: Alexandru-Cezar Sardan <alexandru.sardan@freescale.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: changed multilib options handlingAlexandru-Cezar Sardan2014-04-011-4/+20
| | | | | | | | | | | | | Duplicate parameters in the tune args are repeated in the MULTILIB_OPTIONS variable. This leads to incorrect configurations if the order of the parameters is bad. (Eg. "mhard-float m32/mhard-float m64" leads to an incorrect config) This patch finds the common parameters and removes the duplicates. (From OE-Core rev: 90dc31c24adfa8e916a9c475ae1afc58ad179dfb) Signed-off-by: Alexandru-Cezar Sardan <alexandru.sardan@freescale.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* meta: Don't use deprecated bitbake APIRichard Purdie2013-09-011-1/+1
| | | | | | | | | | These have been deprecated for a long time, convert the remaining references to the correct modules and prepare for removal of the compatibility support from bitbake. (From OE-Core rev: 6a39835af2b2b3c7797fe05479341d71a3f3aaf6) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-cross-canadian: enable multilib supportConstantin Musca2013-02-111-1/+2
| | | | | | | (From OE-Core rev: ee7331e3e7d0b38f3e19ccf7e394537f5f653a22) Signed-off-by: Constantin Musca <constantinx.musca@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: enable multilib for target gccConstantin Musca2013-02-011-0/+190
- add a task to setup multilib configuration for target gcc - this commit adapts Nitin Kamble's work to gcc 4.7 - use a hash for storing arch-dependent multilib options - patch gcc in order to use the multilib config files from the build directory Tests: root@qemux86-64:~# gcc -m64 t.c -o t root@qemux86-64:~# file t t: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, not stripped root@qemux86-64:~# ./t Hello World ! root@qemux86-64:~# gcc -m32 t.c -o t root@qemux86-64:~# file t t: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, not stripped root@qemux86-64:~# ./t Hello World ! [YOCTO #1369] (From OE-Core rev: b26819c85881e82ee1b5c68840011e78c321f18e) Signed-off-by: Constantin Musca <constantinx.musca@intel.com> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>