From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2267 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: roadmap for 0.9.8 ? Date: Fri, 9 Nov 2012 13:51:20 -0500 Message-ID: <20121109185120.GA20323@brightrain.aerifal.cx> References: <5091B637.3060107@barfooze.de> <20121101000518.GG20323@brightrain.aerifal.cx> <20121108222452.GX20323@brightrain.aerifal.cx> <509D230F.5090404@barfooze.de> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1352487092 17987 80.91.229.3 (9 Nov 2012 18:51:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 9 Nov 2012 18:51:32 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2268-gllmg-musl=m.gmane.org@lists.openwall.com Fri Nov 09 19:51:42 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1TWtg6-00067P-CA for gllmg-musl@plane.gmane.org; Fri, 09 Nov 2012 19:51:42 +0100 Original-Received: (qmail 30159 invoked by uid 550); 9 Nov 2012 18:51:33 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 30145 invoked from network); 9 Nov 2012 18:51:32 -0000 Content-Disposition: inline In-Reply-To: <509D230F.5090404@barfooze.de> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2267 Archived-At: On Fri, Nov 09, 2012 at 04:36:47PM +0100, John Spencer wrote: > On 11/08/2012 11:24 PM, Rich Felker wrote: > >- explicit mips soft-float abi support (mainly for use with broken > >>> openwrt kernels) , > >>Mainly this requires a discussion of whether it should go in the build > >>system (sub-archs/abis) or just at the source level somewhere. > >Still on the table for discussion. > > i don't have an opinion on this, however: > for path names that are using $ARCH, such as the ld-musl files, it > would be nice if for example mips and mipsel had different filenames > (for multi-lib installations). > same applies for armv4tl vs armv7l, etc mips and mipsel are *different* archs/abis, so I agree it would make sense for the dynamic linker to be named differently on mipsel. However, armv4t and armv7 are the same arch. If the hardware is little endian and supports armv7 ISA, there's no reason the same dynamic linker can't be used both for apps built at armv7-native and older armv4-compatible binaries. There's no reason the name of the dynamic linker needs to indicate that the library is using v7-specific features, because the ABI for linking to the library is the same either way. Of course, armeb and arm should be separate archs, for naming purposes, just like mips and mipsel. > >>>additionally, i think it'd make sense to add stubs for the missing > >>>optional schedule functions (as most of them are already there), > >>>that way we could build some exotic programs like "fluidsynth" > >>>without patches, and further increase the pkgsrc success rate: > >>Hopefully we can just add real versions of them. A good half of the > >This is also on my agenda at high priority (pardon the pun). > will it make it into the next release ? > i think, for the moment, having it as stubs would perfectly suffice. Yes, I think so. Like I said before, adding stubs and making sure their behavior is conforming is almost as much work as making operational versions of these functions. > i guess the ppc port can be postponed. My inclination would be to postpone it, but if there are any volunteers to help, we could perhaps include it as an experimental port. > >>One thing that comes to mind is updating the wiki and keeping it > >>relevant. Most of the FAQ items are obsolete now. > >Volunteers? > i cleaned up the obsolete stuff. Thanks. > >>An internal task I want to work on is removing most/all of the > >>#include directives from stdio_impl.h. I think this would improve > >Done. Also did pthread_impl.h. Much cleaner now. > nice, i especially like the memset removal in leaf-functions. > which could lead to what we discussed on IRC a while ago (object > files that are identical for PIC and non-PIC should only be built > once) The biggest problem here is that I don't know any way to detect if a file would be different with -fPIC without actually compiling it to see (which would take just as long). > >>I know you want some fixes/improvements in configure. > >Done. > thanks Does it meet your needs? > > Please let me know if there > >are other issues that should be addressed before release. > everything that came to mind is fixed by now. Great. Rich