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

[Jeremy Huddleston Sequoia]

> On Apr 22, 2015, at 11:23, Mihai Moldovan <ionic at macports.org> wrote:
> 
> 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.

That's not how it works.

1) It wouldn't be backporting because it's not going backwards ;)

2) Copyright and license are different issues.  It doesn't matter that Apple holds the copyright.

3) The driver-driver is GPLv2+ (look at driverdriver.c in the apple-gcc42 port), so it's perfectly usable with gcc5.

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

You cannot copyright ideas.  That is what patents are for.

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

I don't really care about gcc, and I doubt many other at Apple do either.  We've moved on to clang years ago and don't give gcc much thought.

> Does anyone here have:
>  - a clear understanding of the legal matter?

I am not a lawyer, so I cannot give advise, but I am confident enough in my own understanding to act.

>  - experience with writing robust code and maybe even a little bit of knowledge of GCC's internals (likely helpful)?

yes

>  - enough time to backport/implement this?

No, but it should be fairly straight forward, especially if you only care about supporting i386/x86_64 since that only requires the single intel CTARGET gcc.  If you want to support ppc, that will be more problematic because you'll need to build a ppc gcc and an intel gcc.  Look at how hacky the build_gcc script is in the apple-gcc42 port.

>  - confidence a backport will be accepted by the GCC project?

It isn't something FSF is interested in.  They haven't cared for the past 10 years, so I doubt they'd start caring now.  It also doesn't really fit the gcc model.

> 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.
> 
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4109 bytes
Desc: not available
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20150422/63139616/attachment-0001.p7s>