summaryrefslogtreecommitdiffstats
path: root/meta/recipes-devtools/gcc/gcc-configure-common.inc
Commit message (Collapse)AuthorAgeFilesLines
* gcc/libtool/perl: Fix various path to sed-native problemsRichard Purdie2013-09-261-0/+1
| | | | | | | | | | | | | | | | | | | | If sed-native is built before these programs, hardcoded paths to sed-native can end up in scripts and other parts of the system which may cause issues if they are later used from sstate and sed-native is not installed. To avoid this, this patch changes the global site configuration to specify that plain "sed" is fine to be used. We need to spell this out for gcc since it doesn't see the site files since we don't autoreconf it. We can remove the values from libtool. We tell perl to use "/bin/sed" since it requires a path and the system sed should be just fine for it. [YOCTO #4971] (From OE-Core rev: 2ec171cb188601bf18c6c2895870907024b1c52a) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: enable multilib for target gccConstantin Musca2013-02-011-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | - 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>
* gcc-configure-cross: factor out --enable-threads argument into ${GCCTHREADS}Phil Blundell2012-09-261-1/+2
| | | | | | | | | | | This allows BSPs for architectures with no thread support to set (for example) "GCCTHREADS=no" without having to override all the other configure parameters. (From OE-Core rev: 6bb0d37529a82b953d374f2d76c2412d7cee587b) Signed-off-by: Phil Blundell <pb@pbcl.net> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-configure-common.inc: use --with-long-double-128 on powerpc to comply ↵Matthew McClintock2012-07-111-0/+4
| | | | | | | | | with ABI (From OE-Core rev: 243539efec94e79dade2525d0ab3586eea48c529) Signed-off-by: Matthew McClintock <msm@freescale.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: fix collect2 host contamination problem properlyRichard Purdie2012-07-051-4/+5
| | | | | | | | | | | | | We added the autoconf cache line a while back to ensure that configure doesn't poke into some hardcoded host paths looking for things it shouldn't. Applying it as part of do_configure wasn't getting it to the do_compile tasks where much of the configure scripts are run by gcc. This changes it to a simple export to ensure it reaches the places it needs to and truly gets rid of the cross compile badness messages from the logs. (From OE-Core rev: af58d5c3a5c5e632aa20b1d007d47dbbfb4ed6e6) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-4.6, gcc-4.7: Add support for building mips64 cross compilerKhem Raj2012-05-211-0/+4
| | | | | | | | | Defaults to n64 ABI (From OE-Core rev: 253f1f3aebd1a90c55efcc6d1f585204e7f3c371) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-configure-common.inc: Use libc-uclibc overrideKhem Raj2012-04-301-3/+1
| | | | | | | | | Its better than duplicating the overrides (From OE-Core rev: 7159dad19f8cfd3e7e95523da63e91370744da7f) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-configure: Render --with-local-prefix harmlessKhem Raj2012-04-301-0/+1
| | | | | | | | | | | | | this option by default points to /usr/local no matter what so we cant let it sit on sidelines otherwise it will access host machine's /usr/local which may not be desired. So disable this option. This also helps in making gcc's shared state more consistent (From OE-Core rev: eee3658366e1ae9d3e429b3d3c968938d8d0f00e) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-configure: Pass distinct target flagsKhem Raj2012-04-301-0/+4
| | | | | | | | | | | | | | | | | When building gcc-cross-canadian libgcc is built using headers from gcc-crosssdk and not the target sysroot because we do not pass proper CFLAGS for target bits so it ends up using CFLAGS that were meant for compiling canadian gcc itself. It does not show up as a problem when building SDK with eglibc because eglibc-nativesdk and eglibc have identical headers. The problem shows up clearly when you try to build uclibc based meta-toolchain since then nativesdk libc and target libc are different (From OE-Core rev: 0e904103e9bd7fdb31bfcc129067511f9f45701b) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-configure-common.inc: Stop gcc looking at build system pathsRichard Purdie2012-04-151-0/+4
| | | | | | | | | | | | | | | | | | | There were puzzling failures when you make a force recompile of any gcc component. The error was in do_configure with cross-compilation badness being detected in config.log files. gcc is different in that many of the config.log files are generated during the do_compile phase. This means this host contamination issue has always been present but only shows up on a rebuild. The fix is to force the appropriate configuration variable to "none required" then gcc won't look in the bad locations. [YOCTO #2279] (From OE-Core rev: e7135f14f3ef37f93f5c28b319464f3d6dd9b8da) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* meta: Convert getVar/getVarFlag(xxx, 1) -> (xxx, True)Richard Purdie2012-03-051-1/+1
| | | | | | | | | | | | Using "1" with getVar is bad coding style and "True" is preferred. This patch is a sed over the meta directory of the form: sed \ -e 's:\(\.getVar([^,()]*, \)1 *):\1True):g' \ -e 's:\(\.getVarFlag([^,()]*, [^,()]*, \)1 *):\1True):g' \ -i `grep -ril getVar *` Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Quoting fixesRichard Purdie2012-02-261-1/+1
| | | | | | | | | We have various variables which are either not quoted at all or are half quoted. This patch fixes the bad exmaples so everything is consistent. (From OE-Core rev: 30253358f5e76fb7b25be27198b4c125e0dbdf2c) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Ensure that the shared source directory shared the same sstate hashesRichard Purdie2012-01-231-15/+0
| | | | | | | | | | | | | | | | | | | | | | The fetch/unpack/patch/headerfix tasks are shared and hence their sstate hashes should also match. Sadly this is not the case since: a) gcc-runtime applies an additional patch b) The do_headerfix task was missing from libgcc c) The do_headerfix task is a shell task and hence depends on all exported variables which can vary between cross and target recipes. To fix this, the patch moves the patch to the common code, adds the headerfix task to a common include file and disabled shell dependencies on the do_headerfix task since its clear in this case we don't need thsoe dependencies since we just call sed. With this patch applied, all these recipes now share common sstate checksums. (From OE-Core rev: 2c4569801a710f34a695b8d2a0ee7fc127fb34e4) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Introduce multiarch DISTRO_FEATUREJulian Pidancet2011-11-291-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch introduces a distro feature which enables gcc to produce both 32bit and 64bit code, and enables binutils to operate on both 32bit and 64bit binaries. It differs from multilib toolchains in that it does not require to compile a version of the libc for each architecture variant. However, the code produced for the secondary architecture will not be linkable against the libc. v2: - Renamed the feature name from "biarch" to "multiarch". The GCC installation manual claims that the mips-linux can be made a tri-arch compiler (http://gcc.gnu.org/install/configure.html) - For x86_64, the compiler is made bi-arch by default, so nothing has to be done in particular. - I analyzed the gcc/config.gcc from GCC sources and added in this patch all the architectures that could be made biarch with the version of gcc currently used in OE, which are powerpc, and sparc, in addition to x86. mips and s390 will probably be supported in future versions of gcc. For x86 and sparc, only the --enable-targets=all option is valid to make this work (this option doesn't have any other side effects than making the compiler bi-arch). For powerpc, I used the --enable-targets=powerpc64 option (although 'all' also works). Note: - Untested on powerpc and sparc. But I believe it works the same as with x86. - gcc in meta-toolchain is also made multiarch. (From OE-Core rev: 99e295ef30ba02db3966c66619807c037ef5089f) Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Convert to use direct access to the data store (instead of bb.data.*Var*())Richard Purdie2011-11-101-1/+1
| | | | | | | | | | | | | | | | | This is the result of running the following over the metadata: sed \ -e 's:bb.data.\(setVar([^,()]*,[^,()]*\), *\([^ )]*\) *):\2.\1):g' \ -e 's:bb.data.\(setVarFlag([^,()]*,[^,()]*,[^,()]*\), *\([^) ]*\) *):\2.\1):g' \ -e 's:bb.data.\(getVar([^,()]*\), *\([^(), ]*\) *,\([^)]*\)):\2.\1,\3):g' \ -e 's:bb.data.\(getVarFlag([^,()]*,[^,()]*\), *\([^(), ]*\) *,\([^)]*\)):\2.\1,\3):g' \ -e 's:bb.data.\(getVarFlag([^,()]*,[^,()]*\), *\([^() ]*\) *):\2.\1):g' \ -e 's:bb.data.\(getVar([^,()]*\), *\([^) ]*\) *):\2.\1):g' \ -i `grep -ril bb.data *` (From OE-Core rev: b22831fd63164c4db9c0b72934d7d734a6585251) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Various fixups to ensure consistent gcc buildsRichard Purdie2011-08-111-3/+7
| | | | | | | | | | | | | | | We ensure that: * the shared work directory contains PR and ensure PR values are consistent across gcc builds * the regexp to handle library directories is in a specific task and run once This avoids breakage that was seen in incremental builds after commit be1f70d68b6b75772ebab8bdff683ddd7c42b0cd where the interpretor could become corrupted. This was due to the sed expression corrupting the source directory. (From OE-Core rev: 970af6b09e1d69041b0d82fa56ace19543405eb1) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Fix setting of GLIBC_DYNAMIC_LINKERKumar Gala2011-08-031-4/+8
| | | | | | | | | | | | | | | | | | | | The sed regex in do_configure_prepend was producing the following result: #define GLIBC_DYNAMIC_LINKER64 SYSTEMLIBS_DIR "/lib64/ld-linux-x86-64.so.2" instead of removing the leading "/lib" or "/lib64". Now we have it do: #define GLIBC_DYNAMIC_LINKER64 SYSTEMLIBS_DIR "ld-linux-x86-64.so.2" Additionally, with the regex fixed the manipulation of SYSTEMLIBS_DIR needs to be removed. (From OE-Core rev: b343436d03fa5690b16ee8ef5d4a738c5194b301) Signed-off-by: Kumar Gala <galak@kernel.crashing.org> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Share gcc work directoriesRobert Yang2011-06-301-20/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patched is derived from Richard, make gcc use the shared source directory during the different building: 1) Make gcc-cross, gcc-cross-initial, gcc-cross-intermediate and gcc-runtime share the same source directory. 2) The source directory is ${TMPDIR}/work-shared/gcc-${PV}, for example: tmp/work-shared/gcc-4.5.1 3) Fix do_clean to clean the shared source directory and stamps 4) gcc uses sed and creates config files against ${S} which means the directory should not be shared. Change the way to make it work: * The configure option --with-headers=${STAGING_DIR_TARGET}${SYSTEMHEADERS} can replace the sed command, see the code in configure: if test "x$with_headers" != x; then glibc_header_dir=$with_headers This has the same effect as the sed command: sed -i 's:^\([ ]*\)glibc_header_dir=\"${with_build_sysroot}/usr/include\": ... so add the --with-headers=${STAGING_DIR_TARGET}${SYSTEMHEADERS} to gcc-configure-cross.inc( not add to gcc-configure-common.inc, since not all the gcc building need this, the one which has its own do_configure doesn't need it). * Move t-oe from ${T} to ${B}/gcc, so that the patched Makefile.in can read it easily, please see the commit for gcc-4.5.1 and gcc-4.6.0. * Use the defaults.h in ${B}/gcc instead of ${S}/gcc, and the patched configure.ac(configure) can read it correctly, please see the commit for gcc-4.5.1 and gcc-4.6.0. * The gcc-crosssdk.inc used sed to edit ${S}/config/*/linux*.h to change the GLIBC_DYNAMIC_LINKER, which made the source incompatible. To make the source compatible: - Use: sed -i ${S}/gcc/config/*/linux*.h -e \ 's#\(GLIBC_DYNAMIC_LINKER[^ ]*\)\( *"/lib.*\)#\1 SYSTEMLIBS_DIR\2#' so entries in the files that look like: #define GLIBC_DYNAMIC_LINKER64 "/lib64/ld-linux-x86-64.so.2" would become #define GLIBC_DYNAMIC_LINKER64 SYSTEMLIBS_DIR"/ld-linux-x86-64.so.2" and we define SYSTEMLIBS_DIR in defaults.h. NOTE: #define GLIBC_DYNAMIC_LINKER64 (SYSTEMLIBS_DIR "/ld-linux-x86-64.so.2") doesn't work in in the following define: #define LINUX_DYNAMIC_LINKER \ CHOOSE_DYNAMIC_LINKER (GLIBC_DYNAMIC_LINKER, UCLIBC_DYNAMIC_LINKER) so use #define GLIBC_DYNAMIC_LINKER64 SYSTEMLIBS_DIR"/ld-linux-x86-64.so.2" 5) Add do_configure_prepend to gcc-configure-common.inc and remove the one in gcc-crosssdk.inc, this makes it easy to share the source, otherwise we need do extra changes in gcc-configure-sdk.inc. 6) Use "cat > file <_EOF" to replace the "echo > file" (From OE-Core rev: 934d38530c9a67562e53d4034aee5531f0f26750) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* recipes: Use -uclibceabi instead of -uclibcgnueabiKhem Raj2011-04-041-1/+1
| | | | | | | (From OE-Core rev: 3aa429406184d27bdb8a771c4c12bde1dcccb95b) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: fix check for target libc ssp supportKevin Tian2010-09-301-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | gcc uses hardcoded path "${with-build-sysroot}/usr/include" to check target libc ssp support. Based on GLIBC version strings in features.h in that search path, gcc knows whether target (e)glibc implements stack protector itself. However this breaks meta-toolchain, which actually has target libc headers installed under {with-build-sysroot}/opt/... This way features.h is not found and thus gcc-crosssdk-intermediate thinks that target (e)glibc doesn't support ssp. Later when building eglibc-nativesdk, undefined reference to "__stack_chk_guard" occurs which was caused by: o eglibc do_configure found that gcc-crosssdk-intermediate supports ssp, and thus enable -fstack-protector for nscd o eglibc itself supports stack smash proctection for some architectures such as i386, x86-64, etc. It's expected to use its own method to provide stack protection, instead of relying on gcc. So eglibc rtld.os doesn't export __stack_chk_guard to other modules o then when installing nscd objects, gcc-crosssdk-intermediate sees the flag "-fstack-protector", while it thought this eglibc doesn't implement ssp itself, so gcc turns to the alternative to find a valid __stack_chk_guard exported. eglibc doesn'g export it, while gcc-crosssdk-intermediate itself disables libssp. Then the undefined reference happens. If enabling libssp for gcc-crosssdk- intermediate, it may also work-around this issue. But the ideal fix is still to replace hard coded path with the actual one where target libc gets installed. glibc-nativesdk doesn't encounter this issue because it thinks gcc doesn't support ssp, and thus doesn't enable "-fstack-protector" for nscd. Don't know the reason yet This fix [BUGID #366] Signed-off-by: Dexuan Cui <dexuan.cui@intel.com> Signed-off-by: Kevin Tian <kevin.tian@intel.com>
* gcc: enable poison parameters detectionDongxiao Xu2010-09-271-1/+1
| | | | | | | | | | | If not configured with --enable-target-optspace, gcc will report errors if there is '-Os' optimization in parameters. This fixes [BUGID #342] Also add "--enable-target-optspace" option to arm gcc configuration. Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
* gcc: upgrade gcc for powerpc to version 4.5.0Dongxiao Xu2010-09-171-1/+2
| | | | | | | | | | | | | | Fix one parameter order issue for base_contains function, which impacts glibc build under new gcc. Add new judge code to determine whether <altivec.h> is needed. This fixes the mpeg2dec build failure under new gcc. Use O2 as the optimization flag to tinylogin as it will meet segfault if compiled by gcc-4.5.0 when enable both frename-registers and Os options. Use O2 instead. Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
* Major layout change to the packages directoryRichard Purdie2010-08-271-0/+107
Having one monolithic packages directory makes it hard to find things and is generally overwhelming. This commit splits it into several logical sections roughly based on function, recipes.txt gives more information about the classifications used. The opportunity is also used to switch from "packages" to "recipes" as used in OpenEmbedded as the term "packages" can be confusing to people and has many different meanings. Not all recipes have been classified yet, this is just a first pass at separating things out. Some packages are moved to meta-extras as they're no longer actively used or maintained. Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>