Re: roadmap for 0.9.8 ?

[Rich Felker <dalias@aerifal.cx>]

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