problems compiling glibc_2.9-r37.4 under Angstrom

problems compiling glibc_2.9-r37.4 under Angstrom

[Víctor M. Jáquez L.]

In order to build native-sdk-image recipe, I found my self compiling
glibc_2.9-r37.4, because it is the real provider of virtual-libc-dev (the
toolchain does not truly provide it -but that is another bug [1]-).

But the glibc_2.9-r37.4 configuration fails using the canonical
arm-angstrom-linux-gnueabi- toolchain (using the csl external toolchain fails
too, but for other reasons):

Log data follows:
| configure.in:2204: warning: AC_CACHE_VAL(pic_default, ...): suspicious cache-id, must contain _cv_ to be cached
| ../../lib/autoconf/general.m4:1999: AC_CACHE_VAL is expanded from...
| ../../lib/autoconf/general.m4:2020: AC_CACHE_CHECK is expanded from...
| configure.in:2204: the top level
| checking build system type... x86_64-pc-linux-gnu
| checking host system type... arm-angstrom-linux-gnueabi
| checking add-on ports for preconfigure fragments... am33 arm hppa m68k mips
| configure: running configure fragment for add-on nptl
| configure: running configure fragment for add-on libidn
| checking sysdep dirs... ports/sysdeps/arm/elf ports/sysdeps/unix/sysv/linux/arm/eabi/nptl ports/sysdeps/unix/sysv/linux/arm/eabi sysdeps/unix/sysv/linux/arm/eabi ports/sysdeps/unix/sysv/linux/arm/nptl ports/sysdeps/unix/sysv/linux/arm sysdeps/unix/sysv/linux/arm ports/sysdeps/unix/sysv/linux nptl/sysdeps/unix/sysv/linux nptl/sysdeps/pthread sysdeps/pthread sysdeps/unix/sysv/linux sysdeps/gnu sysdeps/unix/common sysdeps/unix/mman sysdeps/unix/inet ports/sysdeps/unix/sysv nptl/sysdeps/unix/sysv sysdeps/unix/sysv ports/sysdeps/unix/arm ports/sysdeps/unix nptl/sysdeps/unix sysdeps/unix sysdeps/posix ports/sysdeps/arm/eabi ports/sysdeps/arm/fpu ports/sysdeps/arm/nptl ports/sysdeps/arm sysdeps/wordsize-32 sysdeps/ieee754/flt-32 sysdeps/ieee754/dbl-64 sysdeps/ieee754 sysdeps/generic/elf sysdeps/generic
| checking for a BSD-compatible install... /media/DISK/meego/vjaquez-angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/x86_64-linux/usr/bin/install -c
| checking whether ln -s works... yes
| checking for arm-angstrom-linux-gnueabi-gcc... ccache arm-angstrom-linux-gnueabi-gcc -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -mthumb-interwork -mno-thumb
| checking for suffix of object files... o
| checking whether we are using the GNU C compiler... yes
| checking whether ccache arm-angstrom-linux-gnueabi-gcc -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -mthumb-interwork -mno-thumb accepts -g... yes
| checking for ccache arm-angstrom-linux-gnueabi-gcc -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -mthumb-interwork -mno-thumb option to accept ISO C89... unsupported
| checking for gcc... ccache gcc
| checking how to run the C preprocessor... arm-angstrom-linux-gnueabi-gcc -E
| configure: error: C preprocessor "arm-angstrom-linux-gnueabi-gcc -E" fails sanity check
| See `config.log' for more details.

Reading the config.log I found:

configure:3734: checking how to run the C preprocessor
configure:3850: result: arm-angstrom-linux-gnueabi-gcc -E
configure:3879: arm-angstrom-linux-gnueabi-gcc -E  conftest.c
In file included from /media/DISK/meego/vjaquez-angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/x86_64-linux/usr/armv7a/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/include-fixed/syslimits.h:7,
                 from /media/DISK/meego/vjaquez-angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/x86_64-linux/usr/armv7a/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/include-fixed/limits.h:11,
                 from conftest.c:10:
/media/DISK/meego/vjaquez-angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/x86_64-linux/usr/armv7a/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/include-fixed/limits.h:122:61: error: limits.h: No such file or directory
configure:3885: $? = 1
configure: failed program was:
| /* confdefs.h.  */
| #define PACKAGE_NAME "GNU C Library"
| #define PACKAGE_TARNAME "c-library"
| #define PACKAGE_VERSION "(see version.h)"
| #define PACKAGE_STRING "GNU C Library (see version.h)"
| #define PACKAGE_BUGREPORT "glibc"
| #define HAVE_LIBIDN 1
| /* end confdefs.h.  */
| #ifdef __STDC__
| # include <limits.h>
| #else
| # include <assert.h>
| #endif
| 		     Syntax error
configure:3879: arm-angstrom-linux-gnueabi-gcc -E  conftest.c
In file included from /media/DISK/meego/vjaquez-angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/x86_64-linux/usr/armv7a/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/include-fixed/syslimits.h:7,
                 from /media/DISK/meego/vjaquez-angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/x86_64-linux/usr/armv7a/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/include-fixed/limits.h:11,
                 from conftest.c:10:
/media/DISK/meego/vjaquez-angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/x86_64-linux/usr/armv7a/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/include-fixed/limits.h:122:61: error: limits.h: No such file or directory
configure:3885: $? = 1

So, the problem is that the pre-processor is _unable_ to find the *correct*
header limits.h. Why? Because it does not exist in the sysroot!!!!

$ find tmp-angstrom_2008_1/sysroots/armv7a-angstrom-linux-gnueabi/ -name "limits.h"
tmp-angstrom_2008_1/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/include-fixed/limits.h
tmp-angstrom_2008_1/sysroots/armv7a-angstrom-linux-gnueabi/usr/include/c++/4.3.3/tr1/limits.h
tmp-angstrom_2008_1/sysroots/armv7a-angstrom-linux-gnueabi/usr/include/linux/limits.h

Why? Why the toolchain does not install a sane limits.h in a sane directory?

Thanks.

vmjl

1. http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-January/028942.html

Re: problems compiling glibc_2.9-r37.4 under Angstrom

[Khem Raj]

2011/1/20 Víctor M. Jáquez L. <vjaquez@igalia.com>:
>
> In order to build native-sdk-image recipe, I found my self compiling
> glibc_2.9-r37.4, because it is the real provider of virtual-libc-dev (the
> toolchain does not truly provide it -but that is another bug [1]-).
>
> But the glibc_2.9-r37.4 configuration fails using the canonical
> arm-angstrom-linux-gnueabi- toolchain (using the csl external toolchain fails
> too, but for other reasons):
>
> Log data follows:
> | configure.in:2204: warning: AC_CACHE_VAL(pic_default, ...): suspicious cache-id, must contain _cv_ to be cached
> | ../../lib/autoconf/general.m4:1999: AC_CACHE_VAL is expanded from...
> | ../../lib/autoconf/general.m4:2020: AC_CACHE_CHECK is expanded from...
> | configure.in:2204: the top level
> | checking build system type... x86_64-pc-linux-gnu
> | checking host system type... arm-angstrom-linux-gnueabi
> | checking add-on ports for preconfigure fragments... am33 arm hppa m68k mips
> | configure: running configure fragment for add-on nptl
> | configure: running configure fragment for add-on libidn
> | checking sysdep dirs... ports/sysdeps/arm/elf ports/sysdeps/unix/sysv/linux/arm/eabi/nptl ports/sysdeps/unix/sysv/linux/arm/eabi sysdeps/unix/sysv/linux/arm/eabi ports/sysdeps/unix/sysv/linux/arm/nptl ports/sysdeps/unix/sysv/linux/arm sysdeps/unix/sysv/linux/arm ports/sysdeps/unix/sysv/linux nptl/sysdeps/unix/sysv/linux nptl/sysdeps/pthread sysdeps/pthread sysdeps/unix/sysv/linux sysdeps/gnu sysdeps/unix/common sysdeps/unix/mman sysdeps/unix/inet ports/sysdeps/unix/sysv nptl/sysdeps/unix/sysv sysdeps/unix/sysv ports/sysdeps/unix/arm ports/sysdeps/unix nptl/sysdeps/unix sysdeps/unix sysdeps/posix ports/sysdeps/arm/eabi ports/sysdeps/arm/fpu ports/sysdeps/arm/nptl ports/sysdeps/arm sysdeps/wordsize-32 sysdeps/ieee754/flt-32 sysdeps/ieee754/dbl-64 sysdeps/ieee754 sysdeps/generic/elf sysdeps/generic
> | checking for a BSD-compatible install... /media/DISK/meego/vjaquez-angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/x86_64-linux/usr/bin/install -c
> | checking whether ln -s works... yes
> | checking for arm-angstrom-linux-gnueabi-gcc... ccache arm-angstrom-linux-gnueabi-gcc -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -mthumb-interwork -mno-thumb
> | checking for suffix of object files... o
> | checking whether we are using the GNU C compiler... yes
> | checking whether ccache arm-angstrom-linux-gnueabi-gcc -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -mthumb-interwork -mno-thumb accepts -g... yes
> | checking for ccache arm-angstrom-linux-gnueabi-gcc -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -mthumb-interwork -mno-thumb option to accept ISO C89... unsupported
> | checking for gcc... ccache gcc
> | checking how to run the C preprocessor... arm-angstrom-linux-gnueabi-gcc -E
> | configure: error: C preprocessor "arm-angstrom-linux-gnueabi-gcc -E" fails sanity check
> | See `config.log' for more details.
>
> Reading the config.log I found:
>
> configure:3734: checking how to run the C preprocessor
> configure:3850: result: arm-angstrom-linux-gnueabi-gcc -E
> configure:3879: arm-angstrom-linux-gnueabi-gcc -E  conftest.c
> In file included from /media/DISK/meego/vjaquez-angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/x86_64-linux/usr/armv7a/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/include-fixed/syslimits.h:7,
>                 from /media/DISK/meego/vjaquez-angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/x86_64-linux/usr/armv7a/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/include-fixed/limits.h:11,
>                 from conftest.c:10:
> /media/DISK/meego/vjaquez-angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/x86_64-linux/usr/armv7a/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/include-fixed/limits.h:122:61: error: limits.h: No such file or directory


