Cleaning up SDK/Toolchain

Cleaning up SDK/Toolchain

[Michael 'Mickey' Lauer]

On OEDEM we talked about SDK and Toolchain issues. Richard Purdie
recently merged Poky's meta-toolchain package plus the infrastructure
that enables OE building external toolchains for usage with or without
OpenEmbedded.

In order to make this a bit more clean, we'd like to remove some of
the older meta-sdk packages, if no one objects. If you are still using
the meta-sdk packages, could you merge them towards using
meta-toolchain?

Adding custom packages to the meta-toolchain should just be a matter
of overriding TOOLCHAIN_TARGET_TASK now.

Regards,

:M:
-- 
Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de

Re: Cleaning up SDK/Toolchain

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael 'Mickey' Lauer schreef:
> On OEDEM we talked about SDK and Toolchain issues. Richard Purdie
> recently merged Poky's meta-toolchain package plus the infrastructure
> that enables OE building external toolchains for usage with or without
> OpenEmbedded.
> 
> In order to make this a bit more clean, we'd like to remove some of
> the older meta-sdk packages, if no one objects. If you are still using
> the meta-sdk packages, could you merge them towards using
> meta-toolchain?
> 
> Adding custom packages to the meta-toolchain should just be a matter
> of overriding TOOLCHAIN_TARGET_TASK now.

Apart from the libc flaw I pointed out in another mail, the naming of the toolchains is
broken as well:

angstrom-2007.9-test-20071017-arm-linux-gnueabi-toolchain.tar.bz2
angstrom-2007.9-test-20071017-arm-linux-uclibcgnueabi-toolchain.tar.bz2
angstrom-2007.9-test-20071018-powerpc-linux-toolchain.tar.bz2
angstrom-2007.9-test-20071018-powerpc-linux-uclibc-toolchain.tar.bz2

There's no way to see if the arm ones are armv4t, armv5te or armv6 and the powerpc ones
ppc405, ppc440 or ppc603e. For compiling 'hello world' that doesn't matter, but libc6.so
and libgcc_s.so will contain instruction not available on other cpus of that arch (e.g.
clz is not in armv4t), so your binary will probably not work on your device.

My idea is to use PACKAGE_ARCH (e.g. armv5te or ppc603e) instead of TARGET_ARCH.

Comments/hints/ideas?

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFHFyntMkyGM64RGpERAm+UAJsHn+2oCOjJoHlTxJ0o9SmSTP5bjQCffUcx
fNmkEs0chQ5uAtVAoxOsZ7c=
=gywh
-----END PGP SIGNATURE-----

Re: Cleaning up SDK/Toolchain

[Richard Purdie]

On Thu, 2007-10-18 at 11:39 +0200, Koen Kooi wrote:
> Apart from the libc flaw I pointed out in another mail, the naming of the toolchains is
> broken as well:
> 
> angstrom-2007.9-test-20071017-arm-linux-gnueabi-toolchain.tar.bz2
> angstrom-2007.9-test-20071017-arm-linux-uclibcgnueabi-toolchain.tar.bz2
> angstrom-2007.9-test-20071018-powerpc-linux-toolchain.tar.bz2
> angstrom-2007.9-test-20071018-powerpc-linux-uclibc-toolchain.tar.bz2
> 
> There's no way to see if the arm ones are armv4t, armv5te or armv6 and the powerpc ones
> ppc405, ppc440 or ppc603e. For compiling 'hello world' that doesn't matter, but libc6.so
> and libgcc_s.so will contain instruction not available on other cpus of that arch (e.g.
> clz is not in armv4t), so your binary will probably not work on your device.
> 
> My idea is to use PACKAGE_ARCH (e.g. armv5te or ppc603e) instead of TARGET_ARCH.
> 
> Comments/hints/ideas?

We actually have a bigger problem. Staging uses an arm directory, not an
armv5te one so the armv5te binaries mix up with the armv4 ones etc.

This isn't a problem with images built from packages where everything
dynamically links since the right packages are used. The moment someone
tries to statically link an armv4 binary with armv5te in staging, game
over though.

