Re: [gentoo-dev] Is X86 uclibc environment supported?

["Anthony G. Basile" <blueness@gentoo.org>]

On 5/2/16 5:27 PM, waltdnes@waltdnes.org wrote:
> On Mon, May 02, 2016 at 04:04:46PM -0400, Anthony G. Basile wrote
>> On 5/2/16 2:37 PM, waltdnes@waltdnes.org wrote:
>>> On Mon, May 02, 2016 at 10:37:45AM -0400, Ian Stakenvicius wrote
>>>> On 29/04/16 09:34 PM, waltdnes@waltdnes.org wrote:
>>>>> On Fri, Apr 29, 2016 at 08:19:53PM -0400, Anthony G. Basile wrote
>>>>>
>>>>>> 1) i support uclibc across many arches. see
>>>>>>
>>>>>> https://wiki.gentoo.org/wiki/Project:Hardened_uClibc
>>>>>>
>>>>>>
>>>>>> 2) you can file uclibc bugs and i will look at them.  i know about that
>>>>>> one and i've got the fix upstream.  its going slowly because the bug was
>>>>>> in libcheck which is bundled with gstreamer and so there's layers of
>>>>>> backporting.  see
>>>>>>
>>>>>> https://bugs.gentoo.org/show_bug.cgi?id=577312
>>>>>
>>>>>   Thanks.  For the time-being, I'll try building Pale Moon without HTML5
>>>>> video support.  It may turn up other problems.
>>>>>
>>>>
>>>>
>>>> If you needed this for Firefox, grab 45.x or 46.0 since you can get
>>>> HTML5 support from ffmpeg directly without needing gstreamer.
>>>
>>>   Firefox's "Australis" can best be described as "the systemd of GUI's".
>>> It's what drove me away from Firefox to Pale moon, in the first place,
>>> and I'm not going back.
>>>
>>>   I understand that Anthony is frustrated with uclibc, and is working on
>>> replacing it with the uclibc-ng fork in the uclibc stage 3.  I've run
>>> into other issues, besides gstreamer, in uclibc.  Hopefully, uclibc-ng
>>> will have fewer issues.  For now, I'll simply wait until the uclibc-ng
>>> stage 3 comes out.
>>>
>>
>> Yes, I am frustrated with uClibc and I'm just one package and a few
>> stabilizations away from switching to uclibc-ng.  The problem is that
>> upstream is very far behind in patches, and even further behind in
>> releases.  So you submit a patch and you don't even know if it will
>> apply cleanly because its in a queue of submissions that have not even
>> hit git master/HEAD.  Or you want to back port a fix to the 0.9.33
>> branch and there's a dozen other intermediate patches that have to be
>> applied first.  Since these patches really address other issues, you're
>> cutting and pasting code.  Its a mess.
> 
>   Let me know offline if/when you need a beta tester.  I have QEMU and
> an ancient 32-bit-only Atom netbook that could really use a smaller
> libc.
> 

well at some point i'll start throwing stages up in
distfiles.gentoo.org/experimental/<arch>/uclibc-ng.  I'll let the list
know and it'll be open season on those tarballs.  I'll give them about 6
months or so and then drop the older uclibc ones.

Beta testing is always welcome, but building stage3's consistently and
repeatedly is usually a good indicator that they're good to go.

The big problem is going to be the migration.  You can't just unmerge
uclibc and emerge uclibc-ng.  The two hard block one another for that
reason.  The migration path I took is really really dirty but works:

1. ebuild uclibc-ng-<version>.ebuild clean install
3. Copy .so files from /var/tmp/portage/.../image/lib to /lib
   Since the .so versions are different they won't overwrite.
4. Use a static binary to switch over the sym links to the new .so's
5. emerge uclibc-ng properly
6. re-emerge world

I can automate some of that with scripts, but it will take care on the
part of the user who should be ready to boot off of rescue media.  I'm
going to recommend that people really avoid that if possible and start anew.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA