Re: [gentoo-dev] RFC: migration from uclibc to uclibc-ng

[Mike Gilbert]

On Sat, Jul 16, 2016 at 8:07 PM,   wrote:
>   I don't know if this is on topic.  Is it possible to backport 64-bit
> date/time to uclibc-ng in 32-bit mode?  32-bit date runs between late
> 1901 and early 2038.  2038 is not that far away.  E.g. in a 32-bit VM...

This seems pretty off-topic for this thread.

I think the kernel would need to support 64-bit time interfaces in the
x86 ABI before any libc could use them.

Re: [gentoo-dev] RFC: migration from uclibc to uclibc-ng

[waltdnes]

On Sat, Jul 16, 2016 at 01:02:42PM -0400, Anthony G. Basile wrote

> I welcome comment on any of the above.

  I don't know if this is on topic.  Is it possible to backport 64-bit
date/time to uclibc-ng in 32-bit mode?  32-bit date runs between late
1901 and early 2038.  2038 is not that far away.  E.g. in a 32-bit VM...

[g32gst1][waltdnes][~] date --date='@-2147483649'
date: invalid date '@-2147483649'
[g32gst1][waltdnes][~] date --date='@-2147483648'
Fri Dec 13 15:45:52 EST 1901
[g32gst1][waltdnes][~] date --date='@2147483647'
Mon Jan 18 22:14:07 EST 2038
[g32gst1][waltdnes][~] date --date='@2147483648'
date: invalid date '@2147483648'

  64-bit date covers beyond the heat death of the universe each way...

[i3][waltdnes][~] date --date='@-2147483649'
Fri Dec 13 15:45:51 EST 1901
[i3][waltdnes][~] date --date='@-2147483648'
Fri Dec 13 15:45:52 EST 1901
[i3][waltdnes][~] date --date='@2147483647'
Mon Jan 18 22:14:07 EST 2038
[i3][waltdnes][~] date --date='@2147483648'
Mon Jan 18 22:14:08 EST 2038

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

[gentoo-dev] RFC: migration from uclibc to uclibc-ng

[Anthony G. Basile]

Hi everyone,

Most of you know that uclibc upstream is pretty much dead.  There hasn't
been a official release since 2012 and there hasn't been a commit to
their master branch for over a year.  The situation has become
impossible since important fixes really can't be backported without
layers of intermediated fixes being backported first.  This has lead to
a fork at http://uclibc-ng.org/ which is actively maintained and has all
of the fixes we need in the latest release.

Since I don't want to just give up on Gentoo + uclibc, I'm going to
migrate to uclibc-ng.  (Parenthetically let me add that I think the real
future of embedded will be musl, but still I don't want to just give up
on uclibc.)

After migrating, I will pretty much abandon uclibc itself and continue
exclusively with uclibc-ng.  The supported arches are and will continue
to be amd64, armv7a (hard/soft float), mips32r2 (big endian), mipsel3
(little endian), ppc and i686.  The process will be as follows:

1. Build experimental stage3's with customize /etc/portage.  This is
just for testing since the final stage3's should not have anything in
/etc/portage.  This must be completed for all arches before the next step.

2. Migrate the customized /etc/portage to profiles/default/linux/uclibc
for all arches, and switch the priority in virtual/libc/libc-0.ebuild.
Currently it reads:

elibc_uclibc? ( || ( sys-libs/uclibc sys-libs/uclibc-ng ) )


3. Update https://wiki.gentoo.org/wiki/Project:Hardened_uClibc with
instructions on how to upgrade.

4. Start pushing out uclibc-ng base stages
https://www.gentoo.org/downloads/ for amd64 and i686.

I'm at step 1 for amd64 and i686.

I welcome comment on any of the above.

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