* [PATCH/RFC] zlib: convert to BBCLASSEXTEND
@ 2010-03-11 23:13 Scott Garman
2010-03-12 0:18 ` Khem Raj
2010-03-24 3:06 ` BBCLASSEXTEND sdk vs. nativesdk Scott Garman
0 siblings, 2 replies; 17+ messages in thread
From: Scott Garman @ 2010-03-11 23:13 UTC (permalink / raw)
To: openembedded-devel
[-- Attachment #1: Type: text/plain, Size: 363 bytes --]
Hi all,
Attached is my first OE patch submission, to convert the zlib recipe to
use BBCLASSEXTEND and cleanup the do_stage() task.
I would like to start making regular contributions to OE, and am
starting with the basics. Any guidance from the more experienced folks
is gratefully accepted.
Scott
--
Scott Garman
sgarman at zenlinux dot com
[-- Attachment #2: zlib_bbclassextend.patch --]
[-- Type: text/x-patch, Size: 1312 bytes --]
commit 803f864960dcf58abc03003b2e3e62f2f26230f3
Author: Scott Garman <sgarman@zenlinux.com>
Date: Thu Mar 11 15:01:59 2010 -0800
Convert zlib recipe to use BBCLASSEXTEND and remove do_stage task.
diff --git a/recipes/zlib/zlib-native_1.2.3.bb b/recipes/zlib/zlib-native_1.2.3.bb
deleted file mode 100644
index d7e0777..0000000
--- a/recipes/zlib/zlib-native_1.2.3.bb
+++ /dev/null
@@ -1,5 +0,0 @@
-require zlib_${PV}.bb
-ZLIB_EXTRA = ""
-DEPENDS = "libtool-native"
-
-inherit native
diff --git a/recipes/zlib/zlib-sdk_1.2.3.bb b/recipes/zlib/zlib-sdk_1.2.3.bb
deleted file mode 100644
index 4863395..0000000
--- a/recipes/zlib/zlib-sdk_1.2.3.bb
+++ /dev/null
@@ -1,4 +0,0 @@
-require zlib_${PV}.bb
-LIB_EXTRA = ""
-
-inherit sdk
diff --git a/recipes/zlib/zlib_1.2.3.bb b/recipes/zlib/zlib_1.2.3.bb
index d995869..db4b16b 100644
--- a/recipes/zlib/zlib_1.2.3.bb
+++ b/recipes/zlib/zlib_1.2.3.bb
@@ -3,7 +3,7 @@ SECTION = "libs"
PRIORITY = "required"
HOMEPAGE = "http://www.gzip.org/zlib/"
LICENSE = "zlib"
-PR ="r5"
+PR ="r6"
SRC_URI = "http://www.zlib.net/zlib-1.2.3.tar.bz2 \
file://visibility.patch;patch=1 \
@@ -15,6 +15,4 @@ DEPENDS = "libtool-cross"
inherit autotools
-do_stage() {
- autotools_stage_all
-}
+BBCLASSEXTEND = "native sdk"
^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH/RFC] zlib: convert to BBCLASSEXTEND
2010-03-11 23:13 [PATCH/RFC] zlib: convert to BBCLASSEXTEND Scott Garman
@ 2010-03-12 0:18 ` Khem Raj
2010-03-12 3:26 ` Scott Garman
2010-03-24 3:06 ` BBCLASSEXTEND sdk vs. nativesdk Scott Garman
1 sibling, 1 reply; 17+ messages in thread
From: Khem Raj @ 2010-03-12 0:18 UTC (permalink / raw)
To: openembedded-devel
On Thu, Mar 11, 2010 at 3:13 PM, Scott Garman <sgarman@zenlinux.com> wrote:
> Hi all,
>
> Attached is my first OE patch submission, to convert the zlib recipe to use
> BBCLASSEXTEND and cleanup the do_stage() task.
>
> I would like to start making regular contributions to OE, and am starting
> with the basics. Any guidance from the more experienced folks is gratefully
> accepted.
Thanks for the patch. While this change looks ok. You should submit a full patch
where you also delete the unneeded recipes and with proper sign-off
http://wiki.openembedded.net/index.php/Commit_Policy
http://wiki.openembedded.net/index.php/Commit_log_example
might help
and also formatting patch with git format-patch would be nice.
Thanks
-Khem
>
> Scott
>
> --
> Scott Garman
> sgarman at zenlinux dot com
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH/RFC] zlib: convert to BBCLASSEXTEND
2010-03-12 0:18 ` Khem Raj
@ 2010-03-12 3:26 ` Scott Garman
2010-03-12 3:28 ` Scott Garman
2010-03-12 20:39 ` Khem Raj
0 siblings, 2 replies; 17+ messages in thread
From: Scott Garman @ 2010-03-12 3:26 UTC (permalink / raw)
To: openembedded-devel
[-- Attachment #1: Type: text/plain, Size: 659 bytes --]
On 03/11/2010 04:18 PM, Khem Raj wrote:
> Thanks for the patch. While this change looks ok. You should submit a full patch
> where you also delete the unneeded recipes and with proper sign-off
>
> http://wiki.openembedded.net/index.php/Commit_Policy
> http://wiki.openembedded.net/index.php/Commit_log_example
>
> might help
>
> and also formatting patch with git format-patch would be nice.
Gotcha, thanks for the feedback. Let's try this then. In the future I
assume the format-patch email should be sent directly to the list and
not as an attachment - correct me if I'm mistaken.
Scott
--
Scott Garman
sgarman at zenlinux dot com
[-- Attachment #2: 0001-zlib-convert-to-new-style-staging-and-BBCLASSEXTEND.patch --]
[-- Type: text/x-patch, Size: 1658 bytes --]
From 322589252447f6bb4a96b79b5495001f6cb64f12 Mon Sep 17 00:00:00 2001
From: Scott Garman <sgarman@zenlinux.com>
Date: Thu, 11 Mar 2010 19:15:29 -0800
Subject: [PATCH] zlib: convert to new style staging and BBCLASSEXTEND
---
recipes/zlib/zlib-native_1.2.3.bb | 5 -----
recipes/zlib/zlib-sdk_1.2.3.bb | 4 ----
recipes/zlib/zlib_1.2.3.bb | 6 ++----
3 files changed, 2 insertions(+), 13 deletions(-)
delete mode 100644 recipes/zlib/zlib-native_1.2.3.bb
delete mode 100644 recipes/zlib/zlib-sdk_1.2.3.bb
diff --git a/recipes/zlib/zlib-native_1.2.3.bb b/recipes/zlib/zlib-native_1.2.3.bb
deleted file mode 100644
index d7e0777..0000000
--- a/recipes/zlib/zlib-native_1.2.3.bb
+++ /dev/null
@@ -1,5 +0,0 @@
-require zlib_${PV}.bb
-ZLIB_EXTRA = ""
-DEPENDS = "libtool-native"
-
-inherit native
diff --git a/recipes/zlib/zlib-sdk_1.2.3.bb b/recipes/zlib/zlib-sdk_1.2.3.bb
deleted file mode 100644
index 4863395..0000000
--- a/recipes/zlib/zlib-sdk_1.2.3.bb
+++ /dev/null
@@ -1,4 +0,0 @@
-require zlib_${PV}.bb
-LIB_EXTRA = ""
-
-inherit sdk
diff --git a/recipes/zlib/zlib_1.2.3.bb b/recipes/zlib/zlib_1.2.3.bb
index d995869..db4b16b 100644
--- a/recipes/zlib/zlib_1.2.3.bb
+++ b/recipes/zlib/zlib_1.2.3.bb
@@ -3,7 +3,7 @@ SECTION = "libs"
PRIORITY = "required"
HOMEPAGE = "http://www.gzip.org/zlib/"
LICENSE = "zlib"
-PR ="r5"
+PR ="r6"
SRC_URI = "http://www.zlib.net/zlib-1.2.3.tar.bz2 \
file://visibility.patch;patch=1 \
@@ -15,6 +15,4 @@ DEPENDS = "libtool-cross"
inherit autotools
-do_stage() {
- autotools_stage_all
-}
+BBCLASSEXTEND = "native sdk"
--
1.6.3.3
^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH/RFC] zlib: convert to BBCLASSEXTEND
2010-03-12 3:26 ` Scott Garman
@ 2010-03-12 3:28 ` Scott Garman
2010-03-12 20:39 ` Khem Raj
1 sibling, 0 replies; 17+ messages in thread
From: Scott Garman @ 2010-03-12 3:28 UTC (permalink / raw)
To: openembedded-devel
[-- Attachment #1: Type: text/plain, Size: 378 bytes --]
On 03/11/2010 07:26 PM, Scott Garman wrote:
> Gotcha, thanks for the feedback. Let's try this then. In the future I
> assume the format-patch email should be sent directly to the list and
> not as an attachment - correct me if I'm mistaken.
...and it would be helpful if I actually included the patch this time.
Scott
--
Scott Garman
sgarman at zenlinux dot com
[-- Attachment #2: 0001-zlib-convert-to-new-style-staging-and-BBCLASSEXTEND.patch --]
[-- Type: text/x-patch, Size: 1658 bytes --]
From 322589252447f6bb4a96b79b5495001f6cb64f12 Mon Sep 17 00:00:00 2001
From: Scott Garman <sgarman@zenlinux.com>
Date: Thu, 11 Mar 2010 19:15:29 -0800
Subject: [PATCH] zlib: convert to new style staging and BBCLASSEXTEND
---
recipes/zlib/zlib-native_1.2.3.bb | 5 -----
recipes/zlib/zlib-sdk_1.2.3.bb | 4 ----
recipes/zlib/zlib_1.2.3.bb | 6 ++----
3 files changed, 2 insertions(+), 13 deletions(-)
delete mode 100644 recipes/zlib/zlib-native_1.2.3.bb
delete mode 100644 recipes/zlib/zlib-sdk_1.2.3.bb
diff --git a/recipes/zlib/zlib-native_1.2.3.bb b/recipes/zlib/zlib-native_1.2.3.bb
deleted file mode 100644
index d7e0777..0000000
--- a/recipes/zlib/zlib-native_1.2.3.bb
+++ /dev/null
@@ -1,5 +0,0 @@
-require zlib_${PV}.bb
-ZLIB_EXTRA = ""
-DEPENDS = "libtool-native"
-
-inherit native
diff --git a/recipes/zlib/zlib-sdk_1.2.3.bb b/recipes/zlib/zlib-sdk_1.2.3.bb
deleted file mode 100644
index 4863395..0000000
--- a/recipes/zlib/zlib-sdk_1.2.3.bb
+++ /dev/null
@@ -1,4 +0,0 @@
-require zlib_${PV}.bb
-LIB_EXTRA = ""
-
-inherit sdk
diff --git a/recipes/zlib/zlib_1.2.3.bb b/recipes/zlib/zlib_1.2.3.bb
index d995869..db4b16b 100644
--- a/recipes/zlib/zlib_1.2.3.bb
+++ b/recipes/zlib/zlib_1.2.3.bb
@@ -3,7 +3,7 @@ SECTION = "libs"
PRIORITY = "required"
HOMEPAGE = "http://www.gzip.org/zlib/"
LICENSE = "zlib"
-PR ="r5"
+PR ="r6"
SRC_URI = "http://www.zlib.net/zlib-1.2.3.tar.bz2 \
file://visibility.patch;patch=1 \
@@ -15,6 +15,4 @@ DEPENDS = "libtool-cross"
inherit autotools
-do_stage() {
- autotools_stage_all
-}
+BBCLASSEXTEND = "native sdk"
--
1.6.3.3
^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH/RFC] zlib: convert to BBCLASSEXTEND
2010-03-12 3:26 ` Scott Garman
2010-03-12 3:28 ` Scott Garman
@ 2010-03-12 20:39 ` Khem Raj
1 sibling, 0 replies; 17+ messages in thread
From: Khem Raj @ 2010-03-12 20:39 UTC (permalink / raw)
To: openembedded-devel
On Thu, Mar 11, 2010 at 7:26 PM, Scott Garman <sgarman@zenlinux.com> wrote:
> On 03/11/2010 04:18 PM, Khem Raj wrote:
>>
>> Thanks for the patch. While this change looks ok. You should submit a full
>> patch
>> where you also delete the unneeded recipes and with proper sign-off
>>
>> http://wiki.openembedded.net/index.php/Commit_Policy
>> http://wiki.openembedded.net/index.php/Commit_log_example
>>
>> might help
>>
>> and also formatting patch with git format-patch would be nice.
>
> Gotcha, thanks for the feedback. Let's try this then. In the future I assume
> the format-patch email should be sent directly to the list and not as an
> attachment - correct me if I'm mistaken.
yeah you could use git send-email
>
> Scott
>
> --
> Scott Garman
> sgarman at zenlinux dot com
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* BBCLASSEXTEND sdk vs. nativesdk
2010-03-11 23:13 [PATCH/RFC] zlib: convert to BBCLASSEXTEND Scott Garman
2010-03-12 0:18 ` Khem Raj
@ 2010-03-24 3:06 ` Scott Garman
2010-03-24 5:45 ` Khem Raj
1 sibling, 1 reply; 17+ messages in thread
From: Scott Garman @ 2010-03-24 3:06 UTC (permalink / raw)
To: openembedded-devel
Hi all,
I noticed in my attempt to convert zlib to use BBCLASSEXTEND that
sdk.bbclass has been deprecated, and that the new way is to use
nativesdk.bbclass. This is confirmed by the fact that the Poky recipe
for zlib uses:
BBCLASSEXTEND = "native nativesdk"
However, if I use this in the OE recipe, bitbake no longer knows how to
build zlib-sdk. And zlib-sdk is listed in DEPENDS in a small handful of
packages.
It seems to me the correct course of action is to use nativesdk in
BBCLASSEXTEND and rename the dependencies on other recipes, yes?
Thanks,
Scott
--
Scott Garman
sgarman at zenlinux dot com
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: BBCLASSEXTEND sdk vs. nativesdk
2010-03-24 3:06 ` BBCLASSEXTEND sdk vs. nativesdk Scott Garman
@ 2010-03-24 5:45 ` Khem Raj
2010-03-24 6:42 ` Scott Garman
0 siblings, 1 reply; 17+ messages in thread
From: Khem Raj @ 2010-03-24 5:45 UTC (permalink / raw)
To: openembedded-devel
On Tue, Mar 23, 2010 at 8:06 PM, Scott Garman <sgarman@zenlinux.com> wrote:
> Hi all,
>
> I noticed in my attempt to convert zlib to use BBCLASSEXTEND that
> sdk.bbclass has been deprecated, and that the new way is to use
> nativesdk.bbclass. This is confirmed by the fact that the Poky recipe for
> zlib uses:
>
> BBCLASSEXTEND = "native nativesdk"
>
> However, if I use this in the OE recipe, bitbake no longer knows how to
> build zlib-sdk. And zlib-sdk is listed in DEPENDS in a small handful of
> packages.
>
> It seems to me the correct course of action is to use nativesdk in
> BBCLASSEXTEND and rename the dependencies on other recipes, yes?
you should rename the dependencies on zlib-sdk to zlib-nativesdk
wherever they exist.
>
> Thanks,
>
> Scott
>
> --
> Scott Garman
> sgarman at zenlinux dot com
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: BBCLASSEXTEND sdk vs. nativesdk
2010-03-24 5:45 ` Khem Raj
@ 2010-03-24 6:42 ` Scott Garman
2010-03-24 10:28 ` Richard Purdie
0 siblings, 1 reply; 17+ messages in thread
From: Scott Garman @ 2010-03-24 6:42 UTC (permalink / raw)
To: openembedded-devel
On 03/23/2010 10:45 PM, Khem Raj wrote:
>> It seems to me the correct course of action is to use nativesdk in
>> BBCLASSEXTEND and rename the dependencies on other recipes, yes?
>
> you should rename the dependencies on zlib-sdk to zlib-nativesdk
> wherever they exist.
Khem: Thanks for the confirmation.
I am running into some problems now trying to get zlib-nativesdk to
build. If I change the recipe to use sdk, it builds fine, so I have
something useful to compare things to.
When I build using nativesdk, configure dies pretty quickly when testing
the compiler. It's trying to run i686-linux-gcc.
Sure enough, if I compare the BitBake environments using the -e option,
I see that CC is being set to "gcc" when I use sdk but "i686-linux-gcc"
when I use nativesdk.
If I create the needed symlink to gcc, the compilation gets further but
still fails, wanting i686-linux-ar, etc. So I have a basic understanding
of what the problem is, but I'm sure the solution is not to go symlink
crazy with my native compiler environment.
So I took a look at sdk.bbclass and nativesdk.bbclass. They both set up
a number of architecture-specific variables, but neither of them
explicitly set CC. Where I should look next?
It turns out there is only one package currently in OE that uses
BBCLASSEXTEND with nativesdk (gettext_0.17). So perhaps it is the case
that nativesdk.bbclass needs additional work. I did test copying over
Poky's nativesdk.bbclass (which has just a few differences), but I still
get the same results.
Thanks,
Scott
--
Scott Garman
sgarman at zenlinux dot com
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: BBCLASSEXTEND sdk vs. nativesdk
2010-03-24 6:42 ` Scott Garman
@ 2010-03-24 10:28 ` Richard Purdie
2010-03-24 10:53 ` jkridner
2010-03-24 15:27 ` Tom Rini
0 siblings, 2 replies; 17+ messages in thread
From: Richard Purdie @ 2010-03-24 10:28 UTC (permalink / raw)
To: openembedded-devel
On Tue, 2010-03-23 at 23:42 -0700, Scott Garman wrote:
> On 03/23/2010 10:45 PM, Khem Raj wrote:
> >> It seems to me the correct course of action is to use nativesdk in
> >> BBCLASSEXTEND and rename the dependencies on other recipes, yes?
> >
> > you should rename the dependencies on zlib-sdk to zlib-nativesdk
> > wherever they exist.
This isn't quite correct. nativesdk is not a drop in replacement for the
old sdk but you are right that is is the replacement.
The difference is that the old "sdk" assumes the system you want the sdk
to run on is the same as the build system. This has always been a big
can of worms causing problems so "nativesdk" removes this assumption and
allows you to set SDKMACHINE to be the machine you want the resulting
sdk to run on.
This adds some complexity since we need another cross compiling
toolchain. But cross compiling toolchains are something we're good
at :). It also means we ship *everything* with the sdk including a
standalone glibc massively removing system dependencies from the result
which in my opinion can only be a good thing.
"sdk" and "nativesdk" are designed to coexist and the idea is that we
add "nativesdk" to OE alongside "sdk", get it working, then remove the
old broken "sdk" stuff.
In theory you can therefore just add the BBCLASSEXTEND line to the zlib
recipe and work backwards from there. You will need a working -crosssdk
version of gcc to provide the different compiler.
> I am running into some problems now trying to get zlib-nativesdk to
> build. If I change the recipe to use sdk, it builds fine, so I have
> something useful to compare things to.
>
> When I build using nativesdk, configure dies pretty quickly when testing
> the compiler. It's trying to run i686-linux-gcc.
>
> Sure enough, if I compare the BitBake environments using the -e option,
> I see that CC is being set to "gcc" when I use sdk but "i686-linux-gcc"
> when I use nativesdk.
>
> If I create the needed symlink to gcc, the compilation gets further but
> still fails, wanting i686-linux-ar, etc. So I have a basic understanding
> of what the problem is, but I'm sure the solution is not to go symlink
> crazy with my native compiler environment.
See above, its missing the -crosssdk cross compiler. Did you not have to
ASSUME_PROVIDED something to make the dependencies work?
> So I took a look at sdk.bbclass and nativesdk.bbclass. They both set up
> a number of architecture-specific variables, but neither of them
> explicitly set CC. Where I should look next?
>
> It turns out there is only one package currently in OE that uses
> BBCLASSEXTEND with nativesdk (gettext_0.17). So perhaps it is the case
> that nativesdk.bbclass needs additional work. I did test copying over
> Poky's nativesdk.bbclass (which has just a few differences), but I still
> get the same results.
We probably need those differences in OE. Its nice to see someone
looking at this!
Cheers,
Richard
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: BBCLASSEXTEND sdk vs. nativesdk
2010-03-24 10:28 ` Richard Purdie
@ 2010-03-24 10:53 ` jkridner
2010-03-24 19:27 ` Denys Dmytriyenko
2010-03-24 15:27 ` Tom Rini
1 sibling, 1 reply; 17+ messages in thread
From: jkridner @ 2010-03-24 10:53 UTC (permalink / raw)
To: openembedded-devel
Is this also the mechanism for building an sdk for the target then? Seems great to normalize this.
If I wanted to build a MIPS cross-compiler that ran on an ARM board, and build that from an x86 machine, what would it look like given nativesdk?
Sorry for the blackberry top post.
Sent via BlackBerry from T-Mobile
-----Original Message-----
From: Richard Purdie <rpurdie@rpsys.net>
Date: Wed, 24 Mar 2010 10:28:36
To: <openembedded-devel@lists.openembedded.org>
Subject: Re: [oe] BBCLASSEXTEND sdk vs. nativesdk
On Tue, 2010-03-23 at 23:42 -0700, Scott Garman wrote:
> On 03/23/2010 10:45 PM, Khem Raj wrote:
> >> It seems to me the correct course of action is to use nativesdk in
> >> BBCLASSEXTEND and rename the dependencies on other recipes, yes?
> >
> > you should rename the dependencies on zlib-sdk to zlib-nativesdk
> > wherever they exist.
This isn't quite correct. nativesdk is not a drop in replacement for the
old sdk but you are right that is is the replacement.
The difference is that the old "sdk" assumes the system you want the sdk
to run on is the same as the build system. This has always been a big
can of worms causing problems so "nativesdk" removes this assumption and
allows you to set SDKMACHINE to be the machine you want the resulting
sdk to run on.
This adds some complexity since we need another cross compiling
toolchain. But cross compiling toolchains are something we're good
at :). It also means we ship *everything* with the sdk including a
standalone glibc massively removing system dependencies from the result
which in my opinion can only be a good thing.
"sdk" and "nativesdk" are designed to coexist and the idea is that we
add "nativesdk" to OE alongside "sdk", get it working, then remove the
old broken "sdk" stuff.
In theory you can therefore just add the BBCLASSEXTEND line to the zlib
recipe and work backwards from there. You will need a working -crosssdk
version of gcc to provide the different compiler.
> I am running into some problems now trying to get zlib-nativesdk to
> build. If I change the recipe to use sdk, it builds fine, so I have
> something useful to compare things to.
>
> When I build using nativesdk, configure dies pretty quickly when testing
> the compiler. It's trying to run i686-linux-gcc.
>
> Sure enough, if I compare the BitBake environments using the -e option,
> I see that CC is being set to "gcc" when I use sdk but "i686-linux-gcc"
> when I use nativesdk.
>
> If I create the needed symlink to gcc, the compilation gets further but
> still fails, wanting i686-linux-ar, etc. So I have a basic understanding
> of what the problem is, but I'm sure the solution is not to go symlink
> crazy with my native compiler environment.
See above, its missing the -crosssdk cross compiler. Did you not have to
ASSUME_PROVIDED something to make the dependencies work?
> So I took a look at sdk.bbclass and nativesdk.bbclass. They both set up
> a number of architecture-specific variables, but neither of them
> explicitly set CC. Where I should look next?
>
> It turns out there is only one package currently in OE that uses
> BBCLASSEXTEND with nativesdk (gettext_0.17). So perhaps it is the case
> that nativesdk.bbclass needs additional work. I did test copying over
> Poky's nativesdk.bbclass (which has just a few differences), but I still
> get the same results.
We probably need those differences in OE. Its nice to see someone
looking at this!
Cheers,
Richard
_______________________________________________
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: BBCLASSEXTEND sdk vs. nativesdk
2010-03-24 10:28 ` Richard Purdie
2010-03-24 10:53 ` jkridner
@ 2010-03-24 15:27 ` Tom Rini
2010-03-24 15:37 ` Richard Purdie
1 sibling, 1 reply; 17+ messages in thread
From: Tom Rini @ 2010-03-24 15:27 UTC (permalink / raw)
To: openembedded-devel
On Wed, 2010-03-24 at 10:28 +0000, Richard Purdie wrote:
> On Tue, 2010-03-23 at 23:42 -0700, Scott Garman wrote:
> > On 03/23/2010 10:45 PM, Khem Raj wrote:
> > >> It seems to me the correct course of action is to use nativesdk in
> > >> BBCLASSEXTEND and rename the dependencies on other recipes, yes?
> > >
> > > you should rename the dependencies on zlib-sdk to zlib-nativesdk
> > > wherever they exist.
>
> This isn't quite correct. nativesdk is not a drop in replacement for the
> old sdk but you are right that is is the replacement.
>
> The difference is that the old "sdk" assumes the system you want the sdk
> to run on is the same as the build system. This has always been a big
> can of worms causing problems so "nativesdk" removes this assumption and
> allows you to set SDKMACHINE to be the machine you want the resulting
> sdk to run on.
>
> This adds some complexity since we need another cross compiling
> toolchain. But cross compiling toolchains are something we're good
> at :). It also means we ship *everything* with the sdk including a
> standalone glibc massively removing system dependencies from the result
> which in my opinion can only be a good thing.
Or a really bad thing, yes. I think nativesdk will help out a lot for
making canadian style builds cleaner. But going so far as to say 'Oh,
lets just throw a libc into the SDK export' is going pretty far down a
questionable road. I'm not so naive to think that there's not problems
with my next suggestion, but there's this thing called LSB for a reason.
If you want build once, run many distributions, you do that, not go and
own even more dependencies.
--
Tom Rini <tom_rini@mentor.com>
Mentor Graphics Corporation
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: BBCLASSEXTEND sdk vs. nativesdk
2010-03-24 15:27 ` Tom Rini
@ 2010-03-24 15:37 ` Richard Purdie
2010-03-24 15:57 ` Tom Rini
0 siblings, 1 reply; 17+ messages in thread
From: Richard Purdie @ 2010-03-24 15:37 UTC (permalink / raw)
To: openembedded-devel
On Wed, 2010-03-24 at 08:27 -0700, Tom Rini wrote:
> On Wed, 2010-03-24 at 10:28 +0000, Richard Purdie wrote:
> > The difference is that the old "sdk" assumes the system you want the sdk
> > to run on is the same as the build system. This has always been a big
> > can of worms causing problems so "nativesdk" removes this assumption and
> > allows you to set SDKMACHINE to be the machine you want the resulting
> > sdk to run on.
> >
> > This adds some complexity since we need another cross compiling
> > toolchain. But cross compiling toolchains are something we're good
> > at :). It also means we ship *everything* with the sdk including a
> > standalone glibc massively removing system dependencies from the result
> > which in my opinion can only be a good thing.
>
> Or a really bad thing, yes. I think nativesdk will help out a lot for
> making canadian style builds cleaner. But going so far as to say 'Oh,
> lets just throw a libc into the SDK export' is going pretty far down a
> questionable road. I'm not so naive to think that there's not problems
> with my next suggestion, but there's this thing called LSB for a reason.
> If you want build once, run many distributions, you do that, not go and
> own even more dependencies.
However, an LSB compliant SDK becomes a case of installing "LSB" libs
into the right sysroot and then setting some
ASSUME_PROVIDED/PREFERRED_PROVIDER lines.
So I think its good all around, we achieve independence of the SDK from
the build system and make it depend on exactly what we do or don't want
it to. Where is the bad bit (ignoring build time)? :)
Cheers,
Richard
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: BBCLASSEXTEND sdk vs. nativesdk
2010-03-24 15:37 ` Richard Purdie
@ 2010-03-24 15:57 ` Tom Rini
2010-03-24 18:05 ` Richard Purdie
0 siblings, 1 reply; 17+ messages in thread
From: Tom Rini @ 2010-03-24 15:57 UTC (permalink / raw)
To: openembedded-devel
On Wed, 2010-03-24 at 15:37 +0000, Richard Purdie wrote:
> On Wed, 2010-03-24 at 08:27 -0700, Tom Rini wrote:
> > On Wed, 2010-03-24 at 10:28 +0000, Richard Purdie wrote:
> > > The difference is that the old "sdk" assumes the system you want the sdk
> > > to run on is the same as the build system. This has always been a big
> > > can of worms causing problems so "nativesdk" removes this assumption and
> > > allows you to set SDKMACHINE to be the machine you want the resulting
> > > sdk to run on.
> > >
> > > This adds some complexity since we need another cross compiling
> > > toolchain. But cross compiling toolchains are something we're good
> > > at :). It also means we ship *everything* with the sdk including a
> > > standalone glibc massively removing system dependencies from the result
> > > which in my opinion can only be a good thing.
> >
> > Or a really bad thing, yes. I think nativesdk will help out a lot for
> > making canadian style builds cleaner. But going so far as to say 'Oh,
> > lets just throw a libc into the SDK export' is going pretty far down a
> > questionable road. I'm not so naive to think that there's not problems
> > with my next suggestion, but there's this thing called LSB for a reason.
> > If you want build once, run many distributions, you do that, not go and
> > own even more dependencies.
>
> However, an LSB compliant SDK becomes a case of installing "LSB" libs
> into the right sysroot and then setting some
> ASSUME_PROVIDED/PREFERRED_PROVIDER lines.
>
> So I think its good all around, we achieve independence of the SDK from
> the build system and make it depend on exactly what we do or don't want
> it to. Where is the bad bit (ignoring build time)? :)
How is this working on the runtime? How relocatable is it? How much
have we added to the size?
--
Tom Rini <tom_rini@mentor.com>
Mentor Graphics Corporation
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: BBCLASSEXTEND sdk vs. nativesdk
2010-03-24 15:57 ` Tom Rini
@ 2010-03-24 18:05 ` Richard Purdie
2010-03-24 18:46 ` Tom Rini
0 siblings, 1 reply; 17+ messages in thread
From: Richard Purdie @ 2010-03-24 18:05 UTC (permalink / raw)
To: openembedded-devel
On Wed, 2010-03-24 at 08:57 -0700, Tom Rini wrote:
> On Wed, 2010-03-24 at 15:37 +0000, Richard Purdie wrote:
> > On Wed, 2010-03-24 at 08:27 -0700, Tom Rini wrote:
> > > Or a really bad thing, yes. I think nativesdk will help out a lot for
> > > making canadian style builds cleaner. But going so far as to say 'Oh,
> > > lets just throw a libc into the SDK export' is going pretty far down a
> > > questionable road. I'm not so naive to think that there's not problems
> > > with my next suggestion, but there's this thing called LSB for a reason.
> > > If you want build once, run many distributions, you do that, not go and
> > > own even more dependencies.
> >
> > However, an LSB compliant SDK becomes a case of installing "LSB" libs
> > into the right sysroot and then setting some
> > ASSUME_PROVIDED/PREFERRED_PROVIDER lines.
> >
> > So I think its good all around, we achieve independence of the SDK from
> > the build system and make it depend on exactly what we do or don't want
> > it to. Where is the bad bit (ignoring build time)? :)
>
> How is this working on the runtime? How relocatable is it?
Its no more or less reclocatable than the original was, that wasn't an
objective. Some postprocessing with the same code we use in
packaged-staging shouldn't see it being too bad though.
> How much have we added to the size?
I don't have specific numbers but I did check and it didn't seem
unreasonable on my test builds given that we escaped system dependence.
10MB maybe at a total guess?
If you build against LSB libs, the size shouldn't be any different.
Cheers,
Richard
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: BBCLASSEXTEND sdk vs. nativesdk
2010-03-24 18:05 ` Richard Purdie
@ 2010-03-24 18:46 ` Tom Rini
2010-03-25 23:11 ` Richard Purdie
0 siblings, 1 reply; 17+ messages in thread
From: Tom Rini @ 2010-03-24 18:46 UTC (permalink / raw)
To: openembedded-devel
On Wed, 2010-03-24 at 18:05 +0000, Richard Purdie wrote:
> On Wed, 2010-03-24 at 08:57 -0700, Tom Rini wrote:
> > On Wed, 2010-03-24 at 15:37 +0000, Richard Purdie wrote:
> > > On Wed, 2010-03-24 at 08:27 -0700, Tom Rini wrote:
> > > > Or a really bad thing, yes. I think nativesdk will help out a lot for
> > > > making canadian style builds cleaner. But going so far as to say 'Oh,
> > > > lets just throw a libc into the SDK export' is going pretty far down a
> > > > questionable road. I'm not so naive to think that there's not problems
> > > > with my next suggestion, but there's this thing called LSB for a reason.
> > > > If you want build once, run many distributions, you do that, not go and
> > > > own even more dependencies.
> > >
> > > However, an LSB compliant SDK becomes a case of installing "LSB" libs
> > > into the right sysroot and then setting some
> > > ASSUME_PROVIDED/PREFERRED_PROVIDER lines.
> > >
> > > So I think its good all around, we achieve independence of the SDK from
> > > the build system and make it depend on exactly what we do or don't want
> > > it to. Where is the bad bit (ignoring build time)? :)
> >
> > How is this working on the runtime? How relocatable is it?
>
> Its no more or less reclocatable than the original was, that wasn't an
> objective. Some postprocessing with the same code we use in
> packaged-staging shouldn't see it being too bad though.
Today it's fully relocatable, if you use $ORIGIN. Is that still true?
--
Tom Rini <tom_rini@mentor.com>
Mentor Graphics Corporation
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: BBCLASSEXTEND sdk vs. nativesdk
2010-03-24 10:53 ` jkridner
@ 2010-03-24 19:27 ` Denys Dmytriyenko
0 siblings, 0 replies; 17+ messages in thread
From: Denys Dmytriyenko @ 2010-03-24 19:27 UTC (permalink / raw)
To: openembedded-devel
On Wed, Mar 24, 2010 at 10:53:40AM +0000, jkridner@beagleboard.org wrote:
> Is this also the mechanism for building an sdk for the target then? Seems
> great to normalize this.
Jason,
Calling it "an SDK for the target" is not exactly correct. From your example
below, the target would be MIPS, while ARM would be an SDK host, I believe.
This technique is called The Canadian Cross:
http://en.wikipedia.org/wiki/Canadian_cross#Canadian_Cross
> If I wanted to build a MIPS cross-compiler that ran on an ARM board, and
> build that from an x86 machine, what would it look like given nativesdk?
Theoretically, that should be possible with MACHINE=mips and SDKMACHINE=arm,
but:
1. SDKMACHINE is not yet ported from Poky to OE
2. Currently Poky only supports i586, i686 and x86_64 as SDKMACHINE
--
Denys
> Sorry for the blackberry top post.
> Sent via BlackBerry from T-Mobile
>
> -----Original Message-----
> From: Richard Purdie <rpurdie@rpsys.net>
> Date: Wed, 24 Mar 2010 10:28:36
> To: <openembedded-devel@lists.openembedded.org>
> Subject: Re: [oe] BBCLASSEXTEND sdk vs. nativesdk
>
> On Tue, 2010-03-23 at 23:42 -0700, Scott Garman wrote:
> > On 03/23/2010 10:45 PM, Khem Raj wrote:
> > >> It seems to me the correct course of action is to use nativesdk in
> > >> BBCLASSEXTEND and rename the dependencies on other recipes, yes?
> > >
> > > you should rename the dependencies on zlib-sdk to zlib-nativesdk
> > > wherever they exist.
>
> This isn't quite correct. nativesdk is not a drop in replacement for the
> old sdk but you are right that is is the replacement.
>
> The difference is that the old "sdk" assumes the system you want the sdk
> to run on is the same as the build system. This has always been a big
> can of worms causing problems so "nativesdk" removes this assumption and
> allows you to set SDKMACHINE to be the machine you want the resulting
> sdk to run on.
>
> This adds some complexity since we need another cross compiling
> toolchain. But cross compiling toolchains are something we're good
> at :). It also means we ship *everything* with the sdk including a
> standalone glibc massively removing system dependencies from the result
> which in my opinion can only be a good thing.
>
> "sdk" and "nativesdk" are designed to coexist and the idea is that we
> add "nativesdk" to OE alongside "sdk", get it working, then remove the
> old broken "sdk" stuff.
>
> In theory you can therefore just add the BBCLASSEXTEND line to the zlib
> recipe and work backwards from there. You will need a working -crosssdk
> version of gcc to provide the different compiler.
>
> > I am running into some problems now trying to get zlib-nativesdk to
> > build. If I change the recipe to use sdk, it builds fine, so I have
> > something useful to compare things to.
> >
> > When I build using nativesdk, configure dies pretty quickly when testing
> > the compiler. It's trying to run i686-linux-gcc.
> >
> > Sure enough, if I compare the BitBake environments using the -e option,
> > I see that CC is being set to "gcc" when I use sdk but "i686-linux-gcc"
> > when I use nativesdk.
> >
> > If I create the needed symlink to gcc, the compilation gets further but
> > still fails, wanting i686-linux-ar, etc. So I have a basic understanding
> > of what the problem is, but I'm sure the solution is not to go symlink
> > crazy with my native compiler environment.
>
> See above, its missing the -crosssdk cross compiler. Did you not have to
> ASSUME_PROVIDED something to make the dependencies work?
>
> > So I took a look at sdk.bbclass and nativesdk.bbclass. They both set up
> > a number of architecture-specific variables, but neither of them
> > explicitly set CC. Where I should look next?
> >
> > It turns out there is only one package currently in OE that uses
> > BBCLASSEXTEND with nativesdk (gettext_0.17). So perhaps it is the case
> > that nativesdk.bbclass needs additional work. I did test copying over
> > Poky's nativesdk.bbclass (which has just a few differences), but I still
> > get the same results.
>
> We probably need those differences in OE. Its nice to see someone
> looking at this!
>
> Cheers,
>
> Richard
>
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: BBCLASSEXTEND sdk vs. nativesdk
2010-03-24 18:46 ` Tom Rini
@ 2010-03-25 23:11 ` Richard Purdie
0 siblings, 0 replies; 17+ messages in thread
From: Richard Purdie @ 2010-03-25 23:11 UTC (permalink / raw)
To: openembedded-devel
On Wed, 2010-03-24 at 11:46 -0700, Tom Rini wrote:
> On Wed, 2010-03-24 at 18:05 +0000, Richard Purdie wrote:
> > On Wed, 2010-03-24 at 08:57 -0700, Tom Rini wrote:
> > > On Wed, 2010-03-24 at 15:37 +0000, Richard Purdie wrote:
> > > > On Wed, 2010-03-24 at 08:27 -0700, Tom Rini wrote:
> > > > > Or a really bad thing, yes. I think nativesdk will help out a lot for
> > > > > making canadian style builds cleaner. But going so far as to say 'Oh,
> > > > > lets just throw a libc into the SDK export' is going pretty far down a
> > > > > questionable road. I'm not so naive to think that there's not problems
> > > > > with my next suggestion, but there's this thing called LSB for a reason.
> > > > > If you want build once, run many distributions, you do that, not go and
> > > > > own even more dependencies.
> > > >
> > > > However, an LSB compliant SDK becomes a case of installing "LSB" libs
> > > > into the right sysroot and then setting some
> > > > ASSUME_PROVIDED/PREFERRED_PROVIDER lines.
> > > >
> > > > So I think its good all around, we achieve independence of the SDK from
> > > > the build system and make it depend on exactly what we do or don't want
> > > > it to. Where is the bad bit (ignoring build time)? :)
> > >
> > > How is this working on the runtime? How relocatable is it?
> >
> > Its no more or less reclocatable than the original was, that wasn't an
> > objective. Some postprocessing with the same code we use in
> > packaged-staging shouldn't see it being too bad though.
>
> Today it's fully relocatable, if you use $ORIGIN. Is that still true?
Yes, this doesn't change. You just gain control over which libc it links
against.
Cheers,
Richard
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2010-03-25 23:14 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-03-11 23:13 [PATCH/RFC] zlib: convert to BBCLASSEXTEND Scott Garman
2010-03-12 0:18 ` Khem Raj
2010-03-12 3:26 ` Scott Garman
2010-03-12 3:28 ` Scott Garman
2010-03-12 20:39 ` Khem Raj
2010-03-24 3:06 ` BBCLASSEXTEND sdk vs. nativesdk Scott Garman
2010-03-24 5:45 ` Khem Raj
2010-03-24 6:42 ` Scott Garman
2010-03-24 10:28 ` Richard Purdie
2010-03-24 10:53 ` jkridner
2010-03-24 19:27 ` Denys Dmytriyenko
2010-03-24 15:27 ` Tom Rini
2010-03-24 15:37 ` Richard Purdie
2010-03-24 15:57 ` Tom Rini
2010-03-24 18:05 ` Richard Purdie
2010-03-24 18:46 ` Tom Rini
2010-03-25 23:11 ` Richard Purdie
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.