future of compiler wrappers

future of compiler wrappers

[Rich Felker]

It came up again today on #musl that gratuitous use of musl-gcc was
breaking something (this time, ppc and mips toolchains that were
already musl-targeting but where the musl-gcc specs broke things), and
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. Would anyone be
particularly upset to see them go from the main musl repo/releases,
and is anyone interested in maintaining them out-of-tree separately
from musl?

Rich

Re: future of compiler wrappers

[Markus Wichmann]

On Sun, Jul 01, 2018 at 08:11:50PM -0400, Rich Felker wrote:
> It came up again today on #musl that gratuitous use of musl-gcc was
> breaking something (this time, ppc and mips toolchains that were
> already musl-targeting but where the musl-gcc specs broke things), and
> 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. Would anyone be
> particularly upset to see them go from the main musl repo/releases,
> and is anyone interested in maintaining them out-of-tree separately
> from musl?
> 
> Rich

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!

Ciao,
Markus

Re: future of compiler wrappers

[Assaf Gordon]

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.

regards,
  - gordon

Re: future of compiler wrappers

[Rich Felker]

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

Re: future of compiler wrappers

[Jens Gustedt]

[-- Attachment #1: Type: text/plain, Size: 1960 bytes --]

Hello Rich,

On Mon, 2 Jul 2018 12:50:43 -0400 Rich Felker <dalias@libc.org> wrote:

> 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.

I use musl in teaching, because it is the only variant of the C
library where I can have full standard conformance for atomics and
threads. The university system on which the students are working is
something that I have not much control of, and forcing it to allways
have the latest .dep package of musl installed was quite a challenge.

So anything that changed that situation, would make this even more
fragile. Generally, I think that are a lot of people out there that
don't completely control their developement environment. I would be
nice if withdrawing musl-gcc from musl could wait until the
replacement is a well-established package in the major distributions.

On the other hand I agree that it would probably be a good idea to
have a compiler wrapper package that is independent of musl and that
allows to combine more or less any compiler with any of the C
libraries. It is just annoying that the compiler frontends don't have
easy to use options for this in the first place.

Thanks
Jens

-- 
:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]