you might try to use eglibc. It may fix this issue for you.

Re: problems compiling glibc_2.9-r37.4 under Angstrom

[Víctor M. Jáquez L.]

On Thu, Jan 20, 2011 at 01:40:19PM -0800, Khem Raj wrote:
> 2011/1/20 Víctor M. Jáquez L. <vjaquez@igalia.com>:
> >
> > In order to build native-sdk-image recipe, I found my self compiling
> > glibc_2.9-r37.4, because it is the real provider of virtual-libc-dev (the
> > toolchain does not truly provide it -but that is another bug [1]-).
> >
> > But the glibc_2.9-r37.4 configuration fails using the canonical
> > arm-angstrom-linux-gnueabi- toolchain (using the csl external toolchain fails
> > too, but for other reasons):
> >
> > Log data follows:
> > [snip]
> 
> 
> you might try to use eglibc. It may fix this issue for you.
> 

Thanks. I'm giving a try to minimal distribution according to Yuri's
observation [1].

1. http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-January/028950.html

Re: problems compiling glibc_2.9-r37.4 under Angstrom

[Frans Meulenbroeks]

2011/1/21 Víctor M. Jáquez L. <vjaquez@igalia.com>:
> On Thu, Jan 20, 2011 at 01:40:19PM -0800, Khem Raj wrote:
>> 2011/1/20 Víctor M. Jáquez L. <vjaquez@igalia.com>:
>> >
>> > In order to build native-sdk-image recipe, I found my self compiling
>> > glibc_2.9-r37.4, because it is the real provider of virtual-libc-dev (the
>> > toolchain does not truly provide it -but that is another bug [1]-).
>> >
>> > But the glibc_2.9-r37.4 configuration fails using the canonical
>> > arm-angstrom-linux-gnueabi- toolchain (using the csl external toolchain fails
>> > too, but for other reasons):
>> >
>> > Log data follows:
>> > [snip]
>>
>>
>> you might try to use eglibc. It may fix this issue for you.
>>
>
> Thanks. I'm giving a try to minimal distribution according to Yuri's
> observation [1].
>
> 1. http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-January/028950.html

Victor, apologies for hijacking your thread.

If you are interested to use minimal, be sure to give it a try.
It works like a charm for me. and according to the testing page on the
wiki (http://wiki.openembedded.org/index.php/Testing) there are
several reports for native-sdk-image building under the minimal distro
(for various machines).
And if you encounter issues, feel free to send another mail to the
list or join the #oe irc channel on freenode. Often there is someone
around in that channel willing to help you.

Enjoy OE! Frans (eFfeM on irc).

Re: problems compiling glibc_2.9-r37.4 under Angstrom

[Koen Kooi]

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

On 20-01-11 19:12, Víctor M. Jáquez L. wrote:
> 
> In order to build native-sdk-image recipe, I found my self compiling
> glibc_2.9-r37.4, because it is the real provider of virtual-libc-dev (the
> toolchain does not truly provide it -but that is another bug [1]-).
> 
> But the glibc_2.9-r37.4 configuration fails using the canonical
> arm-angstrom-linux-gnueabi- toolchain

If you're using angstrom 2008, glibc 2.9 is built by default. Trying to
rebuild it won't work because it will be missing headers due to all the
- -initial and -intermedia shuffle.
If you're using angstrom 2010, eglibc is built by default and should
providing virtual-libc-dev

Switching to minimal will only get you anguish, since it's broken by design.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFNOWfsMkyGM64RGpERAsqfAKC2L5KDSLLBSC0tES2r+Axm+rxGoQCfVssG
IDR7J61eU9hEKOTT2+CRW9M=
=R8yc
-----END PGP SIGNATURE-----

Re: problems compiling glibc_2.9-r37.4 under Angstrom

[Frans Meulenbroeks]

Dear board,

Can you please take action to developers badmouthing distro's and the
work of others.
This is now (at least) the 2nd time in 3 weeks (and actually Koen has
already quite a track record bashing others).

Thank you very much.
Frans

2011/1/21 Koen Kooi <k.kooi@student.utwente.nl>:
> Switching to minimal will only get you anguish, since it's broken by design.

and:

Am Freitag, den 31.12.2010, 20:38 +0100 schrieb Koen Kooi:
> The configurations I'm concerned about use angstrom-mirrors.bbclass, I
> don't care about others. I can send you my rate card if you want to pay
> me to support crap like minimal.

Re: problems compiling glibc_2.9-r37.4 under Angstrom

[Dr. Michael Lauer]

I fully agree and support this. It has become unbearable again.
To the risk of repeating myself, I feel this attitude is damaging
the reputation of the OpenEmbedded community and thus its
attractivity for contributors, both present and future ones.

Board, which options do we have?

:M:

Re: problems compiling glibc_2.9-r37.4 under Angstrom

[Philip Balister]

On 01/21/2011 03:29 AM, Frans Meulenbroeks wrote:
> Dear board,
>
> Can you please take action to developers badmouthing distro's and the
> work of others.
> This is now (at least) the 2nd time in 3 weeks (and actually Koen has
> already quite a track record bashing others).

Frans, I'm not going to google IRC and mailing list archives looking for 
similar remarks about Angstrom.

>
> Thank you very much.
> Frans
>
> 2011/1/21 Koen Kooi<k.kooi@student.utwente.nl>:
>> Switching to minimal will only get you anguish, since it's broken by design.
>
> and:
>
> Am Freitag, den 31.12.2010, 20:38 +0100 schrieb Koen Kooi:
>> The configurations I'm concerned about use angstrom-mirrors.bbclass, I
>> don't care about others. I can send you my rate card if you want to pay
>> me to support crap like minimal.

I think these remarks come from discussion over the pandaboard u-boot 
situation? If so, let's consider these options:

1) Remove the pandaboard machine from OE since it does not build for 
some people.

