| Age | Commit message (Collapse) | Author | Files |
|---|
|
By default the system will expand the extra os entries for uclibc and musl
even if they are not enabled in the build. There was no way to prevent this
behavior while still getting the expansion for things like x32 or spe.
The change adds a new setting which a distribution creator can override
easily, setting the base set of canadianextraos components. The other
expansions are then based on this setting.
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
for SDK use
We build SDKs such that gcc-cross-candian is built for only one
target *-*-linux and then use -muclibc or -mmusl to let it compile
code for other libc variants. This works fine when libc = glibc
however it does not work for c++ programs when libc != glibc since
there are c++ headers installed under ${includedir}/c++/${BINV}/${TARGET_SYS}
which is fine when gcc-runtime and gcc-cross-candian uses same --target options
gxx includedir searches in right triplet, but it fails with musl/uclibc
since gcc will look for glibc based triplet but gcc-runtime will install
them under musl/uclibc triplet.
This patch symlinks the musl/uclibc triplet to glibc triplet when libc != glibc
This fixes SDKs for musl/uclibc
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Have DPKG_ARCH set by directly invoking a mapping function, rather
than using an anonymous Python function modify the variable under
the hood, so we can have proper handling of overrides.
Also bring in some additional mappings to Debian architecture names
that weren't being handled.
Signed-off-by: Matt Madison <matt@madison.systems>
Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
With the autodebug package generation logic, specifically setting FILES_${PN}-dbg
isn't needed in most cases, we can remove them.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
If building for a BE8 ARM target, arch is "armeb" rather than
"arm", but ABI should still be "gnueabi". Otherwise gcc won't
build.
Signed-off-by: Peter Seebach <peter.seebach@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Mario Domenech Goulart <mario@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Allow "baremetal" builds.
(From OE-Core rev: 0cd3121058ea620c74622f1200c8040696b4d1d8)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
"n32" is a mips64 variant we need to consider when processing the TARGET_OS
extensions. Also add the multilib extensions for mips64.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
In the same way we map various TARGET_OS options back to the single
cross-canadian compiler, add mappings for the TARGET_VENDOR cases we
know about in the multilib case.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
gcc-cross-canadian-<arch> is only built once. It needs to target all the
different libcs, not just the currently selected one. This change
ensures that if another libc is used, symlinks are present such that the
compiler can be found. The base version is always assumed to be "glibc"
with symlinks from musl and uclibc compiler names.
This means gcc-cross-canadian is consistent regardless of which libc is
selected when its build in multimachine builds.
[YOCTO #8025]
(From OE-Core rev: 83ead626c0da75edec2833ffb1a29011ec7b83d2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
There are some cases we want the manipulation cross-canadian performance
on TARGET_OS, there are also cases like meta-environment where we do not
want this manipulation.
We did try and use immediate expansion to avoid this problem and it
works in the non multilib case. If we have a multilib that used an
extension, like for example:
require conf/multilib.conf
MULTILIBS = "multilib:lib32 multilib:lib64"
DEFAULTTUNE = "mips32r2"
DEFAULTTUNE_virtclass-multilib-lib32 = "mips64-n32"
DEFAULTTUNE_virtclass-multilib-lib64 = "mips64"
then the n32 extension case will be misconfigured.
It turns out saving an unexpanded variable is hard. The best I could
come up with was:
SAVEDTOS := "${@d.getVar('TARGET_OS', False).replace("{", "*")}"
and then
localdata.setVar("TARGET_OS", d.getVar("SAVEDOS", False).replace('*','{'))
which is rather evil, I'd challenge someone to come up with a nicer way
of making it work though!
Rather than the above madness, we modify cross-canadian to make the
problamtic code conditional.
This fixes the original issue (where a linux-gnuspe target was seeing
'linux') of
http://cgit.openembedded.org/openembedded-core/commit/?id=0038634ee6e2b6035c023a2702547f20f67c103a
but also fixes the multilib one.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Similarly to native/cross disable this since otherwise the packagedata
can be marked as machine specific and if you switch machines
which share an architecture, you'll get toolchain overlapping files
errors.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
A while back we fixed the cross definitions to work better in multilib
configurations, apply the same fixes to cross-candian.bbclass
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This allows them to co-exist together in the native sysroot, with one
set of cross tools per target architecture.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Fixes errors like
Parsing recipes...ERROR: Building cross-candian powerpc for an unknown
TARGET_SYS (powerpc-angstrom-linux-uclibc), please update
cross-canadian.bbclass
ERROR: Building cross-candian powerpc for an unknown TARGET_SYS
(powerpc-angstrom-linux-uclibc), please update cross-canadian.bbclass
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The previous cross-canadian change was missing some tweaks
to the comments. This clarifies them slightly.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
PowerPC toolchains can use the OS "linux" or "linux-gnuspe". This
patch links them together so the one cross-canadian toolchain can support
both.
GCC_FOR_TARGET is set for the GCC recipe as otherwise configure
can pick up an incorrect value.
[YOCTO #5354]
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
Both nativesdk and multilib use MLPREFIX for their partciular purposes. When
we have both set, cross-canadian can confuse SHLIBSDIR. This forces the
variable to the correct value for cross-canadian, fixing toolchains in
multilib builds.
[YOCTO #5333]
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The cross-canadian compilers are now build once per architecture but were being
installed into tune specific locations which is incorrect. This adjusts things
so they are make TARGET_ARCH specific. We gain the tune specific parts from the
target sysroot which remains tune specific, the compiler and tools are independent
ot that.
binutils/gcc require sysroot options but since we reset at runtime, these shouldn't
have dependencies in the sstate checksums. They are therefore also excluded.
With these patches, switching machines does not result in a rebuild of *-cross-canadian
and the compiler is correctly located and referenced in the target images.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
directory
Currently we have a hierarchy of pkgdata directories and the code has to put together
a search path and look through each in turn until it finds the data it needs.
This has lead to a number of hardcoded paths and file globing which
is unpredictable and undesirable. Worse, certain tricks that should be
easy like a GL specific package architecture become problematic with the
curretn search paths.
With the modern sstate code, we can do better and construct a single pkgdata
directory for each machine in just the same way as we do for the sysroot. This
is already tried and well tested. With such a single directory, all the code that
iterated through multiple pkgdata directories and simply be removed and give
a significant simplification of the code. Even existing build directories adapt
to the change well since the package contents doesn't change, just the location
they're installed to and the stamp for them.
The only complication is the we need a different shlibs directory for each
multilib. These are only used by package.bbclass and the simple fix is to
add MLPREFIX to the shlib directory name. This means the multilib packages will
repackage and the sstate checksum will change but an existing build directory
will adapt to the changes safely.
It is close to release however I believe the benefits this patch give us
are worth consideration for inclusion and give us more options for dealing
with problems like the GL one. It also sets the ground work well for
shlibs improvements in 1.6.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Hardcoding -nativesdk as the sdk package architecture is inflexible. We may have
multiple different target OS and we need a way to be able to separate them. Turning
this into a configurable value allows the flexibility we need to build different
SDKMACHINEs with different OS targets.
The commit should have no behaviour change, just makes things more configurable.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The gettext handling of USE_NLS has become a bit tricky to understand, or
alter from the SDK context. This patch introduces a SDKUSE_NLS which can
be set to configure a given SDK/ADT to use NLS or not. This is independent
of the target system NLS usage.
The code in gettext.bbclass is therefore simplified and the classes
themselves now set USE_NLS to appropriate values. No NLS is used
for native, cross and crosssdk since it is never used there and
would just increase build time.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This was needed when do_package for target recipes was target specific
however since it now isn't we can remove these stale references.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
non-machine specific
Currently, do_package is machine specific since the shlibs data is installed
into each machine specific sysroot. This change moves the shlibs data to the
pkgdata structure, at the expense of having to iterate over a set of shlibs
directories instead of a single one.
It turns out this isn't any particular hardship for the code and as a result,
do_package stops being machine specific leading to optimisations for builds
that use a common PACKAGE_ARCH.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
In order for the RPATHs in 32bit toolchain binaries to be relocated
properly, chrpath >=0.14 is needed.
[YOCTO #3161]
[YOCTO #3201]
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
As discussed on the mailing lists, using a suffix to package names is
hard and has lead to many recipes having to do PKGSUFFIX games. Its
looking extremely hard to scale nativesdk much further without hacking
many recipes.
By comparison, using a prefix like multilib does works much better and
doesn't involve "hacking" as many recipes. This change converts nativesdk
to use a prefix using the existing multilib infrastructure.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
We have currently no override to detect a recipe being build cross, crosssdk
or for target at times we can use virtclass-native and virtclass-nativesdk to
override stuff in recipes but we dont have way to modify a variables
based on recipe type always.
This patch adds in such an override and in particular makes a target override
class available.
With this change now we can say:
EXTRA_OECONF_class-target = "...."
EXTRA_OECONF_class-native = "..."
EXTRA_OECONF_class-nativesdk = "..."
EXTRA_OECONF_class-crosssdk= "..."
Based of an original patch by Khem Raj
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This makes the libraries located in places like this findable:
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib
Which avoids linking cross canadian sdk executables with host libraries like this:
$ ldd /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-gdb
linux-vdso.so.1 => (0x00007fffb7fff000)
libreadline.so.6 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/x86_64-oe-linux/../libreadline.so.6 (0x00007fbfb5511000)
libdl.so.2 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libdl.so.2 (0x00007fbfb530c000)
libncurses.so.5 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libncurses.so.5 (0x00007fbfb50e9000)
libtinfo.so.5 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libtinfo.so.5 (0x00007fbfb4ec2000)
libz.so.1 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/x86_64-oe-linux/../libz.so.1 (0x00007fbfb4cac000)
libm.so.6 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libm.so.6 (0x00007fbfb4a2a000)
libpthread.so.0 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libpthread.so.0 (0x00007fbfb480d000)
libutil.so.1 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libutil.so.1 (0x00007fbfb4609000)
libexpat.so.1 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/x86_64-oe-linux/../libexpat.so.1 (0x00007fbfb43e0000)
libc.so.6 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libc.so.6 (0x00007fbfb4059000)
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x0000003f05000000)
[RP: Whitespace tweaks]
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
As reported by Martin Jansa, the path to nativesdk sysroot was changing between
nativesdk and cross-canadian recipes. The problem was the incorrect deinfition of
STAGING_DIR_HOST in cross-canadian.bbclass.
Since nothing really uses the cross-canadian output in the sysroot, only the
packages, its not surprising this bug has gone un-noticed.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Complete the bb.data.getVar/setVar replacements with accesses
directly to the data store object.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
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 *`
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This is comming from x32 need to pass special parameters to ld & as.
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
|
|
This patch removes the variables BASE_PACKAGE_ARCH, BASEPKG_HOST_SYS,
BASEPKG_TARGET_SYS and also removes the immediate assignments in
several core classes as these are no longer required.
This should make it clearer what some of the core variables do and
simplfy some overly complex and confusing class code.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
serves no useful purpose
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Set DPKG_ARCH to make debian package to be generated with correct
architecture.
Signed-off-by: Lianhao Lu <lianhao.lu@intel.com>
|
|
This commit changes the sysroots path to be machine specific.
Changes includes:
1) STAGING_DIR_TARGET and STRAGING_DIR_HOST points to machine specific
paths.
2) task stamp files. Adding ${MACHINE} info into stamp files for
do_populate_sysroots and do_package tasks. Add a BB_STAMPTASK_BLACKLIST
to keep native, nativesdk, crosssdk, and cross-canadian stamp unchanged.
3) siteconfig path. Separate the site config path for different machines
to avoid one machine adopting the cache file of another machine.
4) sstate. Add machine name to sstate manifest file.
Change relocation code for sstate paths since sysroot is machine.
Keep native, nativesdk, crosssdk, and cross-canadian unchanged.
5) toolchain scripts. Change the environment path to point to machine
specific sysroots in toolchain scripts bbclass.
6) Relocate la files when populating to a different machine of the same
architecture.
7) Exclude STAGING_DIR_TARGET and STAGING_DIR_HOST parameter from sstate
siginfo since they contain ${MACHINE} information.
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
|
|
environment files.
[BUGID #565] Fixing bug #565, added package of
meta-environment-${TARGET_ARCH} for environment files used by
cross-canadian toolchain.
Also corrected the situation of empty config site file for target.
Signed-off-by: Lianhao Lu <lianhao.lu@intel.com>
|
|
This patch massively simplifies the canadian packaging and allows
multiple toolchain targets to be parallel installed into the same
nativesdk sysroot without package name conflits. Since we now do
this, we can simplify cross-canadian to become more like nativesdk.
This is a first pass over this task, similar changes would be
desireable to cross and the whole MULTIMACH_ARCH mess can then
probably be similified much further.
Signed-off-by: Richgard Purdie <rpurdie@linux.intel.com>
|
|
Using TRANSLATED_TARGET_ARCH instead of TARGET_ARCH for
cross-canadian packages. This is due to the TARGET_ARCH of x86_64
would results incorrect packaging in cross-canadian packages.
The pacakge name appendix of x86_64 target in cross-canadian
packages is x86-64.
Signed-off-by: Lianhao Lu <lianhao.lu@intel.com>
|
|
Signed-off-by: Koen Kooi <k-kooi@ti.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
|
|
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
|
|
multimachine installs and update users accordingly
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
|
|
for multimachine
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
|
|
compilers
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
|
|
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
|
|
* Switch from /usr/local/poky to /opt/poky
* Use a sysroots directory for both the "native" sdk binaries and the target
* Drop the meta-toolchain extras packages. These are replaced with packaged-staging.
* Change the nativesdk layout to match our usual filesystem layout
* Clean up various hardcoded prefix references
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
|
|
cross-canadian packages need to look for their SOLIBS in the nativesdk
sysroot so that dependencies are correctly picked up and meta-toolchains are
correctly built.
Signed-off-by: Joshua Lock <josh@linux.intel.com>
|
|
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
|
