[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140721145040.GQ17402@brightrain.aerifal.cx>
Date: Mon, 21 Jul 2014 10:50:40 -0400
From: Rich Felker <dalias@...c.org>
To: Weldon Goree <weldon@...gurwallah.org>
Cc: musl@...ts.openwall.com
Subject: Re: Packaging: Slackware
On Mon, Jul 21, 2014 at 08:12:58PM +0530, Weldon Goree wrote:
> On 07/21/2014 07:45 PM, Rich Felker wrote:
> >
> > Yes. I'm still not clear though on whether the intent is to provide an
> > environment for musl-[dynamic-]linked programs running on Slackware,
> > or more for a development environment using the musl-gcc wrapper. This
> > might affect the stability requirements. Of course if it's just a
> > development environment using the wrapper, there may not be a lot of
> > point in packaging that since you already need a compiler to use it,
>
> The intent is to provide a build script that builds a musl environment
> that one could then use to build other build scripts in the repository
> (James B's description was good). I'm trying to get some anecdata on
> what the people who mentioned being interested in a musl build script
> want (cross toolchain vs. gcc wrapper with some environment setup vs.
> just the library itself).
>
> The point of making a build script in the trivial case is that it
> integrates it (in a predictable way) with slackware's package
> management/file finding system ("where did I put the cross-x86 version's
> files again?", etc.).
This sounds good. Given the prevalence of C++ these days (which I'm
rather unhappy about), musl-gcc has limited usefulness; for example
it's hard to even compile a cross-compiler with it, since gcc 4.8+ are
written in C++. So I would lean towards providing a native musl-based
compiler using the patches from musl-cross (these fix some header
issues, default dynamic linker path, libstdc++ build, etc. for working
with musl).
One remaining open item on the wiki is making musl-gcc work with C++
(i.e. sufficient compatibility to use the host libstdc++). I think the
problem here is either that gcc adapts its C++ headers to the host
libc, or just that it's using precompiled headers which pulled in part
of the libc headers. If someone could debug this and find a
workaround, we might be able to revitalize musl-gcc as a serious
development option (and it would make bootstrapping a lot easier).
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.
