[PATCH/RFC] zlib: convert to BBCLASSEXTEND

[PATCH/RFC] zlib: convert to BBCLASSEXTEND

[Scott Garman]

[-- 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"

Re: [PATCH/RFC] zlib: convert to BBCLASSEXTEND

[Khem Raj]

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
>
>

Re: [PATCH/RFC] zlib: convert to BBCLASSEXTEND

[Scott Garman]

[-- 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

Re: [PATCH/RFC] zlib: convert to BBCLASSEXTEND

[Scott Garman]

[-- 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

Re: [PATCH/RFC] zlib: convert to BBCLASSEXTEND

[Khem Raj]

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
>
>

BBCLASSEXTEND sdk vs. nativesdk

[Scott Garman]

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

Re: BBCLASSEXTEND sdk vs. nativesdk

[Khem Raj]

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
>

Re: BBCLASSEXTEND sdk vs. nativesdk

[Scott Garman]

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

Re: BBCLASSEXTEND sdk vs. nativesdk

[Richard Purdie]

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

Re: BBCLASSEXTEND sdk vs. nativesdk

[jkridner]

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

Re: BBCLASSEXTEND sdk vs. nativesdk

[Denys Dmytriyenko]

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

Re: BBCLASSEXTEND sdk vs. nativesdk

[Tom Rini]

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

Re: BBCLASSEXTEND sdk vs. nativesdk

[Richard Purdie]

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

Re: BBCLASSEXTEND sdk vs. nativesdk

[Tom Rini]

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

Re: BBCLASSEXTEND sdk vs. nativesdk

[Richard Purdie]

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

Re: BBCLASSEXTEND sdk vs. nativesdk

[Tom Rini]

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

Re: BBCLASSEXTEND sdk vs. nativesdk

[Richard Purdie]

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