Segmentation fault in __uClibc_main on m68k

[Waldemar Brodkorb]

Hi,
Rob Landley wrote,

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

We'll see. In the FPGA world there are four main architectures, 
NIOS2, ARC, Microblaze and Xtensa. Nios2 and Microblaze are
supported by GNU libc. ARC and Xtensa are only supported by
uClibc/uClibc-ng. There are nice developers and company's behind.

For all the no-MMU architectures or systems there is only one option
at the moment. uClibc/uClibc-ng!

I am maintaining an developing buildsystems for embedded devices
since more than 10 years, I don't think I will give up on uClibc-ng
so fast.
 
> 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.

That is not correct. They did not silently migrate to musl.
Musl is a choice like Gnu Libc in their buildsystem.

They will migrate in the next release cycle, but they migrate to
uClibc-ng as default C library for their system.

This will get a better code coverage, than my own embedded-test
project, which at the moment only running the uClibc-ng testsuite
regulary. 

But may be Rob comes up with nommu.org contents with a musl 
libc for at least sh2 nommu, soon.

<advertisement on>
Best choice for exotic architectures and hardware is OpenADK + uCLibc-ng ;)
<advertisement off>

best regards and happy hacking,
 Waldemar