Mailing List Archive: uclibc/busybox environment

uclibc/busybox environment

Oct 9, 2004, 3:50 AM

Post #1 of 5 (1747 views)

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: uclibc/busybox environment [ In reply to ]

vapier at gentoo

Oct 9, 2004, 10:25 AM

Post #2 of 5 (1693 views)

Permalink

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: uclibc/busybox environment [ In reply to ]

solar at gentoo

Oct 9, 2004, 11:00 AM

Post #3 of 5 (1694 views)

Permalink

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

Re: uclibc/busybox environment [ In reply to ]

sander at knopper

Oct 9, 2004, 11:14 AM

Post #4 of 5 (1708 views)

Permalink

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: uclibc/busybox environment [ In reply to ]

mutex at gentoo

Oct 9, 2004, 11:21 AM

Post #5 of 5 (1701 views)

Permalink

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.

Mailing List Archive

Mailing List Archive

Attached Files: