Since we now handle GLIBC_DYNAMIC_LINKER in gcc-configure-common.inc:
's#\(GLIBC_DYNAMIC_LINKER[^ ]*\)\( *"/lib.*\)#\1 SYSTEMLIBS_DIR\2#'
we can drop the patch which changes a hardcoded value for this.
No PR bump since there is no code change resulting from this, its just
a cleanup.
There is still a valid question over the remainder of this patch and its
interaction with multilib configurations.
(From OE-Core rev: 036faf66c3889cd8bf4cd3c9b97c80f008f3c6e2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch adds the core multilib class which can be used along with a
parameter specifying the mutlilib to use in BBCLASSEXTEND.
The MLPREFIX variable is added and can be used in cases where its too
difficult to dynmaically work out where a mutltilib prefix is needed
to be added to a variable.
This includes:
* SHLIBSDIR and PACKAGE_ARCH fixes from Lianhao Lu.
* PACKAGE_DYNAMIC mapping from Yu Ke
* PACKAGE_INSTALL mapping from Yu Ke
* RPROVIDES mapping from Yu Ke
* TARGET_VENDOR fix from Mark Hatle
* Ignorning *-native-runtime dependnecies as well as *-native from Yu Ke
* Map PKG and ALLOW_EMPTY from Dongxiao Xu
* Ensure RCONFLICTS and PKG field dependencies are remapped (from Dongxiao Xu)
* Ensure PN and MLPREFIX are set at the same time to ensure consistent BPN values (Yu Ke)
(From OE-Core rev: 5d9453049915db48ec4b5972e12287417ebb61a2)
Signed-off-by: Yu Ke <ke.yu@intel.com>
Signed-off-by: Xu Dongxiao <dongxiao.xu@intel.com>
Signed-off-by: Lianhao Lu <lianhao.lu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We need to include file class and file color in order to do the conflict
resolution required with a multilib design. This is normally disabled when
we don't use the internal dependency generator, patch enables it in
all cases.
(From OE-Core rev: 4c43ea3440ecca02d2945b02017f56a8de9ff808)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When linking with gcc, the parameter is read from left to write, if *.o
calls a function contained in libxxx, the parameter order should be
"gcc ... *.o -lxxx".
This commit fixes the problem in distcc.
(From OE-Core rev: 782499eaa817f1beecc0aea5bfa075196f8e2a53)
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
bfd.h conflicts between 32-bit and 64-bit versions.
(From OE-Core rev: cd2975f7ad380aaac8c88bc151a2c34a42d4c540)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is this discrepency in spelling. Lets fix it in
core. There are lot of layers using SITEINFO_ENDIANNESS
This was shielded since meta-oe had its own copy of
siteinfo class. But that class has now been deleted in
favor of oe-core
(From OE-Core rev: 54a54778fad39931ac7d43daaf37ce7c1946a29b)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The perl-dynloader.patch can't support lib64 lib32, libx32, etc.
Relax the regular expression to fix this issue.
(From OE-Core rev: 7ebc7a5cb30e13217dc297994a6d9656b52bacba)
Signed-off-by: Mei Lei <lei.mei@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[YOCTO #1250]
This added function will install a private install-catalog binary so that shared state
can find the binary as there is not a guarantee.
(From OE-Core rev: b3e68f112cff5f15b5245582eee7e087acbad2fa)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[YOCTO #1250]
This added function will install a private install-catalog binary so that shared state
can find the binary as there is not a guarantee.
(From OE-Core rev: b4eef2e1bed0536325342ca884ee0905b7e79ada)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[YOCTO #1250]
This added function will install a private install-catalog binary so that shared state
can find the binary as there is not a guarantee.
(From OE-Core rev: 188ac8c8fe7a004c576190c42d0f33d00ea88c60)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The base gcc package is missing liblto_plugin.so. If we try a simple
hello world compile we get something like:
root@p5020-ds:~# gcc hello.c
gcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
compilation terminated.
We need to include liblto_plugin.so in the base gcc package and not
gcc-dev.
(From OE-Core rev: 282326a188467edf6caef21b07a7e51288674245)
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is required especially on uclibc systems where BSD compatible
obsolete functions are disabled by kconfig. Therefore we check
if the macro is undefined then we define it. Therefore eglibc/glibc
builds should work as they use to.
(From OE-Core rev: 60d91ffc6367fe11ced5890240c6b65ada66621e)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
intltool recipe was using perl from the host instead of perl from
poky. This forces the recipe to use poky's perl (along with perl
modules it pulls in)
(From OE-Core rev: fd39130db3f3e66cd6be25dfbbe9cd1e7a21ff26)
Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Tom Rini <tom_rini@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is 5396e0868cf89787746fa6341ddb1f271a770595 in oe.dev but here we
instead use the nativeperl wrapper.
(From OE-Core rev: a788f8262481706d5311eb9b2573f2d69ab2a5d6)
Signed-off-by: Tom Rini <tom_rini@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
On hosts where we may already be past the #! limit this is required
and this is safe on the target as well. This is be7fe31 in oe.dev.
Related to this we now bump all PRs for recipes that inherit cpan.
Note that in oe.dev we mangle for perl but here we use the new
nativeperl script.
(From OE-Core rev: 682a213dc732074985bf86f508305fc6eafe18d9)
Signed-off-by: Tom Rini <tom_rini@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We need this to allow for scripts to do #!/usr/bin/env perl-native
and not require an 'inherit perlnative' per user of a package.
(From OE-Core rev: 48c1e10f53894e666283aac086e61444d2c1ed69)
Signed-off-by: Tom Rini <tom_rini@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is dd33ced4b8123600efa1f67f704aec13b0842ad1 in oe.dev and needed
for building in deep paths.
(From OE-Core rev: 339d039a9b2f0e97f25781ccf6937f1050d83989)
Signed-off-by: Tom Rini <tom_rini@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the library is installed without execute permission then package.bbclass
will not consider it for stripping. This is particularly unfortunate because
there seems to be a bug somewhere else which is causing all DSOs to end up with
a NEEDED dependency on libgcc_s, even if they don't actually require it, and
hence it is getting installed in all images (for uclibc on i586 at least).
(From OE-Core rev: b3724a67ad70f509181555e6be98e1eb3b184bb7)
Signed-off-by: Phil Blundell <philb@gnu.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Several users reported issues with pseudo on CentOS 5.x hosts, Matthew
McClintock tracked the issue to the realpath_fix.patch and Mark Hatle
supplied the included fix.
CC: Matthew McClintock <msm@freescale.com>
CC: Mark Hatle <mark.hatle@windriver.com>
(From OE-Core rev: 46b2bc1d4694f927bc3d6c108309615a4903cede)
Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is a 'side port' of current oe.dev versions. PR is kept in sync
but we drop out the target recipes in order to punt on potential perl
problems. Here we do re-configure as we don't have a dance with
perl-native to deal with. Now that we can build it, don't require it.
(From OE-Core rev: 9673d7aa1f9e1c88ba69047b2e22636c755edaaa)
Signed-off-by: Tom Rini <tom_rini@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The e500v2 core utilizes a unique floating point programming model / ABI.
We utilize TARGET_FPU = "ppc-efd" to distinguish this choice (Embedded
scalar single-precision floating-point). When building the toolchain for
this ABI we need configure gcc with --enable-e500_double.
(From OE-Core rev: 5136c4ad6279c1593301f6dde9b959ad26a2fd0f)
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This needs libuuid bits in order to build.
(From OE-Core rev: 24ecee09541a3f620497bc77f142493ef28e1a50)
Signed-off-by: Tom Rini <tom_rini@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
current RRECOMMENDS_perl-modules replace the hardcode "perl-dbg",
"perl-misc" etc. which does not work in multilib case. Instead, it
should replace the "lib64-perl-dbg", "lib-64-perl-misc". without
doing this, current code will produce RRECOMMENDS=lib64-lib64-xxx etc
This patch revise the code to fix this issue
(From OE-Core rev: d76ede1e696d52c08ede8b6e539cb0895ee73b2f)
Signed-off-by: Yu Ke <ke.yu@intel.com>
Signed-off-by: Xu Dongxiao <dongxiao.xu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This fixes:
| rm: cannot remove `/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-4.5-r39.1+svnr175127/image/usr/libexec/gcc/arm-angstrom-linux-gnueabi/4.5.4/*.la': No such file or directory
| ERROR: Function 'do_install' failed (see /OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-4.5-r39.1+svnr175127/temp/log.do_install.19514 for further information)
NOTE: package gcc-4.5-r39.1+svnr175127: task do_install: Failed
(From OE-Core rev: 4db073061bdd1d3361ff90d309049a1621f06704)
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Set SRCREV to match the point at which 4.6.1 was released, update PV appropriately.
(From OE-Core rev: d575031f3bcd7acbc7dae25f17a60f0d493643fb)
Signed-off-by: Phil Blundell <philb@gnu.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Switch from SITEINFO_BITS / SITEINFO_ENDIANESS rather than
siteinfo_get...
(From OE-Core rev: 615f05dc46afa14ea4fca49a551278b92d2c99d3)
Signed-off-by: Tom Rini <tom_rini@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
To fix these package qa warnings
WARNING: For recipe binutils, the following files were installed but not shipped in any package:
WARNING: /usr/bin/ld.bfd
WARNING: /usr/bin/elfedit
(From OE-Core rev: 2365c6830119f9242aae3450488183ec11fe9c1d)
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
rpm default will use /usr/lib if the --with-path-lib is not specified.
this will not work in non /usr/lib libdir case.
so this patch add the --with-path-lib to fix this issue.
(From OE-Core rev: f707953372dd0962efb5cb8daeb422743376bc29)
Signed-off-by: Yu Ke <ke.yu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
the config.sh is hardcoded to be /usr/lib, which does not work in non
/usr/lib libdir case.
This patch replace the hard code /usr/lib with ${libdir} to fix this issue
(From OE-Core rev: 603c5a241f0549da00334ac62dcbd1b0a72b6c82)
Signed-off-by: Yu Ke <ke.yu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
the get_python_lib() use hard code "lib". when other recipe
building use python-native, the STAGING_LIBDIR is non /usr/lib,
so the hard code "lib" will break the build
This patch replace the hardcoded "lib" with value from libdir
to fix this issue.
(From OE-Core rev: ab4ae436126f20b404375c9ae77cf66cfe31ea34)
Signed-off-by: Yu Ke <ke.yu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
python has several place hard code "lib" which breaks build
when libdir=/usr/lib64. SUSE has a patch to fix this issue.
So this patch add the SUSE patch to address this issue
(From OE-Core rev: c97ab268d6a7092a89c8b0051924a2acc2d86d9c)
Signed-off-by: Yu Ke <ke.yu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[YOCTO #1233]
This fix directly packages the contents in and adds the lib*.so
correctly to the -dev package.
(From OE-Core rev: d3c5f93714165e5c089ce80194f2be07e31d920c)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