2) Force Koen to update the recipe to something that builds.

3) Do nothing.

No one is happy with the set of options, but the reality is some distros 
use source mirrors and do not have issues. Distros that do not use 
source mirrors are going to have problems with this and other recipes, 
so the onus is on them to resolve these issues. Resolving this is issue 
does not revolve around updating the recipe and pushing it un tested for 
the Panda, since this is not something that can be tested on another set 
of hardware.

So until someone who has a panda and the time and patience to work with 
u-boot, minimal will not work for panda. This is because the minimal 
distro is supposed to not use advanced OE features such as source 
mirrors and PREFERRED_VERSION pinning. Because of these decisions, it is 
entirely possible that minimal will not build for all combination by design.

Philip

Re: problems compiling glibc_2.9-r37.4 under Angstrom

[Dr. Michael Lauer]

Philip,

unfortunately you're not commenting on Frans' actual point,
which no longer has anything to do with the u-boot thing.

Board, when can we schedule a meeting?

:M:

Re: problems compiling glibc_2.9-r37.4 under Angstrom

[Dr. Michael Lauer]

ping?

Am 21.01.2011 um 16:12 schrieb Dr. Michael Lauer:

> Philip,
> 
> unfortunately you're not commenting on Frans' actual point,
> which no longer has anything to do with the u-boot thing.
> 
> Board, when can we schedule a meeting?
> 
> :M:
> 

Re: problems compiling glibc_2.9-r37.4 under Angstrom

[Graeme Gregory]

9-5 GMT weds-fri is normally ok with me, outisde these times I work a 
totally non related job.

G

On 24/01/2011 16:46, Dr. Michael Lauer wrote:
> ping?
>
> Am 21.01.2011 um 16:12 schrieb Dr. Michael Lauer:
>
>> Philip,
>>
>> unfortunately you're not commenting on Frans' actual point,
>> which no longer has anything to do with the u-boot thing.
>>
>> Board, when can we schedule a meeting?
>>
>> :M:
>>

Board meeting, was: Re: problems compiling glibc_2.9-r37.4 under Angstrom

[Philip Balister]

On 01/24/2011 08:49 AM, Graeme Gregory wrote:
> 9-5 GMT weds-fri is normally ok with me, outisde these times I work a
> totally non related job.

I'm working at a customer site through Wednesday and traveling Thursday. 
Is Friday during the hours Graeme lists ok?

We also need to cover:

1) Approval of applying to the LF for Yocto Project membership. I 
circulated the documents last week.

2) Decide to authorize having the server admins spend some money on 
builder issues. (See ka6sox's white paper I sent last week) He also has 
some other ideas, so we should budget an amount and let him work out 
what to do.

3) Brief discussion of travel reimbursements, although from discussions 
with board members, it may be more trouble than it is worth for events 
like FOSDEM.

4) We need to decide who is going to provide leadership to move forward 
with the Yocto project.

Philip

>
> G
>
> On 24/01/2011 16:46, Dr. Michael Lauer wrote:
>> ping?
>>
>> Am 21.01.2011 um 16:12 schrieb Dr. Michael Lauer:
>>
>>> Philip,
>>>
>>> unfortunately you're not commenting on Frans' actual point,
>>> which no longer has anything to do with the u-boot thing.
>>>
>>> Board, when can we schedule a meeting?
>>>
>>> :M:
>>>
>
>

Re: problems compiling glibc_2.9-r37.4 under Angstrom

[Khem Raj]

On Fri, Jan 21, 2011 at 6:30 AM, Philip Balister <philip@balister.org> wrote:
> I think these remarks come from discussion over the pandaboard u-boot
> situation? If so, let's consider these options:
>
> 1) Remove the pandaboard machine from OE since it does not build for some
> people.
>

well its a step backwards

> 2) Force Koen to update the recipe to something that builds.
>

he is master of his own time so its not right to force anybody its all
volunteer work and we should leverage each others work.

> 3) Do nothing.

Doesnt take us anywhere.

>
> No one is happy with the set of options, but the reality is some distros use
> source mirrors and do not have issues. Distros that do not use source
> mirrors are going to have problems with this and other recipes, so the onus
> is on them to resolve these issues. Resolving this is issue does not revolve
> around updating the recipe and pushing it un tested for the Panda, since
> this is not something that can be tested on another set of hardware.
>
> So until someone who has a panda and the time and patience to work with
> u-boot, minimal will not work for panda. This is because the minimal distro
> is supposed to not use advanced OE features such as source mirrors and
> PREFERRED_VERSION pinning. Because of these decisions, it is entirely
> possible that minimal will not build for all combination by design.
>

I would propose that we use angstrom-mirrors in minimal distro as a
backup to fetch
sources from.
something like this in minimal.conf would do it

SOURCE_MIRROR_URL +=
"http://www.angstrom-distribution.org/unstable/sources/"
INHERIT += "own-mirrors"

if we do not want to inherit angstrom-mirrors class directly.
>

Re: problems compiling glibc_2.9-r37.4 under Angstrom

[Frans Meulenbroeks]

[taken the board off cc as this has nothing to do with my original
request to the board]

2011/1/22 Khem Raj <raj.khem@gmail.com>:
> On Fri, Jan 21, 2011 at 6:30 AM, Philip Balister <philip@balister.org> wrote:
>> I think these remarks come from discussion over the pandaboard u-boot
>> situation? If so, let's consider these options:
>>
>> 1) Remove the pandaboard machine from OE since it does not build for some
>> people.
>>
>
> well its a step backwards
>
>> 2) Force Koen to update the recipe to something that builds.
>>
>
> he is master of his own time so its not right to force anybody its all
> volunteer work and we should leverage each others work.
>
>> 3) Do nothing.
>
> Doesnt take us anywhere.
>
>>
>> No one is happy with the set of options, but the reality is some distros use
>> source mirrors and do not have issues. Distros that do not use source
>> mirrors are going to have problems with this and other recipes, so the onus
>> is on them to resolve these issues. Resolving this is issue does not revolve
>> around updating the recipe and pushing it un tested for the Panda, since
>> this is not something that can be tested on another set of hardware.
>>
>> So until someone who has a panda and the time and patience to work with
>> u-boot, minimal will not work for panda. This is because the minimal distro
>> is supposed to not use advanced OE features such as source mirrors and
>> PREFERRED_VERSION pinning. Because of these decisions, it is entirely
>> possible that minimal will not build for all combination by design.
>>
>
> I would propose that we use angstrom-mirrors in minimal distro as a
> backup to fetch
> sources from.
> something like this in minimal.conf would do it
>
> SOURCE_MIRROR_URL +=
> "http://www.angstrom-distribution.org/unstable/sources/"
> INHERIT += "own-mirrors"
>
> if we do not want to inherit angstrom-mirrors class directly.
>>
>

Khem, this is not about panda uboot, but about the behaviour of
members towards others.

As far as u-boot and panda concerns. I don't care any more.
If that is the way TI employees want to support their customers, it is
their choice, not mine.

Wrt the source mirror.
I would suggest to use http://sources.openembedded.org/ as official OE
mirror. We could use the angstrom mirror as starting point to further
populate the OE mirror. Alternately I have a fair amount of tarballs
etc that I can contribute (also some for the older days, but none
related to opie like things) And of course someone could also do a
fetchall or so (I seem to recall Martin already did soemthing like
that in the past)

Best regards, Frans.

Re: problems compiling glibc_2.9-r37.4 under Angstrom

[Khem Raj]

On Fri, Jan 21, 2011 at 3:03 AM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 20-01-11 19:12, Víctor M. Jáquez L. wrote:
>>
>> In order to build native-sdk-image recipe, I found my self compiling
>> glibc_2.9-r37.4, because it is the real provider of virtual-libc-dev (the
>> toolchain does not truly provide it -but that is another bug [1]-).
>>
>> But the glibc_2.9-r37.4 configuration fails using the canonical
>> arm-angstrom-linux-gnueabi- toolchain
>
> If you're using angstrom 2008, glibc 2.9 is built by default. Trying to
> rebuild it won't work because it will be missing headers due to all the
> - -initial and -intermedia shuffle.
> If you're using angstrom 2010, eglibc is built by default and should
> providing virtual-libc-dev

yes angstrom-2010.x is a better option keep in mind its new so expect
some churn every now and then.

>
> Switching to minimal will only get you anguish, since it's broken by design.

Heh interesting :) It would help if you elaborate on the flaws so we
can improve it and in turn improve OE in general


> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
>
> iD8DBQFNOWfsMkyGM64RGpERAsqfAKC2L5KDSLLBSC0tES2r+Axm+rxGoQCfVssG
> IDR7J61eU9hEKOTT2+CRW9M=
> =R8yc
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: problems compiling glibc_2.9-r37.4 under Angstrom

[Koen Kooi]

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

On 22-01-11 01:21, Khem Raj wrote:
> On Fri, Jan 21, 2011 at 3:03 AM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
> On 20-01-11 19:12, Víctor M. Jáquez L. wrote:
>>>>
>>>> In order to build native-sdk-image recipe, I found my self compiling
>>>> glibc_2.9-r37.4, because it is the real provider of virtual-libc-dev (the
>>>> toolchain does not truly provide it -but that is another bug [1]-).
>>>>
>>>> But the glibc_2.9-r37.4 configuration fails using the canonical
>>>> arm-angstrom-linux-gnueabi- toolchain
> 
> If you're using angstrom 2008, glibc 2.9 is built by default. Trying to
> rebuild it won't work because it will be missing headers due to all the
> -initial and -intermedia shuffle.
> If you're using angstrom 2010, eglibc is built by default and should
> providing virtual-libc-dev
> 
>> yes angstrom-2010.x is a better option keep in mind its new so expect
>> some churn every now and then.
> 
> 
> Switching to minimal will only get you anguish, since it's broken by design.
> 
>> Heh interesting :) It would help if you elaborate on the flaws so we
>> can improve it and in turn improve OE in general

The design involves not using PREFERRED_PROVIDER for things like bluez
and not setting PREFERRED_VERSION for recipes, using source mirrors or
using things like insane.bbclass. As expected, you had to use pretty
much all those to get minimal to build something remotely usefull.

As Philip points out, people are free to deliberately not use those
advanced features, but they should also realize that any breakage due to
that is entirely their own fault.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFNOrsQMkyGM64RGpERAm+UAJ9YGoCY6P8irFVlcWPF3N5TinD93gCfXU2V
2BBSC/hC7I7ynDgUAps4VuQ=
=RB3v
-----END PGP SIGNATURE-----

Re: problems compiling glibc_2.9-r37.4 under Angstrom

[Frans Meulenbroeks]

2011/1/22 Koen Kooi <k.kooi@student.utwente.nl>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 22-01-11 01:21, Khem Raj wrote:
>> On Fri, Jan 21, 2011 at 3:03 AM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
>> On 20-01-11 19:12, Víctor M. Jáquez L. wrote:
>>>>>
>>>>> In order to build native-sdk-image recipe, I found my self compiling
>>>>> glibc_2.9-r37.4, because it is the real provider of virtual-libc-dev (the
>>>>> toolchain does not truly provide it -but that is another bug [1]-).
>>>>>
>>>>> But the glibc_2.9-r37.4 configuration fails using the canonical
>>>>> arm-angstrom-linux-gnueabi- toolchain
>>
>> If you're using angstrom 2008, glibc 2.9 is built by default. Trying to
>> rebuild it won't work because it will be missing headers due to all the
>> -initial and -intermedia shuffle.
>> If you're using angstrom 2010, eglibc is built by default and should
>> providing virtual-libc-dev
>>
>>> yes angstrom-2010.x is a better option keep in mind its new so expect
>>> some churn every now and then.
>>
>>
>> Switching to minimal will only get you anguish, since it's broken by design.
>>
>>> Heh interesting :) It would help if you elaborate on the flaws so we
>>> can improve it and in turn improve OE in general
>
> The design involves not using PREFERRED_PROVIDER for things like bluez

Do you mean this?
minimal.conf:PREFERRED_PROVIDER_bluez-utils-dbus = "bluez4"
minimal.conf:PREFERRED_PROVIDER_bluez-libs       = "bluez-libs"
minimal.conf:PREFERRED_PROVIDER_bluez-utils      = "bluez4"

> and not setting PREFERRED_VERSION for recipes, using source mirrors or

You mean like this:
minimal.conf:PREFERRED_QT_VERSION ?= "4.7.1"
minimal.conf:PREFERRED_VERSION_qt4-tools-native = "${PREFERRED_QT_VERSION}"
minimal.conf:PREFERRED_VERSION_qt4-tools-sdk = "${PREFERRED_QT_VERSION}"
minimal.conf:PREFERRED_VERSION_qt4-embedded = "${PREFERRED_QT_VERSION}"
minimal.conf:PREFERRED_VERSION_qt4-embedded-gles = "${PREFERRED_QT_VERSION}"
minimal.conf:PREFERRED_VERSION_qt4-x11-free = "${PREFERRED_QT_VERSION}"
minimal.conf:PREFERRED_VERSION_qt4-x11-free-gles = "${PREFERRED_QT_VERSION}"

minimal also includes sane-toolchain.inc which contains the preferred
versions of the toolchain.
(together with some other distros)

Yes there are less pinnings in minimal than in angstrom. Fortunately
not, I'd say. I assume this is because the minimal maintainers have
more confidence and trust in the package maintainers.

wrt the source mirrors.
I feel recipes should build without source mirror. However in some
cases (e.g. handhelds.org) a source mirror is useful. In my previous
reply I suggested to populate sources.openembedded.org. Those who need
it can use it.
If the sources for a recipe reside on a mirror only, the recipe
SRC_URI should be changed to reflect that. Whether a recipe fetches or
not should not depend on the distro.

> using things like insane.bbclass. As expected, you had to use pretty

get your facts straight. minimal uses insane.bbclass:
minimal.conf:INHERIT += "insane"
No idea when exactly it was added. I'm not the minimal maintainer),
but it is used now.

> much all those to get minimal to build something remotely usefull.

In my opinion it is more useful than a binary generator generating
untested (and probably unreproducible) images, but that is just my
opinion. If someone wants to play the digital equivalent of russian
roulette, who am I to deny it to them.
>
> As Philip points out, people are free to deliberately not use those
> advanced features, but they should also realize that any breakage due to
> that is entirely their own fault.

Have a nice weekend! Frans.

Re: problems compiling glibc_2.9-r37.4 under Angstrom

[Frans Meulenbroeks]

2011/1/22 Frans Meulenbroeks <fransmeulenbroeks@gmail.com>:
> 2011/1/22 Koen Kooi <k.kooi@student.utwente.nl>:

>
>> using things like insane.bbclass. As expected, you had to use pretty
>
> get your facts straight. minimal uses insane.bbclass:
> minimal.conf:INHERIT += "insane"
> No idea when exactly it was added. I'm not the minimal maintainer),
> but it is used now.

Withdrawing this last sentence.
Just after pressing send I noticed I added it myself last Xmas:
http://cgit.openembedded.org/cgit.cgi/openembedded/commit/conf/distro/minimal.conf?id=f118388495185c9469b69e68a6f9b7a2ebef17ef

Frans

Re: problems compiling glibc_2.9-r37.4 under Angstrom

[Graeme Gregory]

On 22/01/2011 12:36, Frans Meulenbroeks wrote:
> In my opinion it is more useful than a binary generator generating
> untested (and probably unreproducible) images, but that is just my
> opinion. If someone wants to play the digital equivalent of russian
> roulette, who am I to deny it to them.

Why don't you two just take this to the school playground, this is
getting ridiculus. Sort it out between you or shut up please. Im really
bored of reading this drivel now!

Graeme

Re: problems compiling glibc_2.9-r37.4 under Angstrom

[Frans Meulenbroeks]

2011/1/22 Graeme Gregory <dp@xora.org.uk>:
> On 22/01/2011 12:36, Frans Meulenbroeks wrote:
>> In my opinion it is more useful than a binary generator generating
>> untested (and probably unreproducible) images, but that is just my
>> opinion. If someone wants to play the digital equivalent of russian
>> roulette, who am I to deny it to them.
>
> Why don't you two just take this to the school playground, this is
> getting ridiculus. Sort it out between you or shut up please. Im really
> bored of reading this drivel now!

Then don't read it :-) You're not obliged to.
Just put us both in your kill file/spam filter/whatever. It is not
*that* difficult !

Frans