[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121116071135.GO20323@brightrain.aerifal.cx>
Date: Fri, 16 Nov 2012 02:11:35 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Remaining agenda for 0.9.8
On Thu, Nov 15, 2012 at 10:59:12PM -0800, Isaac Dunham wrote:
> On Wed, 14 Nov 2012 20:55:00 -0500
> Rich Felker <dalias@...ifal.cx> wrote:
>
> > PowerPC port issues:
> > - adding dynamic linking support
> > - resolving which definition of long double we'll use/support
> > - checking for remaining omissions/bugs/etc.
> >
> > Improving app compat:
> > - integrating sys/mtio.h
> Everything it provides is implemented at the kernel level, so you
> can just drop it into include/sys/
Yes, I just wanted to clean up the inconsistent spacing and stuff..
> > - integrating sys/io.h port io stuff
> > - exposing sigreturn stuff needed by libunwind (?)
> >
> > In addition, there are a few things still pending that probably won't
> > make it into this release cycle, but I'd like to keep them in mind
> > anyway:
> >
> > - priority inheritance mutexes
> > - named subarch support (armeb, arm-hardfloat, mips-softfloat, etc.)
> It may be best to do this via -D/#ifdef, for situations where you need multiple sets of oddities.
> I'm thinking of (mipsel-softfloat):
> SUBARCH_CFLAGS=-D__SOFTFLOAT=1
> SUBARCH=el-softfloat #ld.so = ld-musl-${ARCH}${SUBARCH}.so.1
Yeah I was thinking of something like that. Maybe even
ld-musl-$(ARCH)$(ENDIAN)$(ABIVARIANT).so.1 or similar. The things to
think about are how the source tree needs to look to make whatever
option is chosen work. For example, endianness should normally not
affect which files get compiled (endian-agnostic code is pretty much
always the right way to go), but the ABI variant might affect which
asm gets used (e.g. setjmp asm that saves or skips saving floating
point registers, or real vs no-op versions of fenv stuff). Or we could
just say the same asm is going to get used either way, and arrange for
there to exist some global symbols describing the variant, which the
asm could read at runtime.
> > - math_errhandling for archs without fenv
> > - major documentation improvement
> In tree or out-of-tree?
That's a good question. I've gotten some requests for in-tree. The
pros of in-tree are that you can keep it versioned with the code, and
that everything's all in one place, and it looks more "professional"
in releases to have the docs present. The cons are that it makes the
repo and releases a good bit larger, and looks bad in releases if
parts of the docs are outdated at the time of release (if they're
separate, new docs releases can be made separately from new code
releases).
> > Anything I missed, or additional requests? I'm hoping to get a release
> > out pretty quickly since the last release cycle was rather long, and
> > this one doesn't have any invasive changes in it that would need heavy
> > testing before release.
> For releases that do need more testing, what would you think of rc
> tarballs? While git can be built with only libc as a dependency*
> (NO_PYTHON=1 NO_PERL=1 MSGFMT=true... if I remember right), "pull
> from git" does still limit your audience.
The old gitweb had a "download tarball" link. I don't think cgit has
that (for which my server is thankful). RC's are one idea, but I
wonder if daily snapshots might be just as good.
> *Either I missed some variable for the installation, or you will
> also need to install gettext(-tiny) if you don't install with make
> -i install, because it counts on *.po existing.
I think there's some disable option for it.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
