[gentoo-embedded] Using latest uclibc snapshot from SVN

[gentoo-embedded] Using latest uclibc snapshot from SVN

[ryan.baldwin]

Hi,

I have been using crossdev and gentoo to build an uclibc embedded platform. I
have been buidling my toolchain using:

crossdev -binutils 2.16.1-r2 -gcc 3.4.5-r1 -libc 0.9.28 -kernel 2.6.16.20 -t
i386-pc-linux-uclibc

and

crossdev -binutils 2.16.1-r2 -gcc 3.4.5-r1 -libc 0.9.28 -kernel 2.6.16.20 -t
arm-softfloat-linux-uclibc

As you can see I am targeting both Intel and Arm platforms. I'm using 
portage snapshot from portage-20060703.tar.gz. I intend only to update the
portage snapshot I am using only if I need to to fix a bug or add features. 

Things have been working well, but there have been some issues with uclibc's
shared library loader, which so far I have worked around using LD_PRELOAD.
Having cross-compiled both mozilla for dfb and mozilla against X to use with
XDirectFB(dfb mozilla still seems to have some issues) these shared library
loader issues seem to be rearing there head again and I cant seem to work
around them with LD_PRELOAD for mozilla/X.

I have noticed though that since uclibc 0.9.28 there seems to have been a fair
bit of work done in uclibc's ldso directory and it looks like these bugs may
have been fixed there - hence the need to try and build against uclibc from
svn.

I have done this by creating a new uclibc-1.0.0.ebuild (version 1.0.0 just to
provide something.). I place the latest uclibc snapshot in in
/usr/portage/distfiles/uClibc-1.0.0.tar.gz. To make this build I had to use
the pregenerated uClibc locale stuff, make the ebuild fix up KERNEL_HEADERS
rather then KERNEL_SOURCE and in extra/locale 'ln -s ../../include include' so
this part could find it's headers. I also set 'PATCH_VER=""' assuming that
these fixes would probarbly be included in the latest SVN version.
(Please let me know if theres a more appropiate way to do this using the
uclibc ebuild - I noticed a reference to SVN_VER in the ebuild but it wasnt
clear how to use this, what it does or if it workes.  )

This now build's OK and I can compile everything else against it. The problem
comes though trying to use it in 
"crossdev -binutils 2.16.1-r2 -gcc 3.4.5-r1 -libc 1.0.0 -kernel 2.6.16.20 -t
i386-pc-linux-uclibc"

to build the toolchain with uclibc from svn. It falls over in  gcc-stage2 with
the following build errors:

/bin/sh ../libtool --tag CXX --mode=compile
/var/tmp/cross/i386-pc-linux-uclibc/portage/gcc-3.4.5-r1/work/build/gcc/xgcc
-shared-libgcc
-B/var/tmp/cross/i386-pc-linux-uclibc/portage/gcc-3.4.5-r1/work/build/gcc/
-nostdinc++
-L/var/tmp/cross/i386-pc-linux-uclibc/portage/gcc-3.4.5-r1/work/build/i386-pc-linux-uclibc/libstdc++-v3/src
-L/var/tmp/cross/i386-pc-linux-uclibc/portage/gcc-3.4.5-r1/work/build/i386-pc-linux-uclibc/libstdc++-v3/src/.libs
-B/usr/i386-pc-linux-uclibc/bin/ -B/usr/i386-pc-linux-uclibc/lib/ -isystem
/usr/i386-pc-linux-uclibc/include -isystem
/usr/i386-pc-linux-uclibc/sys-include 
-I/var/tmp/cross/i386-pc-linux-uclibc/portage/gcc-3.4.5-r1/work/build/i386-pc-linux-uclibc/libstdc++-v3/include/i386-pc-linux-uclibc
-I/var/tmp/cross/i386-pc-linux-uclibc/portage/gcc-3.4.5-r1/work/build/i386-pc-linux-uclibc/libstdc++-v3/include
-I/var/tmp/cross/i386-pc-linux-uclibc/portage/gcc-3.4.5-r1/work/gcc-3.4.5/libstdc++-v3/libsupc++
-g -Os -g -Os -fno-implicit-templates -Wall -W -Wwrite-strings -Wcast-qual 
-fdiagnostics-show-location=once  -ffunction-sections -fdata-sections  -c -o
ctype_members.lo ctype_members.cc
/var/tmp/cross/i386-pc-linux-uclibc/portage/gcc-3.4.5-r1/work/build/gcc/xgcc
-shared-libgcc
-B/var/tmp/cross/i386-pc-linux-uclibc/portage/gcc-3.4.5-r1/work/build/gcc/
-nostdinc++
-L/var/tmp/cross/i386-pc-linux-uclibc/portage/gcc-3.4.5-r1/work/build/i386-pc-linux-uclibc/libstdc++-v3/src
-L/var/tmp/cross/i386-pc-linux-uclibc/portage/gcc-3.4.5-r1/work/build/i386-pc-linux-uclibc/libstdc++-v3/src/.libs
-B/usr/i386-pc-linux-uclibc/bin/ -B/usr/i386-pc-linux-uclibc/lib/ -isystem
/usr/i386-pc-linux-uclibc/include -isystem
/usr/i386-pc-linux-uclibc/sys-include
-I/var/tmp/cross/i386-pc-linux-uclibc/portage/gcc-3.4.5-r1/work/build/i386-pc-linux-uclibc/libstdc++-v3/include/i386-pc-linux-uclibc
-I/var/tmp/cross/i386-pc-linux-uclibc/portage/gcc-3.4.5-r1/work/build/i386-pc-linux-uclibc/libstdc++-v3/include
-I/var/tmp/cross/i386-pc-linux-uclibc/portage/gcc-3.4.5-r1/work/gcc-3.4.5/libstdc++-v3/libsupc++
-g -Os -g -Os -fno-implicit-templates -Wall -W -Wwrite-strings -Wcast-qual
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections -c
ctype_members.cc  -fPIC -DPIC -o .libs/ctype_members.o
In file included from /usr/i386-pc-linux-uclibc/sys-include/stdio.h:72,
                 from
/var/tmp/cross/i386-pc-linux-uclibc/portage/gcc-3.4.5-r1/work/build/i386-pc-linux-uclibc/libstdc++-v3/include/cstdio:52,
                 from
/var/tmp/cross/i386-pc-linux-uclibc/portage/gcc-3.4.5-r1/work/build/i386-pc-linux-uclibc/libstdc++-v3/include/i386-pc-linux-uclibc/bits/c++locale.h:42,
                 from
/var/tmp/cross/i386-pc-linux-uclibc/portage/gcc-3.4.5-r1/work/build/i386-pc-linux-uclibc/libstdc++-v3/include/bits/localefwd.h:46,
                 from
/var/tmp/cross/i386-pc-linux-uclibc/portage/gcc-3.4.5-r1/work/build/i386-pc-linux-uclibc/libstdc++-v3/include/locale:44,
                 from ctype_members.cc:37:
/usr/i386-pc-linux-uclibc/sys-include/bits/uClibc_stdio.h:346: error: expected
initializer before "attribute_hidden"
/usr/i386-pc-linux-uclibc/sys-include/bits/uClibc_stdio.h:347: error: expected
initializer before "attribute_hidden"
/usr/i386-pc-linux-uclibc/sys-include/bits/uClibc_stdio.h:361: error: expected
initializer before "attribute_hidden"
make[3]: *** [ctype_members.lo] Error 1


I will look into the problem and if I find a solution will post it here. If
somebody already knows how to resolve this problem some advice would be
greatly appreciated.

Thanks

Ryan


-- 
gentoo-embedded@gentoo.org mailing list

[gentoo-embedded] overlay-specific keywords / use flags for cross-compiling

[Christopher Friedt]

Hi everyone,

I've set up a 'build root' that I can chroot into for cross development.
There is also a directory of targets to compile for, and for each 
target, a series of different configurations.

When I chroot into my buildroot my 'enter_chroot' script will 
automatically mount -o bind each of the sysroot, binpkgs, and overlay 
directories for a specified configuration, as well as mount -o bind the 
portage tree itself.

So my directory structure looks something like this:

gentoo-crossdev-buildroot/
   enter_chroot.sh
     (mounts proc, mounts -o bind portage/sysroot/binpkg/overlay etc)
   portage/
     ... (the portage tree)
   buildroot/
     ... (all cross compilation tools and a stage1 filesystem)
   targets/
     arm-9tdmi-linux-gnu/
       cross-toolchain/
       configurations/
         reference/
           overlay/
           binpkgs/
           sysroot/
         client1/
           ...
         client2/
           ...
     arm-9tdmi-linux-uclibc/
       cross-toolchain/
       configurations/
         reference/
           overlay/
           binpkgs/
           sysroot/
         client1/
           ...
         client2/
           ...

What I'm hoping to do is leverage the power of portage overlays here, 
and make it possible to have different package customizations for each 
client and each platform that my company deals with.

It doesn't take a lot to see that this is a great way to minimize 
maintenance.

My problem though, is that when doing cross development (I use the 
xmerge scrypt and set a SYSROOT variable), I have noticed that when I 
set new flags in $SYSROOT/etc/portage/package.use, it's not noticed 
properly during emerge.

I'm hoping that portage can be flexible enough to acknowlege those use 
flags. The xmerge script (taken from one of the gentoo cross development 
guides online) properly sets the PORTAGE_CONFIGROOT variable, ROOT, etc, 
so I don't understand why it doesn't acknowlege the changes in 
$SYSROOT/etc/portage/package.use.

Any suggestions?


Regards,

~/Chris
-- 
gentoo-embedded@gentoo.org mailing list

Re: [gentoo-embedded] overlay-specific keywords / use flags for cross-compiling

[Ned Ludd]

Is your $SYSROOT the same as your $PORTAGE_CONFIGROOT? 

Cuz portage only looks in $PORTAGE_CONFIGROOT and cares nothing of
$SYSROOT..


On Sat, 2007-01-13 at 00:12 +0100, Christopher Friedt wrote:
> Hi everyone,
> 
> I've set up a 'build root' that I can chroot into for cross development.
> There is also a directory of targets to compile for, and for each 
> target, a series of different configurations.
> 
> When I chroot into my buildroot my 'enter_chroot' script will 
> automatically mount -o bind each of the sysroot, binpkgs, and overlay 
> directories for a specified configuration, as well as mount -o bind the 
> portage tree itself.
> 
> So my directory structure looks something like this:
> 
> gentoo-crossdev-buildroot/
>    enter_chroot.sh
>      (mounts proc, mounts -o bind portage/sysroot/binpkg/overlay etc)
>    portage/
>      ... (the portage tree)
>    buildroot/
>      ... (all cross compilation tools and a stage1 filesystem)
>    targets/
>      arm-9tdmi-linux-gnu/
>        cross-toolchain/
>        configurations/
>          reference/
>            overlay/
>            binpkgs/
>            sysroot/
>          client1/
>            ...
>          client2/
>            ...
>      arm-9tdmi-linux-uclibc/
>        cross-toolchain/
>        configurations/
>          reference/
>            overlay/
>            binpkgs/
>            sysroot/
>          client1/
>            ...
>          client2/
>            ...
> 
> What I'm hoping to do is leverage the power of portage overlays here, 
> and make it possible to have different package customizations for each 
> client and each platform that my company deals with.
> 
> It doesn't take a lot to see that this is a great way to minimize 
> maintenance.
> 
> My problem though, is that when doing cross development (I use the 
> xmerge scrypt and set a SYSROOT variable), I have noticed that when I 
> set new flags in $SYSROOT/etc/portage/package.use, it's not noticed 
> properly during emerge.
> 
> I'm hoping that portage can be flexible enough to acknowlege those use 
> flags. The xmerge script (taken from one of the gentoo cross development 
> guides online) properly sets the PORTAGE_CONFIGROOT variable, ROOT, etc, 
> so I don't understand why it doesn't acknowlege the changes in 
> $SYSROOT/etc/portage/package.use.
> 
> Any suggestions?
> 
> 
> Regards,
> 
> ~/Chris
-- 
Ned Ludd <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-embedded@gentoo.org mailing list

Re: [gentoo-embedded] overlay-specific keywords / use flags for cross-compiling

[Christopher Friedt]

Hi Nedd,

Thanks for your reply - i've been crazy busy lately.

The ROOT & PORTAGE_CONFIGROOT directories are the same, and I tested out 
/sysroot/etc/portage/package.use. That works no problem.

However, i still don't see an effect if I do something in package.keywords.

I usually do this on my desktop machine if I'd like to open up the 
keywords for a particular package. Am I doing something wrong?


vaiprime / # echo "sys-apps/busybox" >> 
/sysroot/etc/portage/package.keywords
vaiprime / # xmerge -pv busybox

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   ] sys-apps/busybox-1.2.2.1 to /sysroot/ USE="static* 
-debug -make-symlinks -netboot -savedconfig" 1,380 kB

vaiprime / # ACCEPT_KEYWORDS="~arm" xmerge -avB busybox

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild     U ] sys-apps/busybox-1.3.1 [1.2.2.1] to /sysroot/ 
USE="static* -debug -make-symlinks -savedconfig (-netboot%)" 1,456 kB

Ned Ludd wrote:
> Is your $SYSROOT the same as your $PORTAGE_CONFIGROOT? 
> 
> Cuz portage only looks in $PORTAGE_CONFIGROOT and cares nothing of
> $SYSROOT..
> 
> 
> On Sat, 2007-01-13 at 00:12 +0100, Christopher Friedt wrote:
>> Hi everyone,
>>
>> I've set up a 'build root' that I can chroot into for cross development.
>> There is also a directory of targets to compile for, and for each 
>> target, a series of different configurations.
>>
>> When I chroot into my buildroot my 'enter_chroot' script will 
>> automatically mount -o bind each of the sysroot, binpkgs, and overlay 
>> directories for a specified configuration, as well as mount -o bind the 
>> portage tree itself.
>>
>> So my directory structure looks something like this:
>>
>> gentoo-crossdev-buildroot/
>>    enter_chroot.sh
>>      (mounts proc, mounts -o bind portage/sysroot/binpkg/overlay etc)
>>    portage/
>>      ... (the portage tree)
>>    buildroot/
>>      ... (all cross compilation tools and a stage1 filesystem)
>>    targets/
>>      arm-9tdmi-linux-gnu/
>>        cross-toolchain/
>>        configurations/
>>          reference/
>>            overlay/
>>            binpkgs/
>>            sysroot/
>>          client1/
>>            ...
>>          client2/
>>            ...
>>      arm-9tdmi-linux-uclibc/
>>        cross-toolchain/
>>        configurations/
>>          reference/
>>            overlay/
>>            binpkgs/
>>            sysroot/
>>          client1/
>>            ...
>>          client2/
>>            ...
>>
>> What I'm hoping to do is leverage the power of portage overlays here, 
>> and make it possible to have different package customizations for each 
>> client and each platform that my company deals with.
>>
>> It doesn't take a lot to see that this is a great way to minimize 
>> maintenance.
>>
>> My problem though, is that when doing cross development (I use the 
>> xmerge scrypt and set a SYSROOT variable), I have noticed that when I 
>> set new flags in $SYSROOT/etc/portage/package.use, it's not noticed 
>> properly during emerge.
>>
>> I'm hoping that portage can be flexible enough to acknowlege those use 
>> flags. The xmerge script (taken from one of the gentoo cross development 
>> guides online) properly sets the PORTAGE_CONFIGROOT variable, ROOT, etc, 
>> so I don't understand why it doesn't acknowlege the changes in 
>> $SYSROOT/etc/portage/package.use.
>>
>> Any suggestions?
>>
>>
>> Regards,
>>
>> ~/Chris
-- 
gentoo-embedded@gentoo.org mailing list

Re: [gentoo-embedded] overlay-specific keywords / use flags for cross-compiling

[Christopher Friedt]

Nevermind, I think I managed to discover where I went wrong - in 
portage, one needs to add the ~<arch> flag in 
/etc/portage/package.keywords to equivalently set 
ACCEPT_KEYWORDS="~<arch>" then?

The strange thing, is that on my plain-old i686 laptop, i usually just 
say 'sys-app/busybox' without the ~<arch> and it manages to set 
ACCEPT_KEYWORDS for that package to ~<arch> ....

wierd!

Christopher Friedt wrote:
> Hi Nedd,
> 
> Thanks for your reply - i've been crazy busy lately.
> 
> The ROOT & PORTAGE_CONFIGROOT directories are the same, and I tested out 
> /sysroot/etc/portage/package.use. That works no problem.
> 
> However, i still don't see an effect if I do something in package.keywords.
> 
> I usually do this on my desktop machine if I'd like to open up the 
> keywords for a particular package. Am I doing something wrong?
> 
> 
> vaiprime / # echo "sys-apps/busybox" >> 
> /sysroot/etc/portage/package.keywords
> vaiprime / # xmerge -pv busybox
> 
> These are the packages that would be merged, in order:
> 
> Calculating dependencies... done!
> [ebuild   R   ] sys-apps/busybox-1.2.2.1 to /sysroot/ USE="static* 
> -debug -make-symlinks -netboot -savedconfig" 1,380 kB
> 
> vaiprime / # ACCEPT_KEYWORDS="~arm" xmerge -avB busybox
> 
> These are the packages that would be merged, in order:
> 
> Calculating dependencies... done!
> [ebuild     U ] sys-apps/busybox-1.3.1 [1.2.2.1] to /sysroot/ 
> USE="static* -debug -make-symlinks -savedconfig (-netboot%)" 1,456 kB
> 
> Ned Ludd wrote:
>> Is your $SYSROOT the same as your $PORTAGE_CONFIGROOT?
>> Cuz portage only looks in $PORTAGE_CONFIGROOT and cares nothing of
>> $SYSROOT..
>>
>>
>> On Sat, 2007-01-13 at 00:12 +0100, Christopher Friedt wrote:
>>> Hi everyone,
>>>
>>> I've set up a 'build root' that I can chroot into for cross development.
>>> There is also a directory of targets to compile for, and for each 
>>> target, a series of different configurations.
>>>
>>> When I chroot into my buildroot my 'enter_chroot' script will 
>>> automatically mount -o bind each of the sysroot, binpkgs, and overlay 
>>> directories for a specified configuration, as well as mount -o bind 
>>> the portage tree itself.
>>>
>>> So my directory structure looks something like this:
>>>
>>> gentoo-crossdev-buildroot/
>>>    enter_chroot.sh
>>>      (mounts proc, mounts -o bind portage/sysroot/binpkg/overlay etc)
>>>    portage/
>>>      ... (the portage tree)
>>>    buildroot/
>>>      ... (all cross compilation tools and a stage1 filesystem)
>>>    targets/
>>>      arm-9tdmi-linux-gnu/
>>>        cross-toolchain/
>>>        configurations/
>>>          reference/
>>>            overlay/
>>>            binpkgs/
>>>            sysroot/
>>>          client1/
>>>            ...
>>>          client2/
>>>            ...
>>>      arm-9tdmi-linux-uclibc/
>>>        cross-toolchain/
>>>        configurations/
>>>          reference/
>>>            overlay/
>>>            binpkgs/
>>>            sysroot/
>>>          client1/
>>>            ...
>>>          client2/
>>>            ...
>>>
>>> What I'm hoping to do is leverage the power of portage overlays here, 
>>> and make it possible to have different package customizations for 
>>> each client and each platform that my company deals with.
>>>
>>> It doesn't take a lot to see that this is a great way to minimize 
>>> maintenance.
>>>
>>> My problem though, is that when doing cross development (I use the 
>>> xmerge scrypt and set a SYSROOT variable), I have noticed that when I 
>>> set new flags in $SYSROOT/etc/portage/package.use, it's not noticed 
>>> properly during emerge.
>>>
>>> I'm hoping that portage can be flexible enough to acknowlege those 
>>> use flags. The xmerge script (taken from one of the gentoo cross 
>>> development guides online) properly sets the PORTAGE_CONFIGROOT 
>>> variable, ROOT, etc, so I don't understand why it doesn't acknowlege 
>>> the changes in $SYSROOT/etc/portage/package.use.
>>>
>>> Any suggestions?
>>>
>>>
>>> Regards,
>>>
>>> ~/Chris
-- 
gentoo-embedded@gentoo.org mailing list

[gentoo-embedded] stage1 package list?

[Christopher Friedt]

Hi everyone,

I saw this posted in a document on the gentoo site a long time ago, but 
I can't remember where it is for the life of me.

Which packages comprise a 'stage 1' tarball in general ?

baselayout (normal / lite)
binutils
libc (uclibc / gnu)
gettext
bzip2
zlib
ncurses

?


I guess the question should be: what are the minimum packages needed on 
a root fs before deployment? I'll probably be using busybox too on at 
least one of my configurations.

Suggestions are very welcome.


~/Chris

-- 
gentoo-embedded@gentoo.org mailing list

Re: [gentoo-embedded] stage1 package list?

[Peter S. Mazinger]

On Fri, 19 Jan 2007, Christopher Friedt wrote:

> Hi everyone,
> 
> I saw this posted in a document on the gentoo site a long time ago, but 
> I can't remember where it is for the life of me.
> 
> Which packages comprise a 'stage 1' tarball in general ?
> 
> baselayout (normal / lite)
> binutils
> libc (uclibc / gnu)
> gettext
> bzip2
> zlib
> ncurses
> 
> ?

run USE="build" ROOT=/somedir emerge -pv baselayout binutils gcc \
uclibc/glibc bzip2 tar gzip make ncurses coreutils gawk grep \
binutils-config gcc-config portage

and see what it pulls in, that will approximately be the list

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2

-- 
gentoo-embedded@gentoo.org mailing list

Re: [gentoo-embedded] stage1 package list?

[momentics]

> what are the minimum packages needed on a root fs before deployment?

lately i build a micro one from binaries (versions are also included)
+ kernel image with grub.
After install & configuration some rarely used files were manually deleted.

some post fixes:

1) /etc/runlevels should be created
2) copy files from
/usr/share/baselayout/{fstab,group,hosts,passwd,shadow} to /etc
3) /dev/{console, nullm urandom,zero} must be created
4) modules-update - should generate modules.conf
5) passwords & users

and probably some additional actions that can't remember right now

baselayout-1.12.7-r4.tbz2, gawk-3.1.5-r2.tbz2, ncurses-5.5-r3.tbz2,
udev-103.tbz2, bash-3.2_p9.tbz2, glib-2.12.4-r1.tbz2,
pam-0.99.6.3-r2.tbz2, util-linux-2.12r-r5.tbz2, coreutils-6.7.tbz2,
libc-2.5.tbz2, shadow-4.0.18.1.tbz2, vixie-cron-4.1-r9.tbz2,
diffutils-2.8.7-r1.tbz2, grep-2.5.1a-r1.tbz2, syslog-ng-1.6.11-r1.tbz2,
xinetd-2.3.14.tbz2, e2fsprogs-1.39.tbz2, grub-0.97-r3.tbz2,
sysvinit-2.86-r6.tbz2, zlib-1.2.3-r1.tbz2, findutils-4.3.2.tbz2,
module-init-tools-3.2.2-r2.tbz2, timezone-data-2006p.tbz2,

hope it helps

---
http://sgrid.sf.net/
-- 
gentoo-embedded@gentoo.org mailing list

Re: [gentoo-embedded] stage1 package list?

[momentics]

> and probably some additional actions that can't remember right now

/var is rw, all the rest is ro partition

mkdir -p $SGRD/{bin,boot,dev,etc/opt,home,lib,mnt,opt,proc}
mkdir -p $SGRD/{mnt/{floppy,cdrom},sbin,sys,var}
install -d -m 0750 $SGRD/root
ln -s var/tmp $SGRD/tmp
install -d -m 1777 $SGRD/var/tmp
mkdir -p $SGRD/usr/{,local/}{bin,include,lib,sbin,src}
mkdir -p $SGRD/usr/{,local/}share/{doc,info,locale,man}
mkdir -p $SGRD/usr/{,local/}share/{misc,terminfo,zoneinfo}
mkdir -p $SGRD/usr/{,local/}share/man/man{1..8}
for dir in $SGRD/usr $SGRD/usr/local; do
ln -s share/{man,doc,info} $dir
done
mkdir -p $SGRD/var/{lock,log,mail,run,spool}
mkdir -p $SGRD/var/{opt,cache,lib/{misc,locate},local}

---
http://sgrid.sf.net/
-- 
gentoo-embedded@gentoo.org mailing list

Re: [gentoo-embedded] overlay-specific keywords / use flags for cross-compiling

[Peter S. Mazinger]

On Wed, 17 Jan 2007, Christopher Friedt wrote:

> Nevermind, I think I managed to discover where I went wrong - in 
> portage, one needs to add the ~<arch> flag in 
> /etc/portage/package.keywords to equivalently set 
> ACCEPT_KEYWORDS="~<arch>" then?
> 
> The strange thing, is that on my plain-old i686 laptop, i usually just 
> say 'sys-app/busybox' without the ~<arch> and it manages to set 
> ACCEPT_KEYWORDS for that package to ~<arch> ....

you could use category/package ~*
that will accomodate for all ~arch

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2

-- 
gentoo-embedded@gentoo.org mailing list

Re: [gentoo-embedded] Using latest uclibc snapshot from SVN

[Peter S. Mazinger]

On Mon, 8 Jan 2007 ryan.baldwin@nexusalpha.com wrote:

> /usr/i386-pc-linux-uclibc/sys-include/bits/uClibc_stdio.h:346: error: expected
> initializer before "attribute_hidden"

was fixed in svn, update your copy

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2

-- 
gentoo-embedded@gentoo.org mailing list

Re: [gentoo-embedded] Using latest uclibc snapshot from SVN

[Peter S. Mazinger]

On Mon, 8 Jan 2007 ryan.baldwin@nexusalpha.com wrote:

forgotten to answer the rest, here it comes
 
> I have done this by creating a new uclibc-1.0.0.ebuild (version 1.0.0 just to
> provide something.). I place the latest uclibc snapshot in in

I would call it 0.9.28.x, 0.9.29 is the next

> /usr/portage/distfiles/uClibc-1.0.0.tar.gz. To make this build I had to use
> the pregenerated uClibc locale stuff, make the ebuild fix up KERNEL_HEADERS
> rather then KERNEL_SOURCE and in extra/locale 'ln -s ../../include include' so

if you can avoid, dont enable locales
there are some more options that were renamed, ex. MMU related

> this part could find it's headers. I also set 'PATCH_VER=""' assuming that
> these fixes would probarbly be included in the latest SVN version.

correct

> (Please let me know if theres a more appropiate way to do this using the
> uclibc ebuild - I noticed a reference to SVN_VER in the ebuild but it wasnt
> clear how to use this, what it does or if it workes.  )

I create a diff between .28 and svn and use that diff in SVN_VER (if 
SVN_VER is defined, it will apply the "specially named" diff)

> This now build's OK and I can compile everything else against it. The problem
> comes though trying to use it in 
> "crossdev -binutils 2.16.1-r2 -gcc 3.4.5-r1 -libc 1.0.0 -kernel 2.6.16.20 -t
> i386-pc-linux-uclibc"

I mostly use arch-gentoo-linux-uclibc (and the stages of gentoo-embedded 
too), but it is finally not relevant, unless -softfloat-

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2

-- 
gentoo-embedded@gentoo.org mailing list