[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 2 Jul 2018 12:50:43 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: future of compiler wrappers
On Mon, Jul 02, 2018 at 10:00:11AM -0600, Assaf Gordon wrote:
> Hello,
>
> On 02/07/18 09:28 AM, Markus Wichmann wrote:
> >On Sun, Jul 01, 2018 at 08:11:50PM -0400, Rich Felker wrote:
> >>[...] I expressed a sentiment that the compiler wrapper scripts tend to
> >>reflect badly on musl, and that I'd really rather not keep maintaining
> >>them but pass maintainership of them off to someone else as a separate
> >>project for users who still want to use them. [...]
> >
> >By all means, nuke them. Cross-compilers are the way to go in OS
> >development, as well, and pretty much for the same reason: You want to
> >insulate your compilate from the host environment. So yes, in the words
> >of William Shatner: Let them die!
>
> A slightly different POV, as someone who is not very familiar with
> the nitty-gritty of cross-compliation setup:
>
> The current setup of having "musl-gcc" with a simple "make install"
> is invaluable for testing various programs for portability,
> i.e. it is a clean and easy way to build programs against a
> different libc, even if the host is using glibc.
> As a secondary bonus, it also allows building static binaries very easily.
>
> Now that is of course the simple case, and I'm only using it on x86-64,
> but I'm using it alot. I don't know how mips/ppcs and/or
> cross-compliation complicate things (I understand that they do...).
>
> If musl-gcc is gone, I'd guess the next best (easiest) thing is
> running alpine linux in docker / VM and build locally there?
> Still not very complicated, but seems like an order of magnitude
> more demanding than having "musl-gcc".
>
> There is ELLCC, but it's been almost a year since the last release -
> is it being actively maintained? even if so, it requires a heavy
> compilation phase to setup everything.
>
>
> If "musl-gcc" s relegated to an external package/repository
> but is still easy to install - great. But if it is completely
> removed or abandoned, it would be missed... by me at least.
>
>
> I'm sadly not an expert enough on compilers or cross-compliations
> to maintain it, but I can help with automated testing and bug reporting
> if it becomes a separate package.
I don't want it abandoned. That's why I'm asking and trying to gauge
if there's interest in maintaining it separately. I agree that it
meets some people's needs well enough and it's convenient, but I feel
like having it as something you fetch/install separately would be
better ux/presentation in many ways, in that it wouldn't suggest it's
the "right" way to use musl and would ensure that users are aware
they're using something that has limited functionality, rather than
thinking they're hitting problems with musl.
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.
