Re: sparcv8 gcc

2009/6/24 Peter Stuge <peter@...>:
> Сергей Миронов wrote:
>> Mmm, iam using FPGA emulation board  ML402 with LEON3 cpu and
>> Gaisler's IP-blocks.
>
> Gaisler has a toolchain, right? Does that work?
>
> //Peter
>

Yes, gaisler toochain works fine with gaisler's Snapgear Linux. Hmm..
but is there an easy way to attach their precompiled gcc and binutils
to gentoo crossbuild system? Hmm..

--

-- 
Thanks,
Sergey

What creates

If I build a new image by running "emerge baselayout" into an empty 
directory (having unmasked baselayout 2 and openrc), then I get the 
following packages drawn in:

[binary  N    ] virtual/init-0 to /var/embedded/builds/base1/
[binary  N    ] sys-apps/baselayout-2.0.1 to /var/embedded/builds/base1/ 
USE="-build"
[binary  N    ] sys-apps/openrc-0.4.3-r3 to /var/embedded/builds/base1/ 
USE="ncurses -debug -pam -unicode"

Total: 3 packages (3 new), Size of downloads: 0 kB

But then openrc winges about:

 >>> Installing (3 of 3) sys-apps/openrc-0.4.3-r3 to 
/var/embedded/builds/base1/
 * checking 248 files for package collisions
 * Auto-adding 'termencoding' service to your boot runlevel
ln: creating symbolic link 
`/var/embedded/builds/base1//etc/runlevels/boot/termencoding': No such 
file or directory
 * Auto-adding 'bootmisc' service to your boot runlevel
ln: creating symbolic link 
`/var/embedded/builds/base1//etc/runlevels/boot/bootmisc': No such file 
or directory
..etc..

Which package is supposed to create 
/etc/runlevels/{boot,default,nonetwork, etc} ?

Re: What creates

Ed W wrote:
> But then openrc winges about:
>
> >>> Installing (3 of 3) sys-apps/openrc-0.4.3-r3 to 
> /var/embedded/builds/base1/
> * checking 248 files for package collisions
> * Auto-adding 'termencoding' service to your boot runlevel
> ln: creating symbolic link 
> `/var/embedded/builds/base1//etc/runlevels/boot/termencoding': No such 
> file or directory
> * Auto-adding 'bootmisc' service to your boot runlevel
> ln: creating symbolic link 
> `/var/embedded/builds/base1//etc/runlevels/boot/bootmisc': No such 
> file or directory
> ..etc..
>
>
> Which package is supposed to create 
> /etc/runlevels/{boot,default,nonetwork, etc} ?

Hmm, on further inspection it's possible that I just misunderstand the 
warning - now I look closer I believe that it's complaining about the 
far end of the symlink not existing, which is of course because the 
package is installing the file and the symlink right now?  Seems like a 
common ish situation though (installing file + symlink to new file?) - 
confusing warning?

Ed W

uclibc + glib 2 - possible?

Does anyone have any suggestions to getting glib 2.6 or newer to build 
against uclibc 0.9.30.1 (or similar)?

The docs claim it's masked because glib 2.6 and newer require iconv, 
which is increasingly unavailable on newer uclibc builds...

Actually I don't need locales, I just want to build gpsd to use dbus, 
and that appears to require a recent glib ...  Any suggestions?

Thanks

Ed W

Re: uclibc + glib 2 - possible?

2009/7/6 Ed W <lists@...>:
> Does anyone have any suggestions to getting glib 2.6 or newer to build
> against uclibc 0.9.30.1 (or similar)?
>
> The docs claim it's masked because glib 2.6 and newer require iconv, which
> is increasingly unavailable on newer uclibc builds...
>
> Actually I don't need locales, I just want to build gpsd to use dbus, and
> that appears to require a recent glib ...  Any suggestions?
>
> Thanks
>
> Ed W
>
>

yes, there is a hack on bugs gentoo org  , bug #104468 . it seems like
not much is happening with this bug, unfortunately :/

Re: uclibc + glib 2 - possible?

More breakage, more cutting edge packages and patches wanted...

Hardened and uclibc seem to be lagging a little these days.  I can see 
the argument for keeping quality high in the hardened builds (since 
users probably have a bunch of live servers like me!), however, I wonder 
if there isn't a case to go a bit more cutting with uclibc?

Is it fair to assume that uclibc is largely for less frequently updated 
systems, usually with an upstream developer testing builds before 
release?  Would it be sensible to push forward and tolerate the 
possibility of more "bugs" as a result? 

It seems to me that this might flush out more contributors and patches 
than the current situation?  For example I'm now sitting on a bunch of 
customised builds to build a small uclibc system and no doubt there are 
plenty of others doubling up on that effort?

Perhaps I'm missing an overlay which is easy to push changes to and 
folks here are regularly committing to...? If not do we need one?

Ed W

Re: make only builds X86_64 code

On Tuesday 16 June 2009 15:33:35 Sven Rebhan wrote:
> 2009/6/16 Stephen Feyrer <steve@...>:
> > This http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=5
>
> This is really old and not up-to-date anymore!

then you need to be submitting patches to update things.  the whole point of 
the handbook was to get away from random ass sites different people were 
maintaining and to make it easier for people to update things.  the handbook 
content is dead simple to update.  i havent seen a single bug report in 
bugs.gentoo.org about outdated information.
-mike

Re: What creates

On Thursday 02 July 2009 12:54:29 Ed W wrote:
> If I build a new image by running "emerge baselayout" into an empty
> directory (having unmasked baselayout 2 and openrc), then I get the
> following packages drawn in:
>
> [binary  N    ] virtual/init-0 to /var/embedded/builds/base1/
> [binary  N    ] sys-apps/baselayout-2.0.1 to /var/embedded/builds/base1/
> USE="-build"
> [binary  N    ] sys-apps/openrc-0.4.3-r3 to /var/embedded/builds/base1/
> USE="ncurses -debug -pam -unicode"
>
> Total: 3 packages (3 new), Size of downloads: 0 kB
>
> But then openrc winges about:
>  >>> Installing (3 of 3) sys-apps/openrc-0.4.3-r3 to
>
> /var/embedded/builds/base1/
>  * checking 248 files for package collisions
>  * Auto-adding 'termencoding' service to your boot runlevel
> ln: creating symbolic link
> `/var/embedded/builds/base1//etc/runlevels/boot/termencoding': No such
> file or directory
>  * Auto-adding 'bootmisc' service to your boot runlevel
> ln: creating symbolic link
> `/var/embedded/builds/base1//etc/runlevels/boot/bootmisc': No such file
> or directory
> ..etc..

file a bug please
-mike

crossdev

Hello all I'm after help on crossdev again.
My host system is amd64, stage required is s3.
The target is arm cortex with using newlib.

If I try crossdev -s3 -t arm-elf-gnueabi
in the summary header libc: glibc-[latest]
and it fails with BFD does not support target.

If I try crossdev -s3 -t arm-elf-eabi (also arm-unknown-elf-eabi)
in the summary header libc: -[latest]
and it fails at cross-linux-headers as libc is unknown.

If I cheat
 and modify the /usr/sbin/crossdev script and change the default LPKG
from LPKG="" to LPKG="newlib" on line 343.
in the summary header libc: newlib-[latest]
and it works fine and the code produced works on the chips, the same for
arm-none-eabi which is required for working with some of the sample code
provided.

If I add --ex-gdb (or --ex-insight) the summary has Extra: gdb: DO IT
but no gdb (or insight) is produced.

If I try, with no modification,  crossdev -s3 --ex-gdb -t
arm-unknown-linux-gnu it works fine, with no errors but produces no
extra gdb.

If I try, with my cheat, crossdev --ex-gdb -t arm-elf-eabi, fails with
"checking for acoshf in -lm... make[1] , is there any way to get gdb or
insight with s3?

Many thanks

Billy