Segmentation fault in __uClibc_main on m68k

Rob Landley rob at
Sat May 30 06:09:37 UTC 2015

On Fri, May 29, 2015 at 1:00 PM, Jaromír Cápík <tavvva at> wrote:
> "On 29 May 2015 at 17:54, Jaromír Cápík <tavvva at> 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 or based on the
last-ever uClibc release from 2012 plus a pile of patches in

That said, I've given up on uclibc development and am following 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

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 ?
Well instead what happened was
which became
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

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


More information about the uClibc mailing list