Mailing List Archive: Can I get some interest in the uclibc-0.9.33.ebuild

Can I get some interest in the uclibc-0.9.33.ebuild

lists at wildgooses

Mar 1, 2012, 2:44 AM

Post #1 of 6 (3093 views)

Hi, could all uclibc users take a peek at:
https://bugs.gentoo.org/show_bug.cgi?id=308477

I have bumped the ebuild to 0.9.33 and also added some extremely hacky
patches to build iconv (and accidentally also locale) support. From my
limited understanding this almost works as expected and seems very
achievable to get to a fully working state. The iconv support is the
main thing I wanted. Locales seem to be included as part of the same
uclibc config switch, but don't add that much extra space - it would be
nice to have them independently selectable though

I need some help:
- Testing the iconv stuff and working on the patches so they can go upstream
- Fixing the ebuild to have an iconv flag to bring this stuff in a
selectable way
- Fixing the ebuild to allow selectable locales in some gentoo
acceptable way?
- Testing with hardened, ie gcc-4.5.3-r2 and the adjusted variable as
per bug (this brings SSP support to gcc on uclibc)
- Testing on as many other architectures than x86 as possible...

The goal is to get this into tree as a masked ebuild as soon as
possible. The rest of the tree is growing away from supporting uclibc
because its the easiest option. However, if we can get 0.9.33 in good
shape then we have a modern drop in libc replacement which supports
modern hardened compilers, nptl and more - it's then feasible to start
filing bugs to other packages to add small patches as appropriate. In
particular having even partially working iconv support in uclibc would
appear to reduce the number of packages with uclibc conditional compiles
by a large chunk...

Grateful for help getting this in shape

Thanks

Ed W

Re: Can I get some interest in the uclibc-0.9.33.ebuild [ In reply to ]

Mar 1, 2012, 7:13 AM

Post #2 of 6 (3000 views)

Ed W wrote:
> - Fixing the ebuild to allow selectable locales in some gentoo acceptable
> way?

I think this should use the glibc way, so that there is just one way.
This means /etc/locale.gen

//Peter

Re: Can I get some interest in the uclibc-0.9.33.ebuild [ In reply to ]

lists at wildgooses

Mar 1, 2012, 10:51 AM

Post #3 of 6 (2997 views)

On 01/03/2012 15:13, Peter Stuge wrote:
> Ed W wrote:
>> - Fixing the ebuild to allow selectable locales in some gentoo acceptable
>> way?
> I think this should use the glibc way, so that there is just one way.
> This means /etc/locale.gen
>
>

Sure - and the uclibc format seems similar to locale.gen

Patches obviously appreciated...

Also, I personally don't understand what the @modifiers do (exactly)

Ed W

Re: Can I get some interest in the uclibc-0.9.33.ebuild [ In reply to ]

lists at wildgooses

Mar 5, 2012, 2:06 PM

Post #4 of 6 (2998 views)

Come on... you know you want to...

Can we get some testing of this please? An updated uclibc is a real
blocker for supporting embedded - can we have a push to get this into
portage please?

Cheers

Ed W

On 01/03/2012 10:44, Ed W wrote:
> Hi, could all uclibc users take a peek at:
> https://bugs.gentoo.org/show_bug.cgi?id=308477
>
> I have bumped the ebuild to 0.9.33 and also added some extremely hacky
> patches to build iconv (and accidentally also locale) support. From
> my limited understanding this almost works as expected and seems very
> achievable to get to a fully working state. The iconv support is the
> main thing I wanted. Locales seem to be included as part of the same
> uclibc config switch, but don't add that much extra space - it would
> be nice to have them independently selectable though
>
> I need some help:
> - Testing the iconv stuff and working on the patches so they can go
> upstream
> - Fixing the ebuild to have an iconv flag to bring this stuff in a
> selectable way
> - Fixing the ebuild to allow selectable locales in some gentoo
> acceptable way?
> - Testing with hardened, ie gcc-4.5.3-r2 and the adjusted variable as
> per bug (this brings SSP support to gcc on uclibc)
> - Testing on as many other architectures than x86 as possible...
>
> The goal is to get this into tree as a masked ebuild as soon as
> possible. The rest of the tree is growing away from supporting uclibc
> because its the easiest option. However, if we can get 0.9.33 in good
> shape then we have a modern drop in libc replacement which supports
> modern hardened compilers, nptl and more - it's then feasible to start
> filing bugs to other packages to add small patches as appropriate. In
> particular having even partially working iconv support in uclibc would
> appear to reduce the number of packages with uclibc conditional
> compiles by a large chunk...
>
> Grateful for help getting this in shape
>
> Thanks
>
> Ed W
>

Re: Can I get some interest in the uclibc-0.9.33.ebuild [ In reply to ]

Mar 5, 2012, 2:54 PM

Post #5 of 6 (3002 views)

Ed W wrote:
> Come on... you know you want to...
>
> Can we get some testing of this please?

I do want to test it, but admit it has low priority in my busy life.

> can we have a push to get this into portage please?

I will help push if you help me test. I would like to have a minimal
system with asterisk. What do you suggest? I have plenty of
experience with catalyst, but I know you're not using it, so show us
your way?

With catalyst I would probably have to create a uclibc profile, if
case there isn't one already. Not a terribly big deal, but well, not
what I want to focus on right now.

//Peter

Re: Can I get some interest in the uclibc-0.9.33.ebuild [ In reply to ]

lists at wildgooses

Mar 6, 2012, 8:20 AM

Post #6 of 6 (2992 views)

Hi

> I will help push if you help me test. I would like to have a minimal
> system with asterisk. What do you suggest? I have plenty of
> experience with catalyst, but I know you're not using it, so show us
> your way?

I think probably that my way is suboptimal. I think Bertrands recent
post using crossdev is probably much neater.

However, what I do is simply grab a uclibc build environment. Chroot
into it (I have a script which sets up portage by symlinking and
mounting various dirs here and there). What you end up with is
effectively a running environment in the processor build and libc of
your choice. Clearly this doesn't work for archs that can't be run on
your CPU...

- Anyway, so chroot into build environment
- ROOT=/somedir emerge somestuff

If you scan back in the archives for posts from me with "ROOT=..." in
the body then you can see my basic skeleton. Happy to dig them out, if
they can't be found. It takes surprisingly few packages to build a
basic runnable system.

However, probably that's not what you want - not sure?

It is quite easy to do, but not a 2 min job if you haven't done it
before. Someone else documented the basic technique much better here:
http://www.anticore.org/ratgentoo/index.php?page=001 or google for
"tiny gentoo"...

> With catalyst I would probably have to create a uclibc profile, if
> case there isn't one already. Not a terribly big deal, but well, not
> what I want to focus on right now.
>

I suspect this is a better process from what you describe as your
experience. Just note the iconv pieces that I mentioned - they aren't
integrated into the ebuild at the moment and are really up for
discussion. As you yourself noted, adjust the futzing around with
db.txt to be something like
cat $FILEDIR/db.txt /etc/locale.gen > db.txt
This should merge locale.gen and generate the character conversions you
choose

If in doubt just comment out all that extra stuff I added - it's new and
not relevant to the main ebuild

Blah I'm rambling now...

Good luck

Ed W