From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10824 Path: news.gmane.org!.POSTED!not-for-mail From: Waldemar Brodkorb Newsgroups: gmane.comp.lib.uclibc.buildroot,gmane.linux.lib.musl.general Subject: Re: [musl] Re: [musl] cortex-m support? Date: Wed, 21 Dec 2016 07:18:54 +0100 Message-ID: <20161221061853.GB2915@waldemar-brodkorb.de> References: <04e5a294-719e-8029-704f-a57d1ec935b0@landley.net> <20161208211116.GO1555@brightrain.aerifal.cx> <7bfe2625-725d-d1bb-7177-f2d31ce09e9c@landley.net> <20161215185123.GX15584@waldemar-brodkorb.de> <48fb6c09-9dcb-e563-dc2d-f30062c5fceb@landley.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1482301413 23825 195.159.176.226 (21 Dec 2016 06:23:33 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 21 Dec 2016 06:23:33 +0000 (UTC) User-Agent: Mutt/1.5.23 (2014-03-12) Cc: buildroot-+q+6gMgSsvIBXFe83j6qeQ@public.gmane.org To: musl-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8@public.gmane.org Original-X-From: buildroot-bounces-9GAsQqxh4YTR7s880joybQ@public.gmane.org Wed Dec 21 07:23:28 2016 Return-path: Envelope-to: gclub-buildroot@m.gmane.org Original-Received: from smtp4.osuosl.org ([140.211.166.137] helo=fraxinus.osuosl.org) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cJaJC-0005Os-UJ for gclub-buildroot@m.gmane.org; Wed, 21 Dec 2016 07:23:27 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id E03C185343; Wed, 21 Dec 2016 06:23:30 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Original-Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TTXD-xesZwy; Wed, 21 Dec 2016 06:23:28 +0000 (UTC) Original-Received: from ash.osuosl.org (ash.osuosl.org [140.211.166.34]) by fraxinus.osuosl.org (Postfix) with ESMTP id 861D5853F9; Wed, 21 Dec 2016 06:23:28 +0000 (UTC) Original-Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by ash.osuosl.org (Postfix) with ESMTP id 2A1A31C073B for ; Wed, 21 Dec 2016 06:23:28 +0000 (UTC) Original-Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 2775B83585 for ; Wed, 21 Dec 2016 06:23:28 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Original-Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUalLhWJMrQ0 for ; Wed, 21 Dec 2016 06:23:26 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Original-Received: from helium.openadk.org (helium.openadk.org [89.238.66.15]) by whitealder.osuosl.org (Postfix) with ESMTPS id 4C10183528 for ; Wed, 21 Dec 2016 06:23:26 +0000 (UTC) Original-Received: by helium.openadk.org (Postfix, from userid 1000) id 51F8B10124; Wed, 21 Dec 2016 07:18:54 +0100 (CET) Content-Disposition: inline In-Reply-To: <48fb6c09-9dcb-e563-dc2d-f30062c5fceb-VoJi6FS/r0vR7s880joybQ@public.gmane.org> X-Operating-System: Linux 3.16.0-4-amd64 x86_64 X-BeenThere: buildroot-9GAsQqxh4YTR7s880joybQ@public.gmane.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion and development of buildroot List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: buildroot-bounces-9GAsQqxh4YTR7s880joybQ@public.gmane.org Original-Sender: "buildroot" Xref: news.gmane.org gmane.comp.lib.uclibc.buildroot:167614 gmane.linux.lib.musl.general:10824 Archived-At: 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. But I am not sure you declare OpenADK a real project. It seems to me that in your definition of a open source project, the people behind must either get money for their work or the project needs millions of installations. > Did you want me to send it to the uclibc.org mailing list which hasn't > had a single post this month except your announcement of your fork's > release? No, I would like to see your suggestions and patches on the uClibc-ng mailing list: http://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel/ > Has your fork solved the locales problem? > > http://lists.busybox.net/pipermail/uclibc/2015-June/049000.html I don't support the binary locale package. I am not very interested in locale support. > Has your fork solved the nptl issue? > > http://lists.busybox.net/pipermail/uclibc/2008-September/020151.html > http://lists.busybox.net/pipermail/uclibc/2008-September/020169.html > http://lists.busybox.net/pipermail/uclibc/2008-September/020171.html > http://lists.busybox.net/pipermail/uclibc/2008-October/041201.html Not sure. But in uClibc-ng there is Linuxthreads support for every supported architecture (excluding METAG) and NPTL for the global players. I added NPTL support from GNU libc recently, but Microblaze seems indeed bitrotted inside GNU libc as nobody is doing any test suite runs. https://sourceware.org/ml/libc-alpha/2016-07/msg00640.html There is even missing DWARF2 support in GCC upstream, so I think it is even not compile time tested. > http://lists.busybox.net/pipermail/uclibc/2006-March/014811.html > > Do you have a sane "make defconfig" that lets people build uClibc > without learning what over a hundred individual config options do and > making decisions about whether or not they need each one? This issue > doesn't even come _up_ with musl, it fundamentally avoids most of the > structural problems that strangled uClibc development, by design. I regulary cleanup needless options and keep good defaults. The number of options get lower. I still like the idea of being able to build a complete toolchain without thread support or other stuff disabled. I will try to remove more options in the future. > > You still believe uClibc projects should die? > > No, I believe uClibc _already_ died. I believe this because I was there. Yes, uClibc is dead. uClibc-ng is alive! > But cortex-m still only supports pthreads in 2016 and even that's buggy > in ways that were fixed out of tree quite a while ago. The release I > fished this bugfix out of is a year old. I don't have their source > control to see how old the fix really is, but emcraft's "preferred" > kernel (https://github.com/emcraftsystems/linux-emcraft) forked off from > mainline 7 years ago, and cortex-m support for Linux is their core > business, so there's a guess how long ago somebody actually _using_ this > might have noticed it. So, may be you can prepare a patch for the uClibc-ng list? Or do you want to see the bug open for another year? > In case you really _don't_ know the history, let me walk you through how > the uClibc project died, going back through about ten years of > accumulated scar tissue, and why three different maintainers before you > failed to fix it. Thanks for the history walkthrough. Do you know why Bernhard is so unresponsive and more about the time shortly after his last release? > You came into a project I'd pushed for 10 years and started collecting > trivial bugfixes without addressing any of the serious architectural > issues (like needlessly duplicated per-architecture headers snapshot > from ancient glibc versions, with a #define pretending to be glibc (musl > doesn't) and declaring all sorts of stuff the library doesn't actually > implement). And you're wondering why I have a more pessimistic outlook > of your chances than you do? You have to start somewhere, otherwise nothing happens. > The big elephant in the development room was the NPTL code, and cortex-m > is still using pthreads, not nptl, and WITHIN that pthreads mess is _old > and _new versions of thread wait for supporting 2.2 kernels. (The > menuconfig option has been replaced with _old and _new suffixes on the > functions. Great.) Linuxthreads.new is gone. uClibc-ng only support Linuxthreads and NPTL. > You've said that your reason for supporting uclibc-ng was for two > architectures, ARC and Xtensa: > > http://www.openwall.com/lists/musl/2015/05/30/1 > That is why _you_ care. I personally think that adding support for those > to musl-libc would be a far better use of your time, but it's not my job > to tell you want to do. It's your hobby time. Do what you like with it. > Just don't expect me to take you seriously after ten years of this. That is not entirely right. I care for every supported uClibc-ng architecture. uClibc-ng might be used for different use cases: - old non mainstream architectures like lm32, avr32, cris, fr-v, .. - noMMU systems like arm, coldfire, bfin, c6x, .. - 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 Indeed Max has started a musl implementaton for Xtensa: https://github.com/jcmvbkbc/musl-xtensa The Synopsys people trying to add support for GNU libc. But even then uClibc-ng is always a good choice for regression testing and testing between the different C libraries. > I cc'd buildroot. That is a real project, which still uses uClibc for > the targets Rich hasn't gotten around to porting musl to yet. I cc'd > them so they would be aware of the issue. I could have just sent it to > the musl list, but chose to inform buildroot as well. Other real projects use uClibc-ng, too. So may be next time you sent it to our list directly ;) best regards Waldemar