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>
We have a patch unixccompiler.patch where we try to throw away
everything except first element of CC string but this does not
work if gcc is prepended with something e.g. CC="ccache gcc"
then the logic fails and it ends up in some modules failing on
you silently (_sqlite3) in my case.
The fix here is to drop basename so we keep the whole
string as it is and then the detection function searches
for gcc string in the whole CC. This works in both cases
one the original intent of the patch and the second described
above. One place where it will fail is if someone has non-gcc
compiler installed in some subdir which has gcc in it e.g.
/usr/gcc/fakecc but for OE this should never happen. Ideally
the the detection logic should have tried to execute gcc
and then parsed --version output or something.
(From OE-Core rev: 9b13b9024d24953dedb35f62d3d8b06a29036992)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This class currently only works with eglibc. Since
it adds dependencies explicitly on eglibc when using
uclibc this creates problems. So we make sure that
it checks for TCLIBC to determine system C library
in use
(From OE-Core rev: 2278f891a9bd204d82abbd6998cf0921908f1d14)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
runqemu scripts check for them and when using just oe-core
these are not defined anywhere
(From OE-Core rev: 1ec729dfe8e6df9a8d65d939b8a0f2b322196acf)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Complete the bb.data.getVar/setVar replacements with accesses
directly to the data store object.
(From OE-Core rev: 2864ff6a4b3c3f9b3bbb6d2597243cc5d3715939)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Avoding the autoreconf with a hardcoded do_configure is bad practise
since it can hide various errors. This patch ensures we do use the
standard do_configure.
(From OE-Core rev: 54c4b4fd10c104641bb7ae087b2230aa6c6085f8)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
On my system, the sys/time.h header is in a subdir off /usr/include
which causes a build failure. Apply the target CFLAGS fix to native
builds as well to address this.
(From OE-Core rev: 67176378266767cd0cca4f8ecafa865907ca4bdd)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There continue to be parallel make race issues showing up on the autobuilder.
This patch removes some potential sources of these. The rm is unrequired
since we're using cp -f. The || true ensures that if we did race against
someone it becomes harmless.
[YOCTO #1202]
(From OE-Core rev: 32840cd95fcde92433fbb0271b82d0f4048a823a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We need to ensure there is a python dependency for the ofono python
test scripts. To do this without introducing the dependency
unnecessarily for the core ofono functionality, this patch splits
the tests into a separate package too.
[YOCTO #1705]
(From OE-Core rev: f699cb48c7f379f97623f1f244b0b6c5875d7497)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
USER is the correct variable to use, also this can affect sstate
cache as well.
(From OE-Core rev: 0f446c29f10fd83228619e05ddec29fdc29188b3)
Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When I was trying self-hosted-image, eglibc's do_install failed in the target:
ERROR: cannot stat bootparam_prot.h:
the cause is: rpcgen doesn't work properly: rpcgen can't exec /lib/cpp since
it doesn't exist.
According to http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/lib.html:
"if a C preprocessor is installed, /lib/cpp must be a reference to it, for
historical reasons. The usual placement of this binary is /usr/bin/cpp".
Typical distros, like Ubuntu, openSuSE, Fedora and RHEL, all comply with
the rule.
Actually in meta/recipes-devtools/gcc/gcc-package-target.inc, we do try to
package ${base_libdir}/cpp:
FILES_cpp = "\
${bindir}/${TARGET_PREFIX}cpp \
${base_libdir}/cpp \
${libexecdir}/gcc/${TARGET_SYS}/${BINV}/cc1"
But unluckily we didn't create a symbol link in do_install.
This patch adds the symbol link.
(From OE-Core rev: 58fb9fbce2af05a469691390e75aebb2de16ca96)
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
configure of cvs packages was failing on the meta-toolchain for a x86_64 target.
Configure error reported:
checking whether printf supports %p... configure: error: cannot run test program while cross compiling
This fixes [YOCTO #1781]
(From OE-Core rev: 061818adbea1af9e98fe0fdf81b21f1e7f210c00)
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The value of baselib can be constructed in several different ways
and from a sstate perspective we don't care how it was made up,
we only care what the final value is. This uses the new functionality
in bitbake to ensure we only include the value of baselib and not
any intermediate dependencies.
[YOCTO #1583]
(From OE-Core rev: c38567894ebc31ac977f2bc89a076d0380bddcf8)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We need to remove the files from avahi-ui which conflict with the avahi recipe.
If we don't do this they trigger packaging warnings and can also overwrite
files in the sysroot unexpectedly causing build failures (if X depends on
avahi, it expects avahi's files to stay there, not disappear as avahi-ui
build/stages).
This patch cleans up the packaging although I wish there were an alterantive
to the do_install which makes my eyes bleed.
[YOCTO #1770]
[YOCTO #1722]
(From OE-Core rev: 95b383781f875a0f10e5c1de039289bb89e421dd)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Without this simply changing the number of threads via
PARALLEL_MAKE can invalidate sstate-cache
(From OE-Core rev: 45140c860272fa4b610805d4dacadcf9201c3e35)
Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The method of resolving the patch should not effect the sstate-cache
signature.
(From OE-Core rev: b64cbe0b511de8d8943ce34cbb4901239d9f0cb0)
Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
when gtk+ configures, it should pick up ${NM} from the environment \
if it is defined, instead of just looking for "nm".
(From OE-Core rev: 7cb5063d8bc59534dc64b19164cb9bdf0c04c68b)
Signed-off-by: Xiaofeng Yan <xiaofeng.yan@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Get patch from: http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/27614
There is a potentially "unsafe" use of open(). Ubuntu 8.10+, for instance,
by default enables the compiler flag -D_FORTIFY_SOURCE=2 \
which throws an error of ts_calibrate.c. To fix this, \
set a mode in the open() call, patch patched ts_calibrate.c \
to set 0644 (S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH) and it compiles fine
(From OE-Core rev: 61928384b91f7328aaa72c6d1299d8598c24574d)
Signed-off-by: Xiaofeng Yan <xiaofeng.yan@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #1174]
Rpm logs will grow indefinitely, so change the config to flush those old logs.
(From OE-Core rev: e2c4dff079722f256ddcab9630b5b3f8f6421cc9)
Signed-off-by: Mei Lei <lei.mei@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Update eglibc 2.13 SRCREV to 15508, just to sync with upstream
Remove glibc_bug_fix_12454.patch, because it is already merged.
(From OE-Core rev: e364b04a34d7c2a95145799773821e82b8677e78)
Signed-off-by: Kang Kai <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
mysql.patch is not used by the recipe anymore, so delete it.
(From OE-Core rev: a60449f6110bc86dd0d976413c169bafc0ebcada)
Signed-off-by: Scott Garman <scott.a.garman@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The console log is often helpful for debugging issues. Difficult to
reproduce bugs would benefit from a log being generated by default as it
may be difficult to come by after the fact.
Log to ${TMPDIR}/cooker.log.${DATETIME} by default.
[YOCTO #1771]
(From OE-Core rev: 4b916ce59bf88ca92b034b2acaddee6130155e46)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we just use print, the bitbake logging functions don't see the message
and it can get lost if bitbake is for example logging messages to disk.
(From OE-Core rev: 73a3d0d337e26c2be89c215efb8a2c3dd5d5994d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is no point in having "executable" binaries in the .libs
directory linked with different rpaths to the target which
could concivably be run on the build system when cross compiling.
This patch removes the extra rpaths ($compile_rpath) so that the
output from the "link" stage can be used on the target. We can then
avoid having to "relink" during the install stage.
This saves some build time (do_install is over 2 minutes faster for
pulseaudio).
This patch also removes an annoying "seems to be moved" warning
which is totally bogus in the sysroot case.
(From OE-Core rev: 0a1dedeb8eea4e230b47d1516b3e6e90495fe49d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
apt wasn't building on modern libc/compiler combinations due to missing
header includes.
The libcpp version was also being hardcoded, this patch generates it
dynamically to work on different host systems which no longer have
this.
(From OE-Core rev: ca8237ee51053d70b5e7579c224a824db2be76b2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Change check sum of directfb. The previous checksum was incorrect when it
was added due to a corrupted download on the submitter's system.
(From OE-Core rev: 7056ea9b1eb5ff358c1f8d2b949597e4e98f3a2b)
Signed-off-by: Xiaofeng Yan <xiaofeng.yan@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Updating manual check dates for the following recipes: tar, libpng,
expat, dosfstools, e2fsprogs
(From OE-Core rev: 30620ff51a8b5a8da6dbcefcf7b9023f82e693e3)
Signed-off-by: Scott Garman <scott.a.garman@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* libnl - NO_UPDATE_REASON due to incompatibility
* zlib - has wrong version in update list (121)
* libtasn1 - Update to 2.10
* pkgconfig - NO_UPDATE_REASON due to removal of glib-conf
* file - update to 5.09
* dchp - New version is 4.2.3, not updated yet.
* tiff - NO_UPDATE_REASON wait until 4.0.0
* gobject-interopsectio - NO_UPDATE_REASON can not cross-build
* gnu-config - Udpate to git HEAD - requires ASSUME_PROVIDED += "git-native"
(From OE-Core rev: b49b04dc6417cc8a079ba8284d193fb78f054713)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Without these changes, gconf will use the hardcoded backend directory meaning
we can see errors when building if the binary was relocated.
(From OE-Core rev: aaa2a70f7f1b8a299f31626d61d7ea27f29fb9e2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The gconf .m4 files use the path encoded into the gconf-native tools
by default to populate this variable. This doesn't work if we're
relocating the gconf-native binaries. By setting this variable we
ensure that the m4 files always pick up the correct path.
This fixes errors seen on the yocto autobuilder.
(From OE-Core rev: 5680bf11f2e5877782d0101d5b8a5ed24d1ddbce)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Without this, linking can fail due to missing libraries since the
code depends on Xrender. The fix was already upstream, we just need
to use a revision that includes it.
(From OE-Core rev: b8328a132efd515515bb2c200271a8960f0d783b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
According to XChangeProperty doc, array of "long" should be used when format is
32. Wrong _NET_WORKAREA parameter caused blank screen in matchbox-desktop on 64
bit platform.
[YOCTO #1689] got fixed.
(From OE-Core rev: 381c7857a5b303bf9eadd7fffc39d17a2b8e31f2)
Signed-off-by: Zhai Edwin <edwin.zhai@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since we clean out do_populate_sysroot if do_configure runs, don't
allow do_populate_sysroot_setscene functions if we're going to
run do_configure.
(From OE-Core rev: 5f1dc1991f97037692193572298eb7f7a5640760)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If rpm-native was built in an alternative location, it may not relocate correctly
unless the rpmpopt and macros paths are explicitly specified.
This fixes errors seen on the Yocto autobuilder where pkgconfig
"provides" entries could disappear leading to image dependency failures.
(From OE-Core rev: fb01bd81197057e62106aac966f9ebc4c5054f97)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Backport fix for PR 47551 fixes the ICE seen on armv7-a/qt4-x11-free
Bump up SRCREV past gcc 4.6.2 release
(From OE-Core rev: dd2fdf9f5a3923c37e4ea2e46e347bb0657c2f5b)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
moreover 4.46 tar is not available on debian pools
(From OE-Core rev: e1abae623a6b3afcb29f325220cc79453efb4e77)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
