[gentoo-embedded] uclibc/busybox environment

[gentoo-embedded] uclibc/busybox environment

[Sander Knopper]

Hi all,

I'm currently working on a gentoo based system which has to run on a usb 
stick.

I've been playing with the uclibc profile but that still gave me a lot of 
unneeded things. For example, I can't why how util-linux, automake, autoconf 
etc. etc. have to depend on perl. So I took another look and saw the embedded 
profile which to my surprise also uses busybox but doesn't use uclibc....

Is there a way to combine these two profiles or is it better to make one of my 
own? At the moment I would go with the second option since it would allow me 
to use busybox, uclibc and also give me the opportunity to leave utilities as 
gawk, grep, gzip and tar away because busybox already supplies them. I'll 
have to take the fact that these programs sometimes aren't fully compatible 
with their GNU relatives for granted.

So basically I'm planning to create a whole new profile which doesn't include 
the base files either since it forces me to install all these utilities I 
don't want.

Or is there an easier way?

Currently I'm using the buildroot scripts from uclibc.org but I just miss the 
abilities of a "package manager" so that's why I'm trying it this way.


Regards,

Sander Knopper

--
gentoo-embedded@gentoo.org mailing list

Re: [gentoo-embedded] uclibc/busybox environment

[Mike Frysinger]

On Saturday 09 October 2004 06:50 am, Sander Knopper wrote:
> Is there a way to combine these two profiles or is it better to make one of
> my own? At the moment I would go with the second option since it would
> allow me to use busybox, uclibc and also give me the opportunity to leave
> utilities as gawk, grep, gzip and tar away because busybox already supplies
> them. I'll have to take the fact that these programs sometimes aren't fully
> compatible with their GNU relatives for granted.

the idea was to use uclibc for development systems and embedded for the target 
(i think, solar can correct me)

ive been keeping the uclibc profile up-to-date, but i think the embedded one 
could use some work ...
-mike

--
gentoo-embedded@gentoo.org mailing list

Re: [gentoo-embedded] uclibc/busybox environment

[Ned Ludd]

[-- Attachment #1: Type: text/plain, Size: 2001 bytes --]

On Sat, 2004-10-09 at 13:25, Mike Frysinger wrote:
> On Saturday 09 October 2004 06:50 am, Sander Knopper wrote:
> > Is there a way to combine these two profiles or is it better to make one of
> > my own? At the moment I would go with the second option since it would
> > allow me to use busybox, uclibc and also give me the opportunity to leave
> > utilities as gawk, grep, gzip and tar away because busybox already supplies
> > them. I'll have to take the fact that these programs sometimes aren't fully
> > compatible with their GNU relatives for granted.
> 
> the idea was to use uclibc for development systems and embedded for the target 
> (i think, solar can correct me)
> 
> ive been keeping the uclibc profile up-to-date, but i think the embedded one 
> could use some work ...

Indeed the embedded one could. I've mentioned this one to Chris before 
about it using glibc vs uclibc by default on IRC but I think he was in
the middle of his work day. That profile was added long before we had a
pretty decent uClibc native environments setup so a instantaneous switch
might not be possible or we could break some existing users setups.

But as I see things it stands right now the embedded profile target 
could be split up into glibc/uclibc subsystems. We could use these
profiles for our vendor mini distros like soekris, wrt54g's. netwinders,
nslu2, video systems, pbx systems, kiosk, dumb terminals, etc.. 
However those profiles would have to be based on user/vendor submissions
as our gentoo devs only provocatively support what we have hardware for.
donations welcome be that time or hardware or documentation to help ease
this maze of what we call embedded.

But so far not a lot of effort has been put into this area of profiles 
because there has been lots of hurdles for us to overcome in the process
of the development environment alone.


-- 
Ned Ludd <solar@gentoo.org>
Gentoo (hardened,security,infrastructure,embedded,toolchain) Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-embedded] uclibc/busybox environment

