Re: [gentoo-hardened] New uclibc profiles will hit the tree soon

[Anthony G. Basile]

On 12/14/2012 05:31 AM, Ed W wrote:
> Hey, cool!
>
> Sorry, bit slow keeping up with the list. Great work though! I have been
> using x86 uclibc for a year now on an embedded router distro, so
> completely behind this. With new uclibc+nptl there are generally very
> few build problems. Main problem is builds which exclude iconv and
> gettext... (eg glib needs some hacking)

Recent >glib-2.30.3 + uclibc is a real pita and breaking everything that 
links against glib.  I'm busy with other stuff but glib is the major 
stumbling block now.  I think the problem is in pthreads.  I haven't had 
time to git bisect it down to the breaking commit.

>
> Just a couple of random thoughts:
>
> - You pull in libiconv as a required package? Wasn't the complaint that
> this could cause problems with GCC upgrades later? Note I have some
> patches that I submitted in the past which allow uclibc to build a
> partly working iconv (almost certainly got bugs, but seems to pass the
> obvious tests)

In cross compiling with CHOST= a glibc system, uclibc iconv code builds 
fine.  But it does not build fine on a native uclibc system.  Lots of 
things need iconv now, even coreutils.  See bug #445716.

>
> - You have -iconv as a git use, but I think most git ebuilds are forcing
> it back on again no matter what you say?

That's an old workaround.  It should work now.  Let me know.

>
> - You appear to mask nls? How about defaulting it to off rather than
> forcing it off? I'm still unclear what problems are actually caused by
> installing gettext? Seems like it can cause a permanent dep with gcc
> linking to it, but for some situations that is probably not the end of
> the world? Surely some people want nls on... (not me)

Okay but please test and open a bug.  Tell me what arch you tested on, 
exactly what change was made to the profiles etc.

>
>
> It would definitely be good to try and get people building uclibc with
> iconv - as in, hopefully people will file bugs and fix them and quickly
> we might end up with a proper working iconv in uclibc. Also canvasing
> for a mini gettext implementation for runtime use...
>
>
> Thanks for your work on this!

Pay me in beer or patches :)


>
> Ed W
>
>
> On 02/11/2012 11:24, Anthony G. Basile wrote:
>> Hi everyone,
>>
>> Can I get feedback regarding the subproject page at
>>
>> http://www.gentoo.org/proj/en/hardened/uclibc/
>>
>> before I link it up and announce it to the rest of the world.
>>
>> BTW, newer stage3's for amd64 and x86 uclibc are on the tree now under
>> experimental.
>>
>> --Tony
>>
>>
>> On 10/27/2012 06:17 AM, Anthony G. Basile wrote:
>>> Hi everyone,
>>>
>>> Either today or tomorrow, there will be two new experimental hardened
>>> profiles, one on amd64 and the other x86. These will be:
>>>
>>> hardened/linux/uclibc/amd64
>>>
>>> and
>>>
>>> hardened/linux/uclibc/x86
>>>
>>> Please be careful with them! Do not try to switch to these profiles from
>>> a glibc system. portage will complain about blocking and not let you
>>> proceed, but for the truly stubborn who will hack away until it does
>>> work, trust me, it will not work. It will utterly break everything.
>>>
>>> Aside: while this is an extreme case, switching profiles is never to be
>>> taken lightly. Eg. hardened <-> non-hardened or selinux <-> non-selinux.
>>>
>>> For the curious, you can play with these using the stage3's at
>>>
>>> http://http://67.151.215.237/
>>>
>>> Notice there are 4 combinations
>>>
>>> amd64 hardened
>>> amd64 vanilla
>>>
>>> i686 hardened
>>> i686 vanilla
>>>
>>> The amd64 are completely done. I'm working on i686 now so you may want
>>> to wait on those. Any stage marked on or later than oct 25 should be
>>> good.
>>>
>>> Note: the vanilla is just hardened with USE="-hardened" set in
>>> make.conf. They are being built as a comparison to the hardened.
>>>
>>>
>>>
>>
>>
>


-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
[phone]