uninative: Add uninative - a way of reusing native/cross over multiple distros
These patches are the start of a new idea, a way of allowing a single set of
cross/native sstate to work over mutliple distros, even old ones.
The assumption is that our own C library is basically up to date. We build
and share a small tarball (~2MB) of a prebuilt copy of this along with a
patchelf binary (which sadly is C++ based so libstdc++ is in there). This
tarball can be generated from our usual SDK generation process through
the supplied recipe, uninative-tarball.
At the start of the build, if its not been extracted into the sysroot, this
tarball is extracted there and configured for the specified path.
When we install binaries from a "uninative" sstate feed, we change the
dynamic loader to point at this dynamic loader and C librbary. This works
exactly the same way as our relocatable SDK does. The only real difference
is a switch to use patchelf, so even if the interpreter section is too small,
it can still adjust the binary.
Right now this implements a working proof of concept. If you build the tarball
and place it at the head of the tree (in COREBASE), you can run a build from
sstate and successfully build packages and construct images.
There is some improvement needed, its hardcoded for x86_64 right now, its trivial
to add 32 bit support too. The tarball isn't fetched right now, there is just a
harcoded path assumption and there is no error handling. I haven't figured
out the best delivery mechanism for that yet. BuildStarted is probably not
the right event to hook on either.
I've merged this to illustrate how with a small change, we might make the
native/cross sstate much more reusable and hence improve the accessibility
of lower overhead builds. With this change, its possible the Yocto Project may
be able to support a configured sstate mirror out the box. This also has
positive implications for our developer workflow/SDK improvements.
(From OE-Core rev: e66c96ae9c7ba21ebd04a4807390f0031238a85a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-08-28 10:10:06 +00:00
|
|
|
SUMMARY = "libc and patchelf tarball for use with uninative.bbclass"
|
|
|
|
|
LICENSE = "MIT"
|
|
|
|
|
|
|
|
|
|
TOOLCHAIN_TARGET_TASK = ""
|
|
|
|
|
|
2016-03-06 18:33:58 +00:00
|
|
|
# ibm850 - mcopy from mtools
|
|
|
|
|
# iso8859-1 - guile
|
2017-03-23 16:14:16 +00:00
|
|
|
# utf-16, cp1252 - binutils-windres
|
uninative: Add uninative - a way of reusing native/cross over multiple distros
These patches are the start of a new idea, a way of allowing a single set of
cross/native sstate to work over mutliple distros, even old ones.
The assumption is that our own C library is basically up to date. We build
and share a small tarball (~2MB) of a prebuilt copy of this along with a
patchelf binary (which sadly is C++ based so libstdc++ is in there). This
tarball can be generated from our usual SDK generation process through
the supplied recipe, uninative-tarball.
At the start of the build, if its not been extracted into the sysroot, this
tarball is extracted there and configured for the specified path.
When we install binaries from a "uninative" sstate feed, we change the
dynamic loader to point at this dynamic loader and C librbary. This works
exactly the same way as our relocatable SDK does. The only real difference
is a switch to use patchelf, so even if the interpreter section is too small,
it can still adjust the binary.
Right now this implements a working proof of concept. If you build the tarball
and place it at the head of the tree (in COREBASE), you can run a build from
sstate and successfully build packages and construct images.
There is some improvement needed, its hardcoded for x86_64 right now, its trivial
to add 32 bit support too. The tarball isn't fetched right now, there is just a
harcoded path assumption and there is no error handling. I haven't figured
out the best delivery mechanism for that yet. BuildStarted is probably not
the right event to hook on either.
I've merged this to illustrate how with a small change, we might make the
native/cross sstate much more reusable and hence improve the accessibility
of lower overhead builds. With this change, its possible the Yocto Project may
be able to support a configured sstate mirror out the box. This also has
positive implications for our developer workflow/SDK improvements.
(From OE-Core rev: e66c96ae9c7ba21ebd04a4807390f0031238a85a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-08-28 10:10:06 +00:00
|
|
|
TOOLCHAIN_HOST_TASK = "\
|
2014-10-02 09:57:25 +00:00
|
|
|
nativesdk-glibc \
|
2015-10-19 05:27:02 +00:00
|
|
|
nativesdk-glibc-gconv-ibm850 \
|
2016-03-06 18:33:58 +00:00
|
|
|
nativesdk-glibc-gconv-iso8859-1 \
|
2017-03-23 16:14:16 +00:00
|
|
|
nativesdk-glibc-gconv-utf-16 \
|
|
|
|
|
nativesdk-glibc-gconv-cp1252 \
|
uninative: Add uninative - a way of reusing native/cross over multiple distros
These patches are the start of a new idea, a way of allowing a single set of
cross/native sstate to work over mutliple distros, even old ones.
The assumption is that our own C library is basically up to date. We build
and share a small tarball (~2MB) of a prebuilt copy of this along with a
patchelf binary (which sadly is C++ based so libstdc++ is in there). This
tarball can be generated from our usual SDK generation process through
the supplied recipe, uninative-tarball.
At the start of the build, if its not been extracted into the sysroot, this
tarball is extracted there and configured for the specified path.
When we install binaries from a "uninative" sstate feed, we change the
dynamic loader to point at this dynamic loader and C librbary. This works
exactly the same way as our relocatable SDK does. The only real difference
is a switch to use patchelf, so even if the interpreter section is too small,
it can still adjust the binary.
Right now this implements a working proof of concept. If you build the tarball
and place it at the head of the tree (in COREBASE), you can run a build from
sstate and successfully build packages and construct images.
There is some improvement needed, its hardcoded for x86_64 right now, its trivial
to add 32 bit support too. The tarball isn't fetched right now, there is just a
harcoded path assumption and there is no error handling. I haven't figured
out the best delivery mechanism for that yet. BuildStarted is probably not
the right event to hook on either.
I've merged this to illustrate how with a small change, we might make the
native/cross sstate much more reusable and hence improve the accessibility
of lower overhead builds. With this change, its possible the Yocto Project may
be able to support a configured sstate mirror out the box. This also has
positive implications for our developer workflow/SDK improvements.
(From OE-Core rev: e66c96ae9c7ba21ebd04a4807390f0031238a85a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-08-28 10:10:06 +00:00
|
|
|
nativesdk-patchelf \
|
|
|
|
|
"
|
|
|
|
|
|
|
|
|
|
INHIBIT_DEFAULT_DEPS = "1"
|
|
|
|
|
|
2016-09-02 22:47:54 +00:00
|
|
|
MULTIMACH_TARGET_SYS = "${SDK_ARCH}-nativesdk${SDK_VENDOR}-${SDK_OS}"
|
2016-09-23 17:05:16 +00:00
|
|
|
PACKAGE_ARCH = "${SDK_ARCH}_${SDK_OS}"
|
2016-09-21 23:24:03 +00:00
|
|
|
PACKAGE_ARCHS = ""
|
|
|
|
|
TARGET_ARCH = "none"
|
|
|
|
|
TARGET_OS = "none"
|
2016-09-02 22:47:54 +00:00
|
|
|
|
2016-02-25 16:59:39 +00:00
|
|
|
TOOLCHAIN_OUTPUTNAME ?= "${SDK_ARCH}-nativesdk-libc"
|
uninative: Add uninative - a way of reusing native/cross over multiple distros
These patches are the start of a new idea, a way of allowing a single set of
cross/native sstate to work over mutliple distros, even old ones.
The assumption is that our own C library is basically up to date. We build
and share a small tarball (~2MB) of a prebuilt copy of this along with a
patchelf binary (which sadly is C++ based so libstdc++ is in there). This
tarball can be generated from our usual SDK generation process through
the supplied recipe, uninative-tarball.
At the start of the build, if its not been extracted into the sysroot, this
tarball is extracted there and configured for the specified path.
When we install binaries from a "uninative" sstate feed, we change the
dynamic loader to point at this dynamic loader and C librbary. This works
exactly the same way as our relocatable SDK does. The only real difference
is a switch to use patchelf, so even if the interpreter section is too small,
it can still adjust the binary.
Right now this implements a working proof of concept. If you build the tarball
and place it at the head of the tree (in COREBASE), you can run a build from
sstate and successfully build packages and construct images.
There is some improvement needed, its hardcoded for x86_64 right now, its trivial
to add 32 bit support too. The tarball isn't fetched right now, there is just a
harcoded path assumption and there is no error handling. I haven't figured
out the best delivery mechanism for that yet. BuildStarted is probably not
the right event to hook on either.
I've merged this to illustrate how with a small change, we might make the
native/cross sstate much more reusable and hence improve the accessibility
of lower overhead builds. With this change, its possible the Yocto Project may
be able to support a configured sstate mirror out the box. This also has
positive implications for our developer workflow/SDK improvements.
(From OE-Core rev: e66c96ae9c7ba21ebd04a4807390f0031238a85a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-08-28 10:10:06 +00:00
|
|
|
|
|
|
|
|
RDEPENDS = "${TOOLCHAIN_HOST_TASK}"
|
|
|
|
|
|
|
|
|
|
EXCLUDE_FROM_WORLD = "1"
|
|
|
|
|
|
|
|
|
|
inherit meta
|
|
|
|
|
inherit populate_sdk
|
2016-09-21 23:24:03 +00:00
|
|
|
inherit nopackages
|
uninative: Add uninative - a way of reusing native/cross over multiple distros
These patches are the start of a new idea, a way of allowing a single set of
cross/native sstate to work over mutliple distros, even old ones.
The assumption is that our own C library is basically up to date. We build
and share a small tarball (~2MB) of a prebuilt copy of this along with a
patchelf binary (which sadly is C++ based so libstdc++ is in there). This
tarball can be generated from our usual SDK generation process through
the supplied recipe, uninative-tarball.
At the start of the build, if its not been extracted into the sysroot, this
tarball is extracted there and configured for the specified path.
When we install binaries from a "uninative" sstate feed, we change the
dynamic loader to point at this dynamic loader and C librbary. This works
exactly the same way as our relocatable SDK does. The only real difference
is a switch to use patchelf, so even if the interpreter section is too small,
it can still adjust the binary.
Right now this implements a working proof of concept. If you build the tarball
and place it at the head of the tree (in COREBASE), you can run a build from
sstate and successfully build packages and construct images.
There is some improvement needed, its hardcoded for x86_64 right now, its trivial
to add 32 bit support too. The tarball isn't fetched right now, there is just a
harcoded path assumption and there is no error handling. I haven't figured
out the best delivery mechanism for that yet. BuildStarted is probably not
the right event to hook on either.
I've merged this to illustrate how with a small change, we might make the
native/cross sstate much more reusable and hence improve the accessibility
of lower overhead builds. With this change, its possible the Yocto Project may
be able to support a configured sstate mirror out the box. This also has
positive implications for our developer workflow/SDK improvements.
(From OE-Core rev: e66c96ae9c7ba21ebd04a4807390f0031238a85a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-08-28 10:10:06 +00:00
|
|
|
|
|
|
|
|
deltask install
|
|
|
|
|
deltask package
|
2015-04-24 06:05:30 +00:00
|
|
|
deltask packagedata
|
2016-09-21 23:24:03 +00:00
|
|
|
deltask populate_sysroot
|
uninative: Add uninative - a way of reusing native/cross over multiple distros
These patches are the start of a new idea, a way of allowing a single set of
cross/native sstate to work over mutliple distros, even old ones.
The assumption is that our own C library is basically up to date. We build
and share a small tarball (~2MB) of a prebuilt copy of this along with a
patchelf binary (which sadly is C++ based so libstdc++ is in there). This
tarball can be generated from our usual SDK generation process through
the supplied recipe, uninative-tarball.
At the start of the build, if its not been extracted into the sysroot, this
tarball is extracted there and configured for the specified path.
When we install binaries from a "uninative" sstate feed, we change the
dynamic loader to point at this dynamic loader and C librbary. This works
exactly the same way as our relocatable SDK does. The only real difference
is a switch to use patchelf, so even if the interpreter section is too small,
it can still adjust the binary.
Right now this implements a working proof of concept. If you build the tarball
and place it at the head of the tree (in COREBASE), you can run a build from
sstate and successfully build packages and construct images.
There is some improvement needed, its hardcoded for x86_64 right now, its trivial
to add 32 bit support too. The tarball isn't fetched right now, there is just a
harcoded path assumption and there is no error handling. I haven't figured
out the best delivery mechanism for that yet. BuildStarted is probably not
the right event to hook on either.
I've merged this to illustrate how with a small change, we might make the
native/cross sstate much more reusable and hence improve the accessibility
of lower overhead builds. With this change, its possible the Yocto Project may
be able to support a configured sstate mirror out the box. This also has
positive implications for our developer workflow/SDK improvements.
(From OE-Core rev: e66c96ae9c7ba21ebd04a4807390f0031238a85a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-08-28 10:10:06 +00:00
|
|
|
|
2016-09-23 17:05:16 +00:00
|
|
|
do_populate_sdk[stamp-extra-info] = "${PACKAGE_ARCH}"
|
2016-09-02 22:47:54 +00:00
|
|
|
|
2015-03-24 22:17:10 +00:00
|
|
|
SDK_DEPENDS += "patchelf-native"
|
|
|
|
|
|
uninative: Add uninative - a way of reusing native/cross over multiple distros
These patches are the start of a new idea, a way of allowing a single set of
cross/native sstate to work over mutliple distros, even old ones.
The assumption is that our own C library is basically up to date. We build
and share a small tarball (~2MB) of a prebuilt copy of this along with a
patchelf binary (which sadly is C++ based so libstdc++ is in there). This
tarball can be generated from our usual SDK generation process through
the supplied recipe, uninative-tarball.
At the start of the build, if its not been extracted into the sysroot, this
tarball is extracted there and configured for the specified path.
When we install binaries from a "uninative" sstate feed, we change the
dynamic loader to point at this dynamic loader and C librbary. This works
exactly the same way as our relocatable SDK does. The only real difference
is a switch to use patchelf, so even if the interpreter section is too small,
it can still adjust the binary.
Right now this implements a working proof of concept. If you build the tarball
and place it at the head of the tree (in COREBASE), you can run a build from
sstate and successfully build packages and construct images.
There is some improvement needed, its hardcoded for x86_64 right now, its trivial
to add 32 bit support too. The tarball isn't fetched right now, there is just a
harcoded path assumption and there is no error handling. I haven't figured
out the best delivery mechanism for that yet. BuildStarted is probably not
the right event to hook on either.
I've merged this to illustrate how with a small change, we might make the
native/cross sstate much more reusable and hence improve the accessibility
of lower overhead builds. With this change, its possible the Yocto Project may
be able to support a configured sstate mirror out the box. This also has
positive implications for our developer workflow/SDK improvements.
(From OE-Core rev: e66c96ae9c7ba21ebd04a4807390f0031238a85a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-08-28 10:10:06 +00:00
|
|
|
SDK_PACKAGING_FUNC = ""
|
2016-09-21 23:24:03 +00:00
|
|
|
REAL_MULTIMACH_TARGET_SYS = "none"
|
uninative: Add uninative - a way of reusing native/cross over multiple distros
These patches are the start of a new idea, a way of allowing a single set of
cross/native sstate to work over mutliple distros, even old ones.
The assumption is that our own C library is basically up to date. We build
and share a small tarball (~2MB) of a prebuilt copy of this along with a
patchelf binary (which sadly is C++ based so libstdc++ is in there). This
tarball can be generated from our usual SDK generation process through
the supplied recipe, uninative-tarball.
At the start of the build, if its not been extracted into the sysroot, this
tarball is extracted there and configured for the specified path.
When we install binaries from a "uninative" sstate feed, we change the
dynamic loader to point at this dynamic loader and C librbary. This works
exactly the same way as our relocatable SDK does. The only real difference
is a switch to use patchelf, so even if the interpreter section is too small,
it can still adjust the binary.
Right now this implements a working proof of concept. If you build the tarball
and place it at the head of the tree (in COREBASE), you can run a build from
sstate and successfully build packages and construct images.
There is some improvement needed, its hardcoded for x86_64 right now, its trivial
to add 32 bit support too. The tarball isn't fetched right now, there is just a
harcoded path assumption and there is no error handling. I haven't figured
out the best delivery mechanism for that yet. BuildStarted is probably not
the right event to hook on either.
I've merged this to illustrate how with a small change, we might make the
native/cross sstate much more reusable and hence improve the accessibility
of lower overhead builds. With this change, its possible the Yocto Project may
be able to support a configured sstate mirror out the box. This also has
positive implications for our developer workflow/SDK improvements.
(From OE-Core rev: e66c96ae9c7ba21ebd04a4807390f0031238a85a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-08-28 10:10:06 +00:00
|
|
|
|
|
|
|
|
fakeroot create_sdk_files() {
|
|
|
|
|
cp ${COREBASE}/scripts/relocate_sdk.py ${SDK_OUTPUT}/${SDKPATH}/
|
|
|
|
|
|
|
|
|
|
# Replace the ##DEFAULT_INSTALL_DIR## with the correct pattern.
|
|
|
|
|
# Escape special characters like '+' and '.' in the SDKPATH
|
|
|
|
|
escaped_sdkpath=$(echo ${SDKPATH}/sysroots/${SDK_SYS} |sed -e "s:[\+\.]:\\\\\\\\\0:g")
|
|
|
|
|
sed -i -e "s:##DEFAULT_INSTALL_DIR##:$escaped_sdkpath:" ${SDK_OUTPUT}/${SDKPATH}/relocate_sdk.py
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
fakeroot tar_sdk() {
|
|
|
|
|
cd ${SDK_OUTPUT}/${SDKPATH}
|
2016-02-25 16:59:39 +00:00
|
|
|
|
|
|
|
|
DEST="./${SDK_ARCH}-${SDK_OS}"
|
|
|
|
|
mv sysroots/${SDK_SYS} $DEST
|
uninative: Add uninative - a way of reusing native/cross over multiple distros
These patches are the start of a new idea, a way of allowing a single set of
cross/native sstate to work over mutliple distros, even old ones.
The assumption is that our own C library is basically up to date. We build
and share a small tarball (~2MB) of a prebuilt copy of this along with a
patchelf binary (which sadly is C++ based so libstdc++ is in there). This
tarball can be generated from our usual SDK generation process through
the supplied recipe, uninative-tarball.
At the start of the build, if its not been extracted into the sysroot, this
tarball is extracted there and configured for the specified path.
When we install binaries from a "uninative" sstate feed, we change the
dynamic loader to point at this dynamic loader and C librbary. This works
exactly the same way as our relocatable SDK does. The only real difference
is a switch to use patchelf, so even if the interpreter section is too small,
it can still adjust the binary.
Right now this implements a working proof of concept. If you build the tarball
and place it at the head of the tree (in COREBASE), you can run a build from
sstate and successfully build packages and construct images.
There is some improvement needed, its hardcoded for x86_64 right now, its trivial
to add 32 bit support too. The tarball isn't fetched right now, there is just a
harcoded path assumption and there is no error handling. I haven't figured
out the best delivery mechanism for that yet. BuildStarted is probably not
the right event to hook on either.
I've merged this to illustrate how with a small change, we might make the
native/cross sstate much more reusable and hence improve the accessibility
of lower overhead builds. With this change, its possible the Yocto Project may
be able to support a configured sstate mirror out the box. This also has
positive implications for our developer workflow/SDK improvements.
(From OE-Core rev: e66c96ae9c7ba21ebd04a4807390f0031238a85a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-08-28 10:10:06 +00:00
|
|
|
rm sysroots -rf
|
2016-05-20 10:56:05 +00:00
|
|
|
patchelf --set-interpreter ${@''.join('a' for n in range(1024))} $DEST/usr/bin/patchelf
|
2016-02-25 16:59:39 +00:00
|
|
|
mv $DEST/usr/bin/patchelf $DEST/usr/bin/patchelf-uninative
|
2016-09-02 22:47:54 +00:00
|
|
|
tar ${SDKTAROPTS} -c -j --file=${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.tar.bz2 .
|
uninative: Add uninative - a way of reusing native/cross over multiple distros
These patches are the start of a new idea, a way of allowing a single set of
cross/native sstate to work over mutliple distros, even old ones.
The assumption is that our own C library is basically up to date. We build
and share a small tarball (~2MB) of a prebuilt copy of this along with a
patchelf binary (which sadly is C++ based so libstdc++ is in there). This
tarball can be generated from our usual SDK generation process through
the supplied recipe, uninative-tarball.
At the start of the build, if its not been extracted into the sysroot, this
tarball is extracted there and configured for the specified path.
When we install binaries from a "uninative" sstate feed, we change the
dynamic loader to point at this dynamic loader and C librbary. This works
exactly the same way as our relocatable SDK does. The only real difference
is a switch to use patchelf, so even if the interpreter section is too small,
it can still adjust the binary.
Right now this implements a working proof of concept. If you build the tarball
and place it at the head of the tree (in COREBASE), you can run a build from
sstate and successfully build packages and construct images.
There is some improvement needed, its hardcoded for x86_64 right now, its trivial
to add 32 bit support too. The tarball isn't fetched right now, there is just a
harcoded path assumption and there is no error handling. I haven't figured
out the best delivery mechanism for that yet. BuildStarted is probably not
the right event to hook on either.
I've merged this to illustrate how with a small change, we might make the
native/cross sstate much more reusable and hence improve the accessibility
of lower overhead builds. With this change, its possible the Yocto Project may
be able to support a configured sstate mirror out the box. This also has
positive implications for our developer workflow/SDK improvements.
(From OE-Core rev: e66c96ae9c7ba21ebd04a4807390f0031238a85a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-08-28 10:10:06 +00:00
|
|
|
}
|
