Hi Rob, Rob Landley wrote, > On 12/21/2016 12:18 AM, Waldemar Brodkorb wrote: > > Hi Rob, > > Rob Landley wrote, > > >>> I am wondering why you don't cc me or any uclibc related list? > >> > >> I cc'd the buildroot list, which only has uClibc-based cortex-m support > >> at the moment. Why do you suppose I did that? > > > > That is not completely true, OpenADK has support for it, too. > > Buildroot has cortex-m support based on OpenADK as well as its cortex-m > support based on uClibc?
Yes, that is true. We found some problems with Linuxthreads and could fix it upstream in elf2flt. Buildroot has furthermore good support for STM32F29 devices. The Qemu-ARM noMMU default config was contributed by me. OpenADK tries to support Kinetis K70 from Emcraft, but it seems my compiler is to recent to compile their old 2.6.33 kernel correctly. > Now I'm trying to turn Android into a self-hosting development > environment ... I dislike the hardware and closed source drivers. It is sad that OpenMoko didn't evolved. People like me working on old crappy C libraries, supporting crappy architectures and devices still own such phones. > Before either of those I spent half the 1990's trying to make OS/2 > happen (because windows was terrible technology and basing the internet > on it meant not just a virus utopia but probably the kind of surveilance > state Edward Snowden eventually showed us we actually got.) My time on > OS/2 was a learning experience, and figuring out it was over and I > needed to move on to Linux in 1998 was an important lesson. I prefer to > spend my public development time on things that have at least the > possibility of a future. I started playing with Linux in nearly the same year. I think SuSE Linux 5.2 was my first playground. > Maybe similarly persisting with uClibc will work out for you, I just > don't see how. (I have no idea what you're trying to accomplish. What > niche it has these days that musl, bionic, and (e)glibc _don't_ have.) You will see, probably. > You're accusing me of choosing not to spend my free time on uClibc > anymore. I don't understand why this is some sort of accusation. There > are 7 billion people on this planet ignoring you. My being among them is > not an attack on your project. I pushed uClibc for 10 years (again, as a > hobbyist). I stopped when Rich posted his libc archive somewhere public > I could test and contribute to, which offered a better use of my time. Yeah, but the 7 billion people don't blog or post bad propaganda about uClibc-ng. But even bad talk about uClibc makes it alive ;) > You're aware that half the point of my > http://landley.net/aboriginal/about.html project was regression testing > each new release under qemu to see what broke, right? Yes, I am aware of it. > Been there, done that. Doing other things now. The point is I am aware > how much work proper regression testing is. I also believe there's no > substitute for actual real-world use, and users other than the > developers who will find stuff the developers never will. The cortex-m > bug says to me that uClibc, on cortex-m, hasn't actually got serious > users or you'd have noticed the problem yourself years ago. I hope to get the Emcraft developers involved in uClibc-ng development and make things better in the future. We will see. > > Thanks for the history walkthrough. Do you know why Bernhard is so > > unresponsive and more about the time shortly after his last release? > > Do you mean you asked him questions he didn't respond to? Yes. I even got a respond from Erik in the same mail, saying that Bernhard is the maintainer. > (Although Rich went with elf-based fdpic instead of a.out-based binflt, > which means for cortex-m on musl we've got to get the > http://www.slideshare.net/linaroorg/sfo15406-arm-fdpic-toolset-kernel-libraries-for-cortexm-cortexr-mmuless-cores > stuff upstream.) I am looking forward to see this and as usual I will test new ports of musl. http://tests.embedded-test.org/musl/ > > - architectures not supported by any other C library like arc, > > xtensa, nds32, h8300, .. > > - vintage unix hardware like SGI O2, Sparcstations, ... > > > > See my table which architectures are not supported by musl/glibc: > > http://uclibc-ng.org/wiki/matrix > > Good to know. > > I've had a todo item to get a coldfire target running under qemu so Rich > can do musl support in it. It's been on my todo list for... 2 years now? > Too much else to do... You can just use buildroot to generate a working environment, I contributed a defconfig for it. > > But even then uClibc-ng is always a good choice for regression > > testing and testing between the different C libraries. > > Good luck with it. Thanks. > I am not interested in subscribing to your list just now, thanks. That is fine for me. Waldemar _______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
