[gentoo-embedded] Can I get some interest in the uclibc-0.9.33.ebuild

[gentoo-embedded] Can I get some interest in the uclibc-0.9.33.ebuild

[Ed W]

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: [gentoo-embedded] Can I get some interest in the uclibc-0.9.33.ebuild

[Peter Stuge]

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: [gentoo-embedded] Can I get some interest in the uclibc-0.9.33.ebuild

[Ed W]

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: [gentoo-embedded] Can I get some interest in the uclibc-0.9.33.ebuild

[Ed W]

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: [gentoo-embedded] Can I get some interest in the uclibc-0.9.33.ebuild

[Peter Stuge]

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: [gentoo-embedded] Can I get some interest in the uclibc-0.9.33.ebuild

[Ed W]

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