Jeff Cunningham | 4 Jul 04:41
Favicon

Error building glibc for arm on AMD's?

I am new to this list. I'm hoping someone will be able to help me solve 
a problem building a toolchain for use with a 2.6 kernel on an arm9 
board using crossdev. The issue is this: I can build a toolchain 
successfully on a Pentium 4 dual-core machine. But when I try to build 
the exact same toolchain on either of two AMD boxes it fails with the 
same error while building glibc.

I looked through the archives of this mailing list without seeing 
anything relevant. I am hoping someone has seen this before and can tell 
me what I'm doing wrong. 

Here are the particulars:

The toolchain in question will build with the following command:

USE="-* nls glibc-omitfp nptl nptlonly tls" crossdev \
    --b 2.16.1-r3 \
    --g 4.1.1-r3 \
    --k 2.6.19.2-r2 \
    --l 2.3.6-r5 \
    -t arm-softfloat-linux-gnu

on the Intel P4 box is running Gentoo 2.6.18 (I don't know the revision 
number right now). But if fails on both of these:

    Athlon-xp box running Gentoo 2.6-19-r5 or 2.6-20-r8
    Duron box running Gentoo 2.6.17-r4

Here is the error message for either of the AMD's:

(Continue reading)

Ned Ludd | 4 Jul 10:10
Picon
Favicon

Re: Error building glibc for arm on AMD's?

On Tue, 2007-07-03 at 19:41 -0700, Jeff Cunningham wrote:
> I am new to this list. I'm hoping someone will be able to help me solve 
> a problem building a toolchain for use with a 2.6 kernel on an arm9 
> board using crossdev. The issue is this: I can build a toolchain 
> successfully on a Pentium 4 dual-core machine. But when I try to build 
> the exact same toolchain on either of two AMD boxes it fails with the 
> same error while building glibc.

Thats your env sneaking in. blame eradicator. Anyway what seems to work
for most people cleanly is to make a 32bit chroot and do your delopment
from there. 

Good luck.

> 
> I looked through the archives of this mailing list without seeing 
> anything relevant. I am hoping someone has seen this before and can tell 
> me what I'm doing wrong. 
> 
> Here are the particulars:
> 
> The toolchain in question will build with the following command:
> 
> USE="-* nls glibc-omitfp nptl nptlonly tls" crossdev \
>     --b 2.16.1-r3 \
>     --g 4.1.1-r3 \
>     --k 2.6.19.2-r2 \
>     --l 2.3.6-r5 \
>     -t arm-softfloat-linux-gnu
> 
(Continue reading)

Natanael Copa | 4 Jul 14:38
Picon
Gravatar

portage light?

Hi,

I wonder if there is a way to filter out things in portage that you dont
want. Like dev-dotnet, games-*, gnome-*, kde-*, x11-*

My portage tree is over 240MB and its really slow on older computers.

Any other tips to make portage more lightweight? Not only speed but also
size to save bandwidth/diskspace for my gentoo based project.

Natanael Copa

René Rhéaume | 4 Jul 14:42
Picon

Re: portage light?

On 7/4/07, Natanael Copa <natanael.copa@...> wrote:
> I wonder if there is a way to filter out things in portage that you dont
> want. Like dev-dotnet, games-*, gnome-*, kde-*, x11-*
Yes, there is. http://gentoo-wiki.com/TIP_Exclude_categories_from_emerge_sync
Janusz Syrytczyk | 4 Jul 14:50
Picon
Favicon

Re: portage light?

Dnia środa, 4 lipca 2007 14:38, Natanael Copa napisał:
> Hi,
>
> I wonder if there is a way to filter out things in portage that you dont
> want. Like dev-dotnet, games-*, gnome-*, kde-*, x11-*
>
> My portage tree is over 240MB and its really slow on older computers.
>
> Any other tips to make portage more lightweight? Not only speed but also
> size to save bandwidth/diskspace for my gentoo based project.
>
> Natanael Copa

Old subject. I suppose there are plenty of unofficial Portage trees but they 
are usually not supported (by a person, community).

I guess the easiest way is to maintain a portage individually. It's not hard 
and you are guaranteed to have exactly your favourite apps included.

--

-- 
Syrytczyk Janusz - Administrator serwerów
Centrum Informatyczne Uniwersytetu Opolskiego
Nr telefonu: +48 77 452-70-91
E-mail: jsyrytczyk@...
Natanael Copa | 4 Jul 15:21
Picon
Gravatar

Re: portage light?

On Wed, 2007-07-04 at 08:42 -0400, René Rhéaume wrote:
> On 7/4/07, Natanael Copa <natanael.copa@...> wrote:
> > I wonder if there is a way to filter out things in portage that you dont
> > want. Like dev-dotnet, games-*, gnome-*, kde-*, x11-*
> Yes, there is. http://gentoo-wiki.com/TIP_Exclude_categories_from_emerge_sync

I tried --exclude= in PORTAGE_RSYNC_EXTRA_OPTS before but i get lots of
messges like this:

inherits= ['toolchain-funcs', 'qt3', 'portability', 'flag-o-matic',
'kde', 'versionator', 'multilib', 'base', 'kde-functions', 'libtool',
'autotools', 'eutils']
ec= {'toolchain-funcs': ('/usr/portage/eclass', 1181979488L), 'qt3':
('/usr/portage/eclass', 1175259977L), 'portability':
('/usr/portage/eclass', 1167690947L), 'flag-o-matic':
('/usr/portage/eclass', 1178971547L), 'kde': ('/usr/portage/eclass',
1181583342L), 'versionator': ('/usr/portage/eclass', 1177356943L),
'multilib': ('/usr/portage/eclass', 1183334777L), 'base':
('/usr/portage/eclass', 1135001142L)}

So I was thinking that there maybe was a cleaner way to do it.

Thanks!

--

-- 
gentoo-embedded@... mailing list

Christopher Friedt | 10 Jul 15:12

Re: portage light?

Janusz Syrytczyk wrote:
> Old subject. I suppose there are plenty of unofficial Portage trees but they 
> are usually not supported (by a person, community).
> 
> I guess the easiest way is to maintain a portage individually. It's not hard 
> and you are guaranteed to have exactly your favourite apps included.

I would also suggest having your own portage tree for embedded purposes.

It's been working for me for quite some time. You can patch your own 
ebuilds very easily to remove a lot of bloat from the 'mainstream' ebuilds.

Portage also lends itself very easily to using overlays as 
'configurations'. What I mean is... you could a) have your own portage 
tree, and b) have an overlay that configures /etc/files to defaults for 
client A and c) have another overlay that configures /etc/config for 
client B

~/Chris
Christopher Friedt | 10 Jul 15:21

arm gnueabi / uClibc

I've been out of the loop for a tiny bit, so could anyone shed some 
light on the status of the EABI on ARM processors for me?

Is it compatible with any version of uClibc ?

Specifically, I have an ARM920T, as well as an ARM926EJ target to 
compile for (ep93xx,marvell orion - www.embeddedarm.com), and I would 
like to continue using uClibc if possible.

Since I do most of my ARM compilation natively using Qemu, this is only 
necessary for compiling kernels and occasionally hand-written apps.

Which versions of binutils, gcc, linux-headers, and uClibc work together 
correctly using crossdev, if any ?

Any horror stories, any words of warning?

Thanks in advance,

~/Chris

Christopher Friedt | 10 Jul 16:20

Re: failed to emerge arm-softfloat-linux-gnueabi toolchain

Ah cool...

I followed your link and it answered my question about which versions I 
should be using for --[klbg] ... It shouldn't be too hard for me to set 
this up in my own overlay with the necessary patches.

Thanks for the info ;-)

~/Chris

Vladimir Pouzanov wrote:
> I've tried to merge arm-softfloat-linux-gnueabi toolchain based on
> gcc-4.1.2/glibc-2.5/linux-headers-2.6.20-r1/binutils-2.17 but failed
> to compile glibc:
> ../ports/sysdeps/arm/eabi/setfpucw.c:26:26: error: asm/procinfo.h: No
> such file or directory
> ../ports/sysdeps/arm/eabi/setfpucw.c: In function '__setfpucw':
> ../ports/sysdeps/arm/eabi/setfpucw.c:31: error: 'HWCAP_VFP' undeclared
> (first use in this function)
> ../ports/sysdeps/arm/eabi/setfpucw.c:31: error: (Each undeclared
> identifier is reported only once
> ../ports/sysdeps/arm/eabi/setfpucw.c:31: error: for each function it
> appears in.)
> make[2]: *** 
>
[/var/tmp/cross/arm-softfloat-linux-gnueabi/portage/cross-arm-softfloat-linux-gnueabi/glibc-2.5/work/ 
> 
> build-default-arm-softfloat-linux-gnueabi-nptl/math/setfpucw.o] Error 1
> 
> It seems to be a known problem for gibc 2.5 and arm eabi (googled
(Continue reading)

Mike Frysinger | 10 Jul 22:25
Picon
Favicon
Gravatar

Re: arm gnueabi / uClibc

On Tuesday 10 July 2007, Christopher Friedt wrote:
> I've been out of the loop for a tiny bit, so could anyone shed some
> light on the status of the EABI on ARM processors for me?
>
> Is it compatible with any version of uClibc ?

uClibc-0.9.29 (which isnt in portage yet) is supposed to work, but i havent 
tested it myself
-mike

Gmane