So both the meta-toolchain and staging need some thought (and are
related since meta-toolchain has knowledge to rebuild bits of staging
for use in its "shortcut an OE build by skipping the toolchain" mode.

I agreed we probably need to add in some PACKAGE_ARCHs in places but its
yet another thing that needs some careful thought and we'll probably
break people's existing builds. I hope to look at/think about it soon if
nobody beats me too it...

Cheers,

Richard

Re: Cleaning up SDK/Toolchain

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Richard Purdie schreef:
> On Thu, 2007-10-18 at 11:39 +0200, Koen Kooi wrote:
>> Apart from the libc flaw I pointed out in another mail, the naming of the toolchains is
>> broken as well:
>>
>> angstrom-2007.9-test-20071017-arm-linux-gnueabi-toolchain.tar.bz2
>> angstrom-2007.9-test-20071017-arm-linux-uclibcgnueabi-toolchain.tar.bz2
>> angstrom-2007.9-test-20071018-powerpc-linux-toolchain.tar.bz2
>> angstrom-2007.9-test-20071018-powerpc-linux-uclibc-toolchain.tar.bz2
>>
>> There's no way to see if the arm ones are armv4t, armv5te or armv6 and the powerpc ones
>> ppc405, ppc440 or ppc603e. For compiling 'hello world' that doesn't matter, but libc6.so
>> and libgcc_s.so will contain instruction not available on other cpus of that arch (e.g.
>> clz is not in armv4t), so your binary will probably not work on your device.
>>
>> My idea is to use PACKAGE_ARCH (e.g. armv5te or ppc603e) instead of TARGET_ARCH.
>>
>> Comments/hints/ideas?
> 
> We actually have a bigger problem. Staging uses an arm directory, not an
> armv5te one so the armv5te binaries mix up with the armv4 ones etc.
> 
> This isn't a problem with images built from packages where everything
> dynamically links since the right packages are used. The moment someone
> tries to statically link an armv4 binary with armv5te in staging, game
> over though.
> 
> So both the meta-toolchain and staging need some thought (and are
> related since meta-toolchain has knowledge to rebuild bits of staging
> for use in its "shortcut an OE build by skipping the toolchain" mode.
> 
> I agreed we probably need to add in some PACKAGE_ARCHs in places but its
> yet another thing that needs some careful thought and we'll probably
> break people's existing builds. I hope to look at/think about it soon if
> nobody beats me too it...

Can't we put it in at the same time as the staging /usr changes? We'll
be breaking stuff anyway...


regards,

Koen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFHF2MwMkyGM64RGpERAkTbAJoDh5qic4QmFPw7N857kQm0rDabjgCgtcJ0
hqYD4JywIUYGwPtw8dgJnTM=
=Hlfq
-----END PGP SIGNATURE-----

Re: Cleaning up SDK/Toolchain

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Richard Purdie schreef:
> On Thu, 2007-10-18 at 11:39 +0200, Koen Kooi wrote:
>> Apart from the libc flaw I pointed out in another mail, the naming of the toolchains is
>> broken as well:
>>
>> angstrom-2007.9-test-20071017-arm-linux-gnueabi-toolchain.tar.bz2
>> angstrom-2007.9-test-20071017-arm-linux-uclibcgnueabi-toolchain.tar.bz2
>> angstrom-2007.9-test-20071018-powerpc-linux-toolchain.tar.bz2
>> angstrom-2007.9-test-20071018-powerpc-linux-uclibc-toolchain.tar.bz2
>>
>> There's no way to see if the arm ones are armv4t, armv5te or armv6 and the powerpc ones
>> ppc405, ppc440 or ppc603e. For compiling 'hello world' that doesn't matter, but libc6.so
>> and libgcc_s.so will contain instruction not available on other cpus of that arch (e.g.
>> clz is not in armv4t), so your binary will probably not work on your device.
>>
>> My idea is to use PACKAGE_ARCH (e.g. armv5te or ppc603e) instead of TARGET_ARCH.
>>
>> Comments/hints/ideas?
> 
> We actually have a bigger problem. Staging uses an arm directory, not an
> armv5te one so the armv5te binaries mix up with the armv4 ones etc.
> 
> This isn't a problem with images built from packages where everything
> dynamically links since the right packages are used. The moment someone
> tries to statically link an armv4 binary with armv5te in staging, game
> over though.
> 
> So both the meta-toolchain and staging need some thought (and are
> related since meta-toolchain has knowledge to rebuild bits of staging
> for use in its "shortcut an OE build by skipping the toolchain" mode.
> 
> I agreed we probably need to add in some PACKAGE_ARCHs in places but its
> yet another thing that needs some careful thought and we'll probably
> break people's existing builds. I hope to look at/think about it soon if
> nobody beats me too it...

Actually, PACKAGE_ARCH (or whatever we will call it) needs to become a
first class citizen with its own overrides, since doing things like:

conf/distro/include/angstrom.inc:39:ENABLE_BINARY_LOCALE_GENERATION_mx31ads
= "0"
conf/distro/include/angstrom.inc:40:ENABLE_BINARY_LOCALE_GENERATION_nokia800
= "0"
conf/distro/include/angstrom.inc:41:ENABLE_BINARY_LOCALE_GENERATION_omap2420h4
= "0"
conf/distro/include/angstrom.inc:42:ENABLE_BINARY_LOCALE_GENERATION_omap2430sdp
= "0"

is tedious when you actually mean _armv6[1]

regards,

Koen

Speaking of armv6: http://maemo.org/news/announcements/view/1192708879.html


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFHF5hFMkyGM64RGpERAouqAJsFXog8g382K6A53UmqA70HY10/LwCgkuhd
lsvuhF+mhxiDSCzgwoQW4iQ=
=YVdl
-----END PGP SIGNATURE-----

Re: Cleaning up SDK/Toolchain

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Richard Purdie schreef:
> On Thu, 2007-10-18 at 11:39 +0200, Koen Kooi wrote:
>> Apart from the libc flaw I pointed out in another mail, the naming of the toolchains is
>> broken as well:
>>
>> angstrom-2007.9-test-20071017-arm-linux-gnueabi-toolchain.tar.bz2
>> angstrom-2007.9-test-20071017-arm-linux-uclibcgnueabi-toolchain.tar.bz2
>> angstrom-2007.9-test-20071018-powerpc-linux-toolchain.tar.bz2
>> angstrom-2007.9-test-20071018-powerpc-linux-uclibc-toolchain.tar.bz2
>>
>> There's no way to see if the arm ones are armv4t, armv5te or armv6 and the powerpc ones
>> ppc405, ppc440 or ppc603e. For compiling 'hello world' that doesn't matter, but libc6.so
>> and libgcc_s.so will contain instruction not available on other cpus of that arch (e.g.
>> clz is not in armv4t), so your binary will probably not work on your device.
>>
>> My idea is to use PACKAGE_ARCH (e.g. armv5te or ppc603e) instead of TARGET_ARCH.
>>
>> Comments/hints/ideas?
> 
> We actually have a bigger problem. Staging uses an arm directory, not an
> armv5te one so the armv5te binaries mix up with the armv4 ones etc.
> 
> This isn't a problem with images built from packages where everything
> dynamically links since the right packages are used. The moment someone
> tries to statically link an armv4 binary with armv5te in staging, game
> over though.
> 
> So both the meta-toolchain and staging need some thought (and are
> related since meta-toolchain has knowledge to rebuild bits of staging
> for use in its "shortcut an OE build by skipping the toolchain" mode.
> 
> I agreed we probably need to add in some PACKAGE_ARCHs in places but its
> yet another thing that needs some careful thought and we'll probably
> break people's existing builds. I hope to look at/think about it soon if
> nobody beats me too it...

Hopefully[1] it's as simple as:

#
# old_revision [95220d9f8a309c487f6d8da20ce7f8df8945bc0c]
#
# patch "conf/bitbake.conf"
#  from [f410a6b3af115612f2bd104814d1035583d3518a]
#    to [3391cfd9df2450e4090fa01879fab5f5e7b100a8]
#
============================================================
- --- conf/bitbake.conf   f410a6b3af115612f2bd104814d1035583d3518a
+++ conf/bitbake.conf   3391cfd9df2450e4090fa01879fab5f5e7b100a8
@@ -45,6 +45,7 @@ HOST_SYS = "${HOST_ARCH}${HOST_VENDOR}-$
 HOST_OS = "${TARGET_OS}"
 HOST_VENDOR = "${TARGET_VENDOR}"
 HOST_SYS = "${HOST_ARCH}${HOST_VENDOR}-${HOST_OS}"
+STAGING_SYS = "${PACKAGE_ARCH}${HOST_VENDOR}-${HOST_OS}"
 HOST_PREFIX = "${TARGET_PREFIX}"
 HOST_CC_ARCH = "${TARGET_CC_ARCH}"

@@ -167,16 +168,16 @@ STAGING_DIR = "${TMPDIR}/staging"
 B = "${S}"

 STAGING_DIR = "${TMPDIR}/staging"
- -STAGING_BINDIR = "${STAGING_DIR}/${HOST_SYS}/bin"
+STAGING_BINDIR = "${STAGING_DIR}/${STAGING_SYS}/bin"
 STAGING_BINDIR_CROSS = "${STAGING_DIR}/${BUILD_SYS}/bin/${HOST_SYS}"
 STAGING_BINDIR_NATIVE = "${STAGING_DIR}/${BUILD_SYS}/bin"
- -STAGING_LIBDIR = "${STAGING_DIR}/${HOST_SYS}/lib"
+STAGING_LIBDIR = "${STAGING_DIR}/${STAGING_SYS}/lib"
 STAGING_LIBDIR_NATIVE = "${STAGING_DIR}/${BUILD_SYS}/lib"
 STAGING_ETCDIR_NATIVE = "${STAGING_DIR}/${BUILD_SYS}/etc"
- -STAGING_INCDIR = "${STAGING_DIR}/${HOST_SYS}/include"
- -STAGING_DATADIR = "${STAGING_DIR}/${HOST_SYS}/share"
- -STAGING_LOADER_DIR = "${STAGING_DIR}/${HOST_SYS}/loader"
- -STAGING_FIRMWARE_DIR = "${STAGING_DIR}/${HOST_SYS}/firmware"
+STAGING_INCDIR = "${STAGING_DIR}/${STAGING_SYS}/include"
+STAGING_DATADIR = "${STAGING_DIR}/${STAGING_SYS}/share"
+STAGING_LOADER_DIR = "${STAGING_DIR}/${STAGING_SYS}/loader"
+STAGING_FIRMWARE_DIR = "${STAGING_DIR}/${STAGING_SYS}/firmware"
 STAGING_PYDIR = "${STAGING_DIR}/lib/python2.4"

regards,

Koen

[1] I suspect this 'breaks' machine specific packages, but we'll see

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFHHIv0MkyGM64RGpERAu2mAJ4uKSq0ikrAs+sDeHbXL/CpoJKhCACgtNRX
V3klBAJipI9EL0EJxVIOYdo=
=vHWK
-----END PGP SIGNATURE-----

Re: Cleaning up SDK/Toolchain

[Richard Purdie]

On Mon, 2007-10-22 at 13:39 +0200, Koen Kooi wrote:
> Richard Purdie schreef:
> > 
> > We actually have a bigger problem. Staging uses an arm directory, not an
> > armv5te one so the armv5te binaries mix up with the armv4 ones etc.
> > 
> > This isn't a problem with images built from packages where everything
> > dynamically links since the right packages are used. The moment someone
> > tries to statically link an armv4 binary with armv5te in staging, game
> > over though.
> > 
> > So both the meta-toolchain and staging need some thought (and are
> > related since meta-toolchain has knowledge to rebuild bits of staging
> > for use in its "shortcut an OE build by skipping the toolchain" mode.
> > 
> > I agreed we probably need to add in some PACKAGE_ARCHs in places but its
> > yet another thing that needs some careful thought and we'll probably
> > break people's existing builds. I hope to look at/think about it soon if
> > nobody beats me too it...
> 
> Hopefully[1] it's as simple as:
> 
> ============================================================
> - --- conf/bitbake.conf   f410a6b3af115612f2bd104814d1035583d3518a
> +++ conf/bitbake.conf   3391cfd9df2450e4090fa01879fab5f5e7b100a8
> @@ -45,6 +45,7 @@ HOST_SYS = "${HOST_ARCH}${HOST_VENDOR}-$
>  HOST_OS = "${TARGET_OS}"
>  HOST_VENDOR = "${TARGET_VENDOR}"
>  HOST_SYS = "${HOST_ARCH}${HOST_VENDOR}-${HOST_OS}"
> +STAGING_SYS = "${PACKAGE_ARCH}${HOST_VENDOR}-${HOST_OS}"
>  HOST_PREFIX = "${TARGET_PREFIX}"
>  HOST_CC_ARCH = "${TARGET_CC_ARCH}"
> 
> @@ -167,16 +168,16 @@ STAGING_DIR = "${TMPDIR}/staging"
>  B = "${S}"
> 
>  STAGING_DIR = "${TMPDIR}/staging"
> - -STAGING_BINDIR = "${STAGING_DIR}/${HOST_SYS}/bin"
> +STAGING_BINDIR = "${STAGING_DIR}/${STAGING_SYS}/bin"
>  STAGING_BINDIR_CROSS = "${STAGING_DIR}/${BUILD_SYS}/bin/${HOST_SYS}"
>  STAGING_BINDIR_NATIVE = "${STAGING_DIR}/${BUILD_SYS}/bin"
> - -STAGING_LIBDIR = "${STAGING_DIR}/${HOST_SYS}/lib"
> +STAGING_LIBDIR = "${STAGING_DIR}/${STAGING_SYS}/lib"
>  STAGING_LIBDIR_NATIVE = "${STAGING_DIR}/${BUILD_SYS}/lib"
>  STAGING_ETCDIR_NATIVE = "${STAGING_DIR}/${BUILD_SYS}/etc"
> - -STAGING_INCDIR = "${STAGING_DIR}/${HOST_SYS}/include"
> - -STAGING_DATADIR = "${STAGING_DIR}/${HOST_SYS}/share"
> - -STAGING_LOADER_DIR = "${STAGING_DIR}/${HOST_SYS}/loader"
> - -STAGING_FIRMWARE_DIR = "${STAGING_DIR}/${HOST_SYS}/firmware"
> +STAGING_INCDIR = "${STAGING_DIR}/${STAGING_SYS}/include"
> +STAGING_DATADIR = "${STAGING_DIR}/${STAGING_SYS}/share"
> +STAGING_LOADER_DIR = "${STAGING_DIR}/${STAGING_SYS}/loader"
> +STAGING_FIRMWARE_DIR = "${STAGING_DIR}/${STAGING_SYS}/firmware"
>  STAGING_PYDIR = "${STAGING_DIR}/lib/python2.4"

> [1] I suspect this 'breaks' machine specific packages, but we'll see

I suspect you'll be right. This actually turns into a nightmare the more
you think about it.

Consider we have libfoo which is compiled with iwmmxt optimisations for
iwmmxt machines and without iwmmxt optimisations for other arm machines.
appfoo statically links against this. 

I can think of a few ways we could handle this and other issues
generically:

* We could have a staging lib directory per PACKAGE_ARCH and then join
them all together with CFLAGS/LDFLAGS as you suggested on irc. I think
it will get really really messy though.

* Each machine could have its own staging area. To do that you'd have to
make the populate staging stamp machine specific. That is possible
although bitbake might require some tweaks and it would have
implications for rm_work.

* We implement packaged staging and only stage the dependencies needed
for each package.

Personally, I suspect the latter two are the best options.

Cheers,

Richard

Re: Cleaning up SDK/Toolchain

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Richard Purdie schreef:
> On Mon, 2007-10-22 at 13:39 +0200, Koen Kooi wrote:
>> Richard Purdie schreef:
>>> We actually have a bigger problem. Staging uses an arm directory, not an
>>> armv5te one so the armv5te binaries mix up with the armv4 ones etc.
>>>
>>> This isn't a problem with images built from packages where everything
>>> dynamically links since the right packages are used. The moment someone
>>> tries to statically link an armv4 binary with armv5te in staging, game
>>> over though.
>>>
>>> So both the meta-toolchain and staging need some thought (and are
>>> related since meta-toolchain has knowledge to rebuild bits of staging
>>> for use in its "shortcut an OE build by skipping the toolchain" mode.
>>>
>>> I agreed we probably need to add in some PACKAGE_ARCHs in places but its
>>> yet another thing that needs some careful thought and we'll probably
>>> break people's existing builds. I hope to look at/think about it soon if
>>> nobody beats me too it...
>> Hopefully[1] it's as simple as:
>>
>> ============================================================
>> - --- conf/bitbake.conf   f410a6b3af115612f2bd104814d1035583d3518a
>> +++ conf/bitbake.conf   3391cfd9df2450e4090fa01879fab5f5e7b100a8
>> @@ -45,6 +45,7 @@ HOST_SYS = "${HOST_ARCH}${HOST_VENDOR}-$
>>  HOST_OS = "${TARGET_OS}"
>>  HOST_VENDOR = "${TARGET_VENDOR}"
>>  HOST_SYS = "${HOST_ARCH}${HOST_VENDOR}-${HOST_OS}"
>> +STAGING_SYS = "${PACKAGE_ARCH}${HOST_VENDOR}-${HOST_OS}"
>>  HOST_PREFIX = "${TARGET_PREFIX}"
>>  HOST_CC_ARCH = "${TARGET_CC_ARCH}"
>>
>> @@ -167,16 +168,16 @@ STAGING_DIR = "${TMPDIR}/staging"
>>  B = "${S}"
>>
>>  STAGING_DIR = "${TMPDIR}/staging"
>> - -STAGING_BINDIR = "${STAGING_DIR}/${HOST_SYS}/bin"
>> +STAGING_BINDIR = "${STAGING_DIR}/${STAGING_SYS}/bin"
>>  STAGING_BINDIR_CROSS = "${STAGING_DIR}/${BUILD_SYS}/bin/${HOST_SYS}"
>>  STAGING_BINDIR_NATIVE = "${STAGING_DIR}/${BUILD_SYS}/bin"
>> - -STAGING_LIBDIR = "${STAGING_DIR}/${HOST_SYS}/lib"
>> +STAGING_LIBDIR = "${STAGING_DIR}/${STAGING_SYS}/lib"
>>  STAGING_LIBDIR_NATIVE = "${STAGING_DIR}/${BUILD_SYS}/lib"
>>  STAGING_ETCDIR_NATIVE = "${STAGING_DIR}/${BUILD_SYS}/etc"
>> - -STAGING_INCDIR = "${STAGING_DIR}/${HOST_SYS}/include"
>> - -STAGING_DATADIR = "${STAGING_DIR}/${HOST_SYS}/share"
>> - -STAGING_LOADER_DIR = "${STAGING_DIR}/${HOST_SYS}/loader"
>> - -STAGING_FIRMWARE_DIR = "${STAGING_DIR}/${HOST_SYS}/firmware"
>> +STAGING_INCDIR = "${STAGING_DIR}/${STAGING_SYS}/include"
>> +STAGING_DATADIR = "${STAGING_DIR}/${STAGING_SYS}/share"
>> +STAGING_LOADER_DIR = "${STAGING_DIR}/${STAGING_SYS}/loader"
>> +STAGING_FIRMWARE_DIR = "${STAGING_DIR}/${STAGING_SYS}/firmware"
>>  STAGING_PYDIR = "${STAGING_DIR}/lib/python2.4"
> 
>> [1] I suspect this 'breaks' machine specific packages, but we'll see
> 
> I suspect you'll be right. This actually turns into a nightmare the more
> you think about it.
> 
> Consider we have libfoo which is compiled with iwmmxt optimisations for
> iwmmxt machines and without iwmmxt optimisations for other arm machines.
> appfoo statically links against this. 
> 
> I can think of a few ways we could handle this and other issues
> generically:
> 
> * We could have a staging lib directory per PACKAGE_ARCH and then join
> them all together with CFLAGS/LDFLAGS as you suggested on irc. I think
> it will get really really messy though.
> 
> * Each machine could have its own staging area. To do that you'd have to
> make the populate staging stamp machine specific. That is possible
> although bitbake might require some tweaks and it would have
> implications for rm_work.

In essence it would make multimachine unimachine :(

> * We implement packaged staging and only stage the dependencies needed
> for each package.

That would be a better approach. Graeme, do you still want to have a
shot at implementing a unionfs based approach?

regards,

Koen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFHHMMdMkyGM64RGpERAnMYAJ0dp0rCX5jJK0DXLT81afSFZdGB0ACeM5p3
Mqjknw8D+MjtWMU+tGV7dck=
=zDLu
-----END PGP SIGNATURE-----

Re: Cleaning up SDK/Toolchain

[Graeme Gregory]

> > * We implement packaged staging and only stage the dependencies
> > needed for each package.
> 
> That would be a better approach. Graeme, do you still want to have a
> shot at implementing a unionfs based approach?
> 
I do think that would be a neat solution to avoid running gzip/unzip
for every package. And should be doable with a LD_PRELOAD type system
that just redirects open() and its familly. Im sure I saw one once
on freshmeat.net Ill try and dig it out.

Graeme (XorA)

Re: Cleaning up SDK/Toolchain

[Richard Purdie]

On Mon, 2007-10-22 at 17:34 +0200, Koen Kooi wrote:
> Richard Purdie schreef:
> > * Each machine could have its own staging area. To do that you'd have to
> > make the populate staging stamp machine specific. That is possible
> > although bitbake might require some tweaks and it would have
> > implications for rm_work.
> 
> In essence it would make multimachine unimachine :(

Not necessarily. Only the populate_staging task would be machine
specific, not the all the tasks.

With the staging changes I'm thinking of, do_populate_staging basically
becomes a file copy. For the numbers of files we're talking about, it
should be fast. rm_work would still work as long as it preserved the
image directory under work...

> > * We implement packaged staging and only stage the dependencies needed
> > for each package.
>
> That would be a better approach. Graeme, do you still want to have a
> shot at implementing a unionfs based approach?

Hmm. Does that need root privs?

Richard

Re: Cleaning up SDK/Toolchain

[Leon Woestenberg]

Hello,

On 10/22/07, Richard Purdie <rpurdie@rpsys.net> wrote:
> On Mon, 2007-10-22 at 17:34 +0200, Koen Kooi wrote:
> > Richard Purdie schreef:
> > > * We implement packaged staging and only stage the dependencies needed
> > > for each package.
> >
> > That would be a better approach. Graeme, do you still want to have a
> > shot at implementing a unionfs based approach?
>
> Hmm. Does that need root privs?
>

Depending on a (virtual) filesystem is not really user-friendly, given
that it needs both a specific kernel configuration and probably root
access.

By the way, unionfs is soon deprecated by an in-kernel union mount
system, like the *BSD's already have, so the solution will be not
future-proof.

Please avoid both the unionfs solution, or the future union mount
options for OpenEmbedded user space.

Regards,

Leon.

Re: Cleaning up SDK/Toolchain

[Graeme Gregory]

> > That would be a better approach. Graeme, do you still want to have a
> > shot at implementing a unionfs based approach?
> 
> Hmm. Does that need root privs?
> 
Not what I was thinking, which was to do a union via LD_PRELOAD
basically redirecting open and its friends. I once saw a program that
did this trick tomorrow I shall try and dig it out, and try and give
it a few simple tests.

Graeme

Re: Cleaning up SDK/Toolchain

[mwester]

> > > That would be a better approach. Graeme, do you still want to have a
> > > shot at implementing a unionfs based approach?
> > 
> > Hmm. Does that need root privs?
> > 
> Not what I was thinking, which was to do a union via LD_PRELOAD
> basically redirecting open and its friends. I once saw a program that
> did this trick tomorrow I shall try and dig it out, and try and give
> it a few simple tests.
> 
> Graeme

Please, please don't tell me that you're thinking of doing something like fakeroot?!  (It still doesn't work reliably, and nobody has ever figured it out -- see the Debian bug reports for some interesting history on this thing's problems).

The huge, giant hole with LD_PRELOAD is that it only works if everyone plays nice and uses the same mechanism.  Since we can't predict how the staging directory might be used, it's pretty hard to ensure that we've caught all the corner cases.  And it's a devilishly difficult problem to solve.

Mike (mwester)

Re: Cleaning up SDK/Toolchain

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Richard Purdie schreef:
> On Mon, 2007-10-22 at 17:34 +0200, Koen Kooi wrote:
>> Richard Purdie schreef:
>>> * Each machine could have its own staging area. To do that you'd have to
>>> make the populate staging stamp machine specific. That is possible
>>> although bitbake might require some tweaks and it would have
>>> implications for rm_work.
>> In essence it would make multimachine unimachine :(
> 
> Not necessarily. Only the populate_staging task would be machine
> specific, not the all the tasks.
> 
> With the staging changes I'm thinking of, do_populate_staging basically
> becomes a file copy. For the numbers of files we're talking about, it
> should be fast. rm_work would still work as long as it preserved the
> image directory under work...

So:

* rm_work deletes ${S} when used
* do_clean deletes ${WORKDIR} when used and kills stamps
* do_stage() copies files from ${WORKDIR}/image/ to staging/machine-tuple/

did I understand that correctly?

regards,

Koen



> 
>>> * We implement packaged staging and only stage the dependencies needed
>>> for each package.
>> That would be a better approach. Graeme, do you still want to have a
>> shot at implementing a unionfs based approach?
> 
> Hmm. Does that need root privs?
> 
> Richard
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFHH6w9MkyGM64RGpERAsPdAKCYsjAOTF+R5zmCnEjr7cqsodJiWQCfWhG7
ZUKW4Ca9hANBG+LC5j/ejJE=
=edFM
-----END PGP SIGNATURE-----