Re: [gentoo-dev] News Item for uClibc-ng deprecation

[William Hubbs]

On Tue, Aug 17, 2021 at 02:54:19PM -0400, Anthony G. Basile wrote:
> On 8/17/21 2:24 PM, Aaron Bauman wrote:
> > On Tue, Aug 17, 2021 at 01:27:45PM -0400, Mike Gilbert wrote:
> >> On Tue, Aug 17, 2021 at 7:40 AM Anthony G. Basile  
> >> wrote:
> >>>
> >>> Hi everyone,
> >>>
> >>> Can I get feedback on the following news item?  (BTW, thanks soap)
> >>>
> >>> Title: uClibc-ng retirement on 2023/01/01
> >>> Author: Anthony G. Basile 
> >>> Posted: 2021-08-15
> >>> Revision: 1
> >>> News-Item-Format: 2.0
> >>> Display-If-Profile: default/linux/uclibc/*
> >>>
> >>> uClibc-ng is mostly abandoned upstream, and since my RFC in Jan 2021,
> >>> noone has volunteered to step up maintenance or expressed interest in
> >>> the uClibc-ng profiles. With this announcement we last-rite the "uclibc"
> >>> profiles, which will be removed on 2023/01/01. For parties interested in
> >>> an alternative libc, consider moving to musl, which is supported.
> >>
> >> 2023? That seems like a pretty long time to wait to remove something
> >> that isn't very well supported right now.
> > 
> > +1
> > 
> > While I have no involvement with uClibc-ng, it does seem awfully long
> > before removal.
> > 
> > -Aaron
> > 
> 
> How does 2022-08-01 sound?  That's about 1 year.

Since we know it is broken, a year even seems long.
Also, We can't get rid of the uclibc-based profiles until uclibc is removed.

Thanks,

William

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


signature.asc
Description: PGP signature

Re: [gentoo-dev] News Item for uClibc-ng deprecation

[Anthony G. Basile]

On 8/17/21 2:24 PM, Aaron Bauman wrote:
> On Tue, Aug 17, 2021 at 01:27:45PM -0400, Mike Gilbert wrote:
>> On Tue, Aug 17, 2021 at 7:40 AM Anthony G. Basile  
>> wrote:
>>>
>>> Hi everyone,
>>>
>>> Can I get feedback on the following news item?  (BTW, thanks soap)
>>>
>>> Title: uClibc-ng retirement on 2023/01/01
>>> Author: Anthony G. Basile 
>>> Posted: 2021-08-15
>>> Revision: 1
>>> News-Item-Format: 2.0
>>> Display-If-Profile: default/linux/uclibc/*
>>>
>>> uClibc-ng is mostly abandoned upstream, and since my RFC in Jan 2021,
>>> noone has volunteered to step up maintenance or expressed interest in
>>> the uClibc-ng profiles. With this announcement we last-rite the "uclibc"
>>> profiles, which will be removed on 2023/01/01. For parties interested in
>>> an alternative libc, consider moving to musl, which is supported.
>>
>> 2023? That seems like a pretty long time to wait to remove something
>> that isn't very well supported right now.
> 
> +1
> 
> While I have no involvement with uClibc-ng, it does seem awfully long
> before removal.
> 
> -Aaron
> 

How does 2022-08-01 sound?  That's about 1 year.

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

Re: [gentoo-dev] News Item for uClibc-ng deprecation

[Anthony G. Basile]

On 8/17/21 2:08 PM, Joshua Kinard wrote:
> On 8/17/2021 13:49, Sam James wrote:
>>
>>
>>> On 17 Aug 2021, at 16:19, Joshua Kinard  wrote:
>>> [snip]
>>>
>>> According to the uClibc-ng website, 1.0.38 was released earlier this year
>>> (March 27th).  Was an announcement put out somewhere about the project not
>>> being maintained any further beyond that release, or has it gone quiet after
>>> that?
>>
>> Upstream supporting something doesn't mean that's the case in Gentoo. The
>> last "proper" mention of deprecating uclibc in Gentoo was from blueness
>> in January this year [0].
>>
>> Funnily enough: while digging for the email, I did notice you replied [1] 
>> and couldn't
>> build ncurses, which is pretty apt for illustrating the problems here. That 
>> is, no developers
>> within Gentoo are supporting uclibc, none of us are really surprised when 
>> common/core packages
>> break, and the tracker [2] at least is rotting (as are other uclibc-related 
>> bugs).
>>
>> The gist is, it's not really supported anymore now. This is just about 
>> formally dropping
>> it. I'd be really surprised if anyone is able to use this day-to-day without 
>> a fair amount
>> of patches.
>>
>> In terms of "alt libcs", musl has won that fight. Maybe if somebody wants to 
>> step in future,
>> we can look at uclibc-ng again, but I don't think we've got the resources 
>> right now.
>>
>> [0] 
>> https://archives.gentoo.org/gentoo-dev/message/8b376050c51c7fa9a8a05246feb8c781
>> [1] 
>> https://archives.gentoo.org/gentoo-dev/message/258c08a43961269338e4c9238783f8fe
>> [2] https://bugs.gentoo.org/570544
>>
>>>
>>> I haven't been able to base a MIPS environment on uclibc-ng since 2019 when
>>> Python3 in my stage3's mysteriously all started failing for unexplained
>>> reasons.  Thought about trying to bootstrap a new environment from scratch
>>> at some point, but just haven't gotten around to it.
>>>
>>
>> That sounds like a good reason to dump it too ;)
> 
> The thing is, the breakage I describe is *really* weird.  Unpack my 2019
> uclibc-ng stage3 on a MIPS system, chroot in, everything works fine.  But
> the instant you recompile ncurses inside of it, using the *same* Portage
> snapshot that it was built from, the Python interpreter falls over with a
> NULL deref in its curses module.  I've debugged it down to the exact line of
> C code in Python, but cannot find an explanation why it fails.
> 
> I've had my share of weird crap running these SGI systems, but this one
> takes the cake.  That's why I gave up on uclibc-ng for a time until I could
> try kickstarting a new build from scratch using OpenADK (which still
> supports older pre-mips32/64r* platforms).  No other choice, really, because
> once Python goes down, so too does emerge.
> 
> Even bugged it on Python's bug tracker, but no surprise it's gone ignored:
> https://bugs.python.org/issue39819
> 
> In any event, yeah, I don't have a real issue with dropping it.  I've
> noticed that some of the more recent commits to it are really just ingesting
> chunks of glibc and stripping out some of the macro fluff.  There's actually
> a change in upstream glibc I've yet to test on one of my non-coherent cache
> platforms that uclibc-ng pulled in that probably breaks them in fun fun ways
> (not that that platform ever worked well from the beginning, though...).
> 

Its broken on every arch.  Its time for it to go.  What little time I
have I need to put into musl.

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

Re: [gentoo-dev] News Item for uClibc-ng deprecation

[Aaron Bauman]

On Tue, Aug 17, 2021 at 01:27:45PM -0400, Mike Gilbert wrote:
> On Tue, Aug 17, 2021 at 7:40 AM Anthony G. Basile  wrote:
> >
> > Hi everyone,
> >
> > Can I get feedback on the following news item?  (BTW, thanks soap)
> >
> > Title: uClibc-ng retirement on 2023/01/01
> > Author: Anthony G. Basile 
> > Posted: 2021-08-15
> > Revision: 1
> > News-Item-Format: 2.0
> > Display-If-Profile: default/linux/uclibc/*
> >
> > uClibc-ng is mostly abandoned upstream, and since my RFC in Jan 2021,
> > noone has volunteered to step up maintenance or expressed interest in
> > the uClibc-ng profiles. With this announcement we last-rite the "uclibc"
> > profiles, which will be removed on 2023/01/01. For parties interested in
> > an alternative libc, consider moving to musl, which is supported.
> 
> 2023? That seems like a pretty long time to wait to remove something
> that isn't very well supported right now.

+1

While I have no involvement with uClibc-ng, it does seem awfully long
before removal.

-Aaron


signature.asc
Description: PGP signature

Re: [gentoo-dev] News Item for uClibc-ng deprecation

[Joshua Kinard]

On 8/17/2021 13:49, Sam James wrote:
> 
> 
>> On 17 Aug 2021, at 16:19, Joshua Kinard  wrote:
>> [snip]
>>
>> According to the uClibc-ng website, 1.0.38 was released earlier this year
>> (March 27th).  Was an announcement put out somewhere about the project not
>> being maintained any further beyond that release, or has it gone quiet after
>> that?
> 
> Upstream supporting something doesn't mean that's the case in Gentoo. The
> last "proper" mention of deprecating uclibc in Gentoo was from blueness
> in January this year [0].
> 
> Funnily enough: while digging for the email, I did notice you replied [1] and 
> couldn't
> build ncurses, which is pretty apt for illustrating the problems here. That 
> is, no developers
> within Gentoo are supporting uclibc, none of us are really surprised when 
> common/core packages
> break, and the tracker [2] at least is rotting (as are other uclibc-related 
> bugs).
> 
> The gist is, it's not really supported anymore now. This is just about 
> formally dropping
> it. I'd be really surprised if anyone is able to use this day-to-day without 
> a fair amount
> of patches.
> 
> In terms of "alt libcs", musl has won that fight. Maybe if somebody wants to 
> step in future,
> we can look at uclibc-ng again, but I don't think we've got the resources 
> right now.
> 
> [0] 
> https://archives.gentoo.org/gentoo-dev/message/8b376050c51c7fa9a8a05246feb8c781
> [1] 
> https://archives.gentoo.org/gentoo-dev/message/258c08a43961269338e4c9238783f8fe
> [2] https://bugs.gentoo.org/570544
> 
>>
>> I haven't been able to base a MIPS environment on uclibc-ng since 2019 when
>> Python3 in my stage3's mysteriously all started failing for unexplained
>> reasons.  Thought about trying to bootstrap a new environment from scratch
>> at some point, but just haven't gotten around to it.
>>
> 
> That sounds like a good reason to dump it too ;)

The thing is, the breakage I describe is *really* weird.  Unpack my 2019
uclibc-ng stage3 on a MIPS system, chroot in, everything works fine.  But
the instant you recompile ncurses inside of it, using the *same* Portage
snapshot that it was built from, the Python interpreter falls over with a
NULL deref in its curses module.  I've debugged it down to the exact line of
C code in Python, but cannot find an explanation why it fails.

I've had my share of weird crap running these SGI systems, but this one
takes the cake.  That's why I gave up on uclibc-ng for a time until I could
try kickstarting a new build from scratch using OpenADK (which still
supports older pre-mips32/64r* platforms).  No other choice, really, because
once Python goes down, so too does emerge.

Even bugged it on Python's bug tracker, but no surprise it's gone ignored:
https://bugs.python.org/issue39819

In any event, yeah, I don't have a real issue with dropping it.  I've
noticed that some of the more recent commits to it are really just ingesting
chunks of glibc and stripping out some of the macro fluff.  There's actually
a change in upstream glibc I've yet to test on one of my non-coherent cache
platforms that uclibc-ng pulled in that probably breaks them in fun fun ways
(not that that platform ever worked well from the beginning, though...).

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Re: [gentoo-dev] News Item for uClibc-ng deprecation

[Sam James]

> On 17 Aug 2021, at 16:19, Joshua Kinard  wrote:
> [snip]
> 
> According to the uClibc-ng website, 1.0.38 was released earlier this year
> (March 27th).  Was an announcement put out somewhere about the project not
> being maintained any further beyond that release, or has it gone quiet after
> that?

Upstream supporting something doesn't mean that's the case in Gentoo. The
last "proper" mention of deprecating uclibc in Gentoo was from blueness
in January this year [0].

Funnily enough: while digging for the email, I did notice you replied [1] and 
couldn't
build ncurses, which is pretty apt for illustrating the problems here. That is, 
no developers
within Gentoo are supporting uclibc, none of us are really surprised when 
common/core packages
break, and the tracker [2] at least is rotting (as are other uclibc-related 
bugs).

The gist is, it's not really supported anymore now. This is just about formally 
dropping
it. I'd be really surprised if anyone is able to use this day-to-day without a 
fair amount
of patches.

In terms of "alt libcs", musl has won that fight. Maybe if somebody wants to 
step in future,
we can look at uclibc-ng again, but I don't think we've got the resources right 
now.

[0] 
https://archives.gentoo.org/gentoo-dev/message/8b376050c51c7fa9a8a05246feb8c781
[1] 
https://archives.gentoo.org/gentoo-dev/message/258c08a43961269338e4c9238783f8fe
[2] https://bugs.gentoo.org/570544

> 
> I haven't been able to base a MIPS environment on uclibc-ng since 2019 when
> Python3 in my stage3's mysteriously all started failing for unexplained
> reasons.  Thought about trying to bootstrap a new environment from scratch
> at some point, but just haven't gotten around to it.
> 

That sounds like a good reason to dump it too ;)

best,
sam



signature.asc
Description: Message signed with OpenPGP

Re: [gentoo-dev] News Item for uClibc-ng deprecation

[Mike Gilbert]

On Tue, Aug 17, 2021 at 7:40 AM Anthony G. Basile  wrote:
>
> Hi everyone,
>
> Can I get feedback on the following news item?  (BTW, thanks soap)
>
> Title: uClibc-ng retirement on 2023/01/01
> Author: Anthony G. Basile 
> Posted: 2021-08-15
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Profile: default/linux/uclibc/*
>
> uClibc-ng is mostly abandoned upstream, and since my RFC in Jan 2021,
> noone has volunteered to step up maintenance or expressed interest in
> the uClibc-ng profiles. With this announcement we last-rite the "uclibc"
> profiles, which will be removed on 2023/01/01. For parties interested in
> an alternative libc, consider moving to musl, which is supported.

2023? That seems like a pretty long time to wait to remove something
that isn't very well supported right now.

Re: [gentoo-dev] News Item for uClibc-ng deprecation

[Joshua Kinard]

On 8/17/2021 07:40, Anthony G. Basile wrote:
> Hi everyone,
> 
> Can I get feedback on the following news item?  (BTW, thanks soap)
> 
> Title: uClibc-ng retirement on 2023/01/01
> Author: Anthony G. Basile 
> Posted: 2021-08-15
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Profile: default/linux/uclibc/*
> 
> uClibc-ng is mostly abandoned upstream, and since my RFC in Jan 2021,
> noone has volunteered to step up maintenance or expressed interest in
> the uClibc-ng profiles. With this announcement we last-rite the "uclibc"
> profiles, which will be removed on 2023/01/01. For parties interested in
> an alternative libc, consider moving to musl, which is supported.
> 
> Gentoo continues to wholeheartedly support musl and is focusing its
> efforts in that area.
> 
> Resources:
> - https://wiki.gentoo.org/wiki/Project:Hardened_musl
> - https://gitweb.gentoo.org/proj/musl.git/ (overlay for patches)
> - #gentoo-hardened (IRC channel on irc.libera.chat) for support and
> discussion

According to the uClibc-ng website, 1.0.38 was released earlier this year
(March 27th).  Was an announcement put out somewhere about the project not
being maintained any further beyond that release, or has it gone quiet after
that?

I haven't been able to base a MIPS environment on uclibc-ng since 2019 when
Python3 in my stage3's mysteriously all started failing for unexplained
reasons.  Thought about trying to bootstrap a new environment from scratch
at some point, but just haven't gotten around to it.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Re: [gentoo-dev] News Item for uClibc-ng deprecation

[Alexey Sokolov]

17.08.2021 12:40, Anthony G. Basile пишет:
> Hi everyone,
> 
> Can I get feedback on the following news item?  (BTW, thanks soap)
> 
> Title: uClibc-ng retirement on 2023/01/01
> Author: Anthony G. Basile 
> Posted: 2021-08-15
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Profile: default/linux/uclibc/*
> 
> uClibc-ng is mostly abandoned upstream, and since my RFC in Jan 2021,
> noone has volunteered to step up maintenance or expressed interest in
> the uClibc-ng profiles. With this announcement we last-rite the "uclibc"
> profiles, which will be removed on 2023/01/01. For parties interested in

2023-01-01 please.

> an alternative libc, consider moving to musl, which is supported.
> 
> Gentoo continues to wholeheartedly support musl and is focusing its
> efforts in that area.
> 
> Resources:
> - https://wiki.gentoo.org/wiki/Project:Hardened_musl
> - https://gitweb.gentoo.org/proj/musl.git/ (overlay for patches)
> - #gentoo-hardened (IRC channel on irc.libera.chat) for support and
> discussion
> 
> 


-- 
Best regards,
Alexey "DarthGandalf" Sokolov

[gentoo-dev] News Item for uClibc-ng deprecation

[Anthony G. Basile]

Hi everyone,

Can I get feedback on the following news item?  (BTW, thanks soap)

Title: uClibc-ng retirement on 2023/01/01
Author: Anthony G. Basile 
Posted: 2021-08-15
Revision: 1
News-Item-Format: 2.0
Display-If-Profile: default/linux/uclibc/*

uClibc-ng is mostly abandoned upstream, and since my RFC in Jan 2021,
noone has volunteered to step up maintenance or expressed interest in
the uClibc-ng profiles. With this announcement we last-rite the "uclibc"
profiles, which will be removed on 2023/01/01. For parties interested in
an alternative libc, consider moving to musl, which is supported.

Gentoo continues to wholeheartedly support musl and is focusing its
efforts in that area.

Resources:
- https://wiki.gentoo.org/wiki/Project:Hardened_musl
- https://gitweb.gentoo.org/proj/musl.git/ (overlay for patches)
- #gentoo-hardened (IRC channel on irc.libera.chat) for support and
discussion


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

Re: [gentoo-dev] News item for uclibc-ng

[Alexis Ballier]

On Wed, 8 Feb 2017 14:37:52 -0500
"Anthony G. Basile"  wrote:

> This will make sure all executables link directly against libc.so.0
> (as reported by `readelf -d`) rather than via sym links like
> libdl.so.0 -> libc.so.0.  Then upgrade from 1.0.19 to 1.0.20 without
> symlink-combat:
  ^^

I'd love to see a symlink fight ! :)

Re: [gentoo-dev] News item for uclibc-ng

[Jason Zaman]

On Wed, Feb 08, 2017 at 02:37:52PM -0500, Anthony G. Basile wrote:
> 0. Because of changes in the library structure in previous versions,
> make sure you are working with 1.0.19 and rebuild world using
> 
> emerge -evq @world
--verbose --quiet? just emerge -e @world is probably better.
> 
> 7. For good measure, rebuild the entire system
> 
> emerge —evq @world
Another non-ascii

I havent tested, but this appears what you want:
grep --color='auto' -P -n "[\x80-\xFF]" filename

from here: http://stackoverflow.com/a/9395552

-- Jason

Re: [gentoo-dev] News item for uclibc-ng

[Gokturk Yuksek]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

Anthony G. Basile:
> Hi everyone,
> 
> Attached you'll find a news item for uclibc-ng.  I'd like to push
> it out in a few days.
> 

>> This will make sure all executables link directly against
>> libc.so.0 (as
should be "all **the** executables"

>> reported by `readelf -d`) rather than via sym links like
>> libdl.so.0 ->
sym links -> symlinks

>> libc.so.0.  Then upgrade from 1.0.19 to 1.0.20 without
>> symlink-combat:
symlink-combat -> symlink-compat

>> 1. Get rid of the obstack.h header since its used by configure
>> scripts
its -> it's

>> 6. Finally updated uclibc-ng to the latest
updated -> update

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJYm88FAAoJEIT4AuXAiM4z85EIAKCBZdivRA/kliIcj5rCFsJC
pRKy7IhNgG8K+zHktV90QbEIXVdOpnZLMx315NEz0vGnPR7Ik/fZqMF8Jwgty26O
OHbb2sYEU6KqS3q/Qwa1/OH+ysfX0Jp2rHIPp2X7gSFPQ4AQyQz5od35b24+whsJ
dRn9M64lo18+PvAD2L5dz9tG2noazkddWN6rugOMQzQbGO/Rk+Z5M3Zq6zJKBVHO
gZCsreQWsqmgHDxX7TzMdqzY0Pt5M5ausvmc689vskYSCt9edhOfYTi2dP+AqLch
4OB5fWcPZe5yGFOeAtLgg0ymBMxSbv8a1Zf5tKwyXsJSE6hJuKgUb/K6gCm1N0Q=
=lVV1
-END PGP SIGNATURE-

Re: [gentoo-dev] News item for uclibc-ng

[Anthony G. Basile]

On 2/8/17 3:23 PM, Andrey Utkin wrote:
> On Wed, Feb 08, 2017 at 02:37:52PM -0500, Anthony G. Basile wrote:
>> Hi everyone,
>>
>> Attached you'll find a news item for uclibc-ng.  I'd like to push it out
>> in a few days.
>>
> 
>> This will make sure all executables link directly against libc.so.0 (as
>> reported by `readelf -d`) rather than via sym links like libdl.so.0 ->
>> libc.so.0.  Then upgrade from 1.0.19 to 1.0.20 without symlink-combat:
>>
>> USE=“-symlink-compat" emerge =sys-libs/uclibc-ng-1.0.20
> 
> First quote sign is non-ascii so command doesn't work when copy-pasted
> to terminal.
> 

Thanks, I wrote this on my mac which does things like that.  Is there a
good utility for catching non-ascii chars?

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

Re: [gentoo-dev] News item for uclibc-ng

[Andrey Utkin]

On Wed, Feb 08, 2017 at 02:37:52PM -0500, Anthony G. Basile wrote:
> Hi everyone,
> 
> Attached you'll find a news item for uclibc-ng.  I'd like to push it out
> in a few days.
> 

> This will make sure all executables link directly against libc.so.0 (as
> reported by `readelf -d`) rather than via sym links like libdl.so.0 ->
> libc.so.0.  Then upgrade from 1.0.19 to 1.0.20 without symlink-combat:
> 
> USE=“-symlink-compat" emerge =sys-libs/uclibc-ng-1.0.20

First quote sign is non-ascii so command doesn't work when copy-pasted
to terminal.

[gentoo-dev] News item for uclibc-ng

[Anthony G. Basile]

Hi everyone,

Attached you'll find a news item for uclibc-ng.  I'd like to push it out
in a few days.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA
Title: Upgrade to =sys-libs/uclibc-ng-1.0.22
Author: Anthony G. Basile 
Content-Type: text/plain
Posted: 2017-02-10
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: sys-libs/uclibc-ng
Display-If-Profile: default/linux/uclibc/amd64
Display-If-Profile: hardened/linux/uclibc/amd64
Display-If-Profile: default/linux/uclibc/arm/armv7a
Display-If-Profile: hardened/linux/uclibc/arm/armv7a
Display-If-Profile: default/linux/uclibc/mips
Display-If-Profile: hardened/linux/uclibc/mips
Display-If-Profile: default/linux/uclibc/mips/mipsel
Display-If-Profile: hardened/linux/uclibc/mips/mipsel
Display-If-Profile: default/linux/uclibc/ppc
Display-If-Profile: hardened/linux/uclibc/ppc
Display-If-Profile: default/linux/uclibc/x86
Display-If-Profile: hardened/linux/uclibc/x86

There have been two major changes in uclibc-ng which need special
attention when upgrading. Version 1.0.19 restructured the breakout
libraries, libcrypt.so.0, libdl.so.0, and friends.  The functions in
those libraries are now included in libuClibc-0.1.0.19.so.  Version
1.0.21 and above removed libc support for obstack, expecting packages to
use their bundled GNU lib code. Both changes require special upgrade
procedures which we outline below: 

0. Because of changes in the library structure in previous versions,
make sure you are working with 1.0.19 and rebuild world using

emerge -evq @world

This will make sure all executables link directly against libc.so.0 (as
reported by `readelf -d`) rather than via sym links like libdl.so.0 ->
libc.so.0.  Then upgrade from 1.0.19 to 1.0.20 without symlink-combat:

USE=“-symlink-compat" emerge =sys-libs/uclibc-ng-1.0.20

1. Get rid of the obstack.h header since its used by configure scripts
to look for function prototypes and macros.

mv /usr/include/obstack.h ~

2. We also need to force the use of any bundled gnu lib code.  We can do
this by removing the definition of _GNU_OBSTACK_INTERFACE_VERSION from
gnu-version.h

cp /usr/include/gnu-versions.h ~
sed -i -e '/#define _GNU_OBSTACK/d' /usr/include/gnu-versions.h

3. We need to tell stdio.h that __UCLIBC_HAS_OBSTACK__ is false.  We do
this via the uClibc_config.h file.

cp /usr/include/bits/uClibc_config.h ~
sed -i -e '/__UCLIBC_HAS_OBSTACK__/ s/1/0/' \
 /usr/include/bits/uClibc_config.h

4. To be safe, you may want to back up your entire /lib directory so
you can fall back should something go wrong:

cp -a /lib /lib.bak

5. Now when we rebuild @world, all packages will use their bundled
obstack code rather than depending on libc to provide it.

ac_cv_func_obstack_vprintf=no emerge --keep-going --exclude \
 sys-libs/uclibc-ng -evq @world

6. Finally updated uclibc-ng to the latest

emerge =sys-libs/uclibc-ng-1.0.22

7. For good measure, rebuild the entire system

emerge —evq @world