GCC driver-driver [was: Re: standard way to require c++11?]

[Mihai Moldovan]

On 22.04.2015 07:39 PM, Jeremy Huddleston Sequoia wrote:> 
>> On Apr 22, 2015, at 10:30, Lawrence Velázquez <larryv at macports.org> wrote:
>>
>> On Apr 21, 2015, at 5:14 AM, Jeremy Huddleston Sequoia <jeremyhu at apple.com> wrote:
>>
>>> On Apr 20, 2015, at 23:51, Mihai Moldovan <ionic at macports.org> wrote:
>>>>[...]
>>>> For specific ports, yes. In general, muniversal might take of that. But it doesn't make a lot of sense to change our ports base to muniversal, if we can salvage the current state by using clang. Which implies libc++. Gotcha.
>>>
>>> What does muniversal have to do with anything?
>>
>> I think Mihai is thinking about using the portgroup's automatic lipo(1)-ing as a hacky substitute for a proper GCC driver-driver.

Yep, thanks Larry.


> Ah, clever.  I see what you mean, but yeah, that would require more extensive use of muniversal which is more of a hack in my mind than a proper solution. =/

You're right. The proper solution would be to add the old driver-driver back to FSF GCC and get it upstreamed, instead of relying even more on muniversal.

Personally, I do not wish to do so, for multiple reasons.

First, a compiler is a somewhat delicate matter and I do not think I've got experience to "get it right". I don't want to completely break (or break in subtle ways) FSF GCC on OS X.

Next, there's this copyright-license issue. While only taking driver-driver from GCC 4.2 and backporting it to at least the newest GCC 5 version might technically not be too difficult (although it probably requires re-implementation in C++?), Apple would still be the original copyright holder on that code and as such can decide under what license to release it. Given they don't want to do that on a GPL-3 basis, only a complete rewrite (for whatever that means *exactly*) would give a contributor the right to claim copyright and determine the license.

Even in a "complete rewrite" case, I'd be concerned with legal problems because the general concept of a GCC driver-driver was their idea. Given that we'd want the new driver-driver to behave like the 4.2 one, there inadvertently will be similarities.

On the other hand, maybe Apple doesn't care and would indeed be happy to see GCC a little bit better supported on their platform. This is pure speculation.

Does anyone here have:
  - a clear understanding of the legal matter?
  - experience with writing robust code and maybe even a little bit of knowledge of GCC's internals (likely helpful)?
  - enough time to backport/implement this?
  - confidence a backport will be accepted by the GCC project?

It's not required to meet all points. Even one would be good enough. This can be a team effort if needed. The GCC Strike Force![0]

On OS X, having driver-driver again with -arch support would certainly be a very welcome improvement to FSF GCC.[1]



Mihai

[0] joke on https://wiki.debian.org/XStrikeForce (which itself it not a joke but a great thing for Debian.)
[1] This would only be useful for MacPorts on recent OS X releases if -stdlib=libc++ would make GCC not link to its own libstdc++ at all. I don't know if that's the case.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20150422/609bc62d/attachment.sig>