[gentoo-dev] Is X86 uclibc environment supported?

[gentoo-dev] Is X86 uclibc environment supported?

[waltdnes]

  I'm currently trying to get a 32 uclibc environment working in a QEMU
VM.  My eventual goal is to get my ancient 32-bit-only Atom netbook
working under uclibc.  Is it worth bothering to file bugs for stuff that
builds under glibc, but fails under uclibc?  Or should I forget it?  If
it's not supported, there's no point in bugging the developers.

  E.g. gstreamer-1.6.3 builds under glibc, but under uclibc...

In file included from /var/tmp/portage/media-libs/gstreamer-1.6.3/work/gstreamer-1.6.3/libs/gst/check/libcheck/check_error.c:25:0:
/usr/include/string.h:386:14: error: conflicting types for 'strsignal'
 extern char *strsignal (int __sig) __THROW;
              ^
In file included from /var/tmp/portage/media-libs/gstreamer-1.6.3/work/gstreamer-1.6.3/libs/gst/check/libcheck/check_error.c:21:0:
/var/tmp/portage/media-libs/gstreamer-1.6.3/work/gstreamer-1.6.3/libs/gst/check/libcheck/libcompat.h:104:24: note: previous declaration of 'strsignal' was here
 CK_DLL_EXP const char *strsignal (int sig);
                        ^
Makefile:672: recipe for target 'libcheckinternal_la-check_error.lo' failed
make[5]: *** [libcheckinternal_la-check_error.lo] Error 1
make[5]: *** Waiting for unfinished jobs....
In file included from /var/tmp/portage/media-libs/gstreamer-1.6.3/work/gstreamer-1.6.3/libs/gst/check/libcheck/check.c:23:0:
/usr/include/string.h:386:14: error: conflicting types for 'strsignal'
 extern char *strsignal (int __sig) __THROW;
              ^
In file included from /var/tmp/portage/media-libs/gstreamer-1.6.3/work/gstreamer-1.6.3/libs/gst/check/libcheck/check.c:21:0:
/var/tmp/portage/media-libs/gstreamer-1.6.3/work/gstreamer-1.6.3/libs/gst/check/libcheck/libcompat.h:104:24: note: previous declaration of 'strsignal' was here
 CK_DLL_EXP const char *strsignal (int sig);
                        ^


-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

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

[Anthony G. Basile]

On 4/29/16 8:02 PM, waltdnes@waltdnes.org wrote:
>   I'm currently trying to get a 32 uclibc environment working in a QEMU
> VM.  My eventual goal is to get my ancient 32-bit-only Atom netbook
> working under uclibc.  Is it worth bothering to file bugs for stuff that
> builds under glibc, but fails under uclibc?  Or should I forget it?  If
> it's not supported, there's no point in bugging the developers.
> 
>   E.g. gstreamer-1.6.3 builds under glibc, but under uclibc...
> 
> In file included from /var/tmp/portage/media-libs/gstreamer-1.6.3/work/gstreamer-1.6.3/libs/gst/check/libcheck/check_error.c:25:0:
> /usr/include/string.h:386:14: error: conflicting types for 'strsignal'
>  extern char *strsignal (int __sig) __THROW;
>               ^
> In file included from /var/tmp/portage/media-libs/gstreamer-1.6.3/work/gstreamer-1.6.3/libs/gst/check/libcheck/check_error.c:21:0:
> /var/tmp/portage/media-libs/gstreamer-1.6.3/work/gstreamer-1.6.3/libs/gst/check/libcheck/libcompat.h:104:24: note: previous declaration of 'strsignal' was here
>  CK_DLL_EXP const char *strsignal (int sig);
>                         ^
> Makefile:672: recipe for target 'libcheckinternal_la-check_error.lo' failed
> make[5]: *** [libcheckinternal_la-check_error.lo] Error 1
> make[5]: *** Waiting for unfinished jobs....
> In file included from /var/tmp/portage/media-libs/gstreamer-1.6.3/work/gstreamer-1.6.3/libs/gst/check/libcheck/check.c:23:0:
> /usr/include/string.h:386:14: error: conflicting types for 'strsignal'
>  extern char *strsignal (int __sig) __THROW;
>               ^
> In file included from /var/tmp/portage/media-libs/gstreamer-1.6.3/work/gstreamer-1.6.3/libs/gst/check/libcheck/check.c:21:0:
> /var/tmp/portage/media-libs/gstreamer-1.6.3/work/gstreamer-1.6.3/libs/gst/check/libcheck/libcompat.h:104:24: note: previous declaration of 'strsignal' was here
>  CK_DLL_EXP const char *strsignal (int sig);
>                         ^
> 
> 

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



-- 
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

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

[waltdnes]

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.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

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

[Ian Stakenvicius]

[-- Attachment #1.1: Type: text/plain, Size: 820 bytes --]

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.




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

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

[waltdnes]

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.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

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

[Anthony G. Basile]

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.

-- 
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

[gentoo-dev] Uclibc performance

[cbergstrom]

does uclibc handle libm stuff as well like sin/cos?

If so has anyone benchmarked it? ‎I guess same question applies to memcpy and friends who can have a performance impact 

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

[waltdnes]

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.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

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

[Anthony G. Basile]

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

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

[Ian Stakenvicius]

Quote: blueness:
> 
> 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.
> 

What about a "unclibc-ng-migrator" ebuild that would do steps 1,3,4 above if uclibc-ng isn't installed yet, and be a no-op otherwise? This could be a dep of uclibc-ng, and not hard-block uclibc.  A bit hackish but emerge would probably enforce the order of things ok with deptree resolution.

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

[Anthony G. Basile]

On 5/2/16 6:31 PM, Ian Stakenvicius wrote:
> Quote: blueness:
>>
>> 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.
>>
> 
> What about a "unclibc-ng-migrator" ebuild that would do steps 1,3,4 above if uclibc-ng isn't installed yet, and be a no-op otherwise? This could be a dep of uclibc-ng, and not hard-block uclibc.  A bit hackish but emerge would probably enforce the order of things ok with deptree resolution.
> 

yeah, i can see that working, but let me get uclibc-ng going first.

-- 
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

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

[Ian Stakenvicius]

[-- Attachment #1.1: Type: text/plain, Size: 301 bytes --]

On 02/05/16 05:27 PM, waltdnes@waltdnes.org wrote:
>   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.
> 

Is musl a good choice perhaps?  iirc it's support right now is better
than uclibc...


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

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

[Ian Bloss]

[-- Attachment #1: Type: text/plain, Size: 683 bytes --]

I think the deal breaker for some people using uclibc over musl is being
able to choose to include individual components to make it even smaller.
Another possibility why is musl doesn't straight drop in replace all of
glibc's non posix quirks that legacy software depends on could make for
some trouble.

On Tue, May 3, 2016, 10:25 Ian Stakenvicius <axs@gentoo.org> wrote:

> On 02/05/16 05:27 PM, waltdnes@waltdnes.org wrote:
> >   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.
> >
>
> Is musl a good choice perhaps?  iirc it's support right now is better
> than uclibc...
>
>

[-- Attachment #2: Type: text/html, Size: 1031 bytes --]