On Fri, May 29, 2015 at 1:00 PM, Jaromír Cápík <[email protected]> wrote: > > "On 29 May 2015 at 17:54, Jaromír Cápík <[email protected]> wrote: > >> You mentioned a distro you boottrapped a couple of weeks >> ago. Do you have a working rootfs environment I could >> test? > > I did not submit the m68k patch to OE yet since i meant to get gmp > going first, no. > " > > > > I found a complete uclibc environment in the uclibc > > downloads. It's called system-image-m68k.tar.bz2 > > and it's based on version 0.9.30.
That sounds like my aboriginal linux output. There should be newer ones at http://landley.net/aboriginal/downloads/binaries/ or http://landley.net/aboriginal/downloads/old/binaries/ based on the last-ever uClibc release from 2012 plus a pile of patches in http://landley.net/hg/aboriginal/file/tip/sources/patches That said, I've given up on uclibc development and am following musl-libc.org these days. At this point, I wouldn't care if uclinux _did_ have a new release. The 3+ year gap since the last release is AFTER I SENT TWO CAKES to get this unblocked last decade. I created a buildroot list and evicted the other project's traffic off this one. I appointed a new maintainer more or less by fiat. None of it helped, and I'm through playing sisyphos. The problem is _chronic_ and apparently unsolvable, which means this project is essentially already dead. It just hasn't noticed because it's _that_dead_. Remember how eglibc was created in response to the vacuum uClibc left. The reason eglibc went away is that vacuum got filled. Between musl and a slowly improving bionic sucking your developers away, I expect the number of people bothering the uClibc developers for a new release has dropped considerably. That's because the number of people who would care about a new uClibc release even if it happened at this point has dropped considerably, because they've moved on. Of course somebody did a uclibc-ng fork (bought the domain name and everything), but I talked to him and his reason for doing it is there are some obscure targets even glibc doesn't support, and I expect that as musl grows support for those targets his reasons for doing it will gradually fade away. *shrug* We'll see. Remember when buildroot announced they would switch their default libc if the uClibc developers couldn't get a new release out? Remember how that was over a year ago, ala http://lists.busybox.net/pipermail/uclibc/2014-February/048252.html ? Well instead what happened was http://lists.busybox.net/pipermail/buildroot/2013-October/079661.html became http://git.buildroot.net/buildroot/commit/?id=c29799330464fb5d152f1b3d550fcbda69c58a3d which became https://www.phoronix.com/scan.php?page=news_item&px=Musl-Libc-GCC-Support and at this point it's pretty much over except the cleanup. They didn't _announce_ a migration, they just did it. At this point if uClibc had a new release I expect they'd smile and nod and _continue_ not to care because there are better alternatives now, once that haven't established a pattern of chronic multi-year development constipation. The only reason I haven't switched aboriginal over yet (added support to build musl but didn't make it the default) is I'm busy with other things. The current blocker is I need to update my linux from scratch 6.8 native build, which is my big smoketest for each aboriginal linux release when I update the kernel and toybox and such. several packages in there have big #ifdef/else staircases with lists of known build environments and end with #error or doing something really stupid if they can't recognize your libc. Yes, even if nothing's wrong, they break just because they don't recognize the _name_ of the build environment. Mostly FSF crap. The way uclibc dealt with that was by lying and claiming to be glibc. Musl pushes fix patches upstream into the other packages instead, but that involves upgrading to package versions that have the fix or applying the fix yourself, and I've needed to upgrade my LFS build version anyway, so... Anyway, good luck with your m68k port.( I've poked the musl maintainer about adding that but he hasn't got a test environment and Laurent Vivier's qemu-q800 fork _still_ isn't merged. I should follow up and poke on that again, but my todo list runneth over...) Rob _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