[Sander Knopper]

Op zaterdag 9 oktober 2004 20:00, schreef Ned Ludd:
> On Sat, 2004-10-09 at 13:25, Mike Frysinger wrote:
> > On Saturday 09 October 2004 06:50 am, Sander Knopper wrote:
> > > Is there a way to combine these two profiles or is it better to make
> > > one of my own? At the moment I would go with the second option since it
> > > would allow me to use busybox, uclibc and also give me the opportunity
> > > to leave utilities as gawk, grep, gzip and tar away because busybox
> > > already supplies them. I'll have to take the fact that these programs
> > > sometimes aren't fully compatible with their GNU relatives for granted.
> >
> > the idea was to use uclibc for development systems and embedded for the
> > target (i think, solar can correct me)
> >
> > ive been keeping the uclibc profile up-to-date, but i think the embedded
> > one could use some work ...
>
> Indeed the embedded one could. I've mentioned this one to Chris before
> about it using glibc vs uclibc by default on IRC but I think he was in
> the middle of his work day. That profile was added long before we had a
> pretty decent uClibc native environments setup so a instantaneous switch
> might not be possible or we could break some existing users setups.
>
> But as I see things it stands right now the embedded profile target
> could be split up into glibc/uclibc subsystems. We could use these
> profiles for our vendor mini distros like soekris, wrt54g's. netwinders,
> nslu2, video systems, pbx systems, kiosk, dumb terminals, etc..
> However those profiles would have to be based on user/vendor submissions
> as our gentoo devs only provocatively support what we have hardware for.
> donations welcome be that time or hardware or documentation to help ease
> this maze of what we call embedded.
>
> But so far not a lot of effort has been put into this area of profiles
> because there has been lots of hurdles for us to overcome in the process
> of the development environment alone.

At the moment I've combined the two profiles, it seems to work at my computer. 
The most difficult part though, is to delete perl and some other packages. 
Especially since autoconf/automake and some other packages depend on it 
because of the wrapper. Currently I'm trying to overcome this by modifying 
some ebuilds and put them in portage-overlay but it's not very clean though.

I'm also thinking of just dropping automake/autoconf...;) The only packages 
that seems to depend on it is libtool and this is due to some bugs which I've 
to take a closer look at.

--
gentoo-embedded@gentoo.org mailing list

Re: [gentoo-embedded] uclibc/busybox environment

[David Bryson]

[-- Attachment #1: Type: text/plain, Size: 1666 bytes --]

On Sat, Oct 09, 2004 at 02:00:41PM -0400 or thereabouts, Ned Ludd wrote:
> Indeed the embedded one could. I've mentioned this one to Chris before 
> about it using glibc vs uclibc by default on IRC but I think he was in
> the middle of his work day. That profile was added long before we had a
> pretty decent uClibc native environments setup so a instantaneous switch
> might not be possible or we could break some existing users setups.
> 
> But as I see things it stands right now the embedded profile target 
> could be split up into glibc/uclibc subsystems. We could use these
> profiles for our vendor mini distros like soekris, wrt54g's. netwinders,
> nslu2, video systems, pbx systems, kiosk, dumb terminals, etc.. 
> However those profiles would have to be based on user/vendor submissions
> as our gentoo devs only provocatively support what we have hardware for.
> donations welcome be that time or hardware or documentation to help ease
> this maze of what we call embedded.
> 
> But so far not a lot of effort has been put into this area of profiles 
> because there has been lots of hurdles for us to overcome in the process
> of the development environment alone.

Yes solar is right.
I originally submitted the embedded profile as an example of something
i hacked together.  I have a cascading one that isn't quite finished
yet, but hopefully in a week or so.
The point was to get *something* so that other people could see how
it's done, unfortunatly it has turned into bit rot.
In the next couple of weeks I'll post the profile and some patches for
catalyst that *really* help automation for embedded system building.


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]