On 22.04.2015 07:39 PM, Jeremy Huddleston Sequoia wrote:> >> On Apr 22, 2015, at 10:30, Lawrence Velázquez <[email protected]> wrote: >> >> On Apr 21, 2015, at 5:14 AM, Jeremy Huddleston Sequoia <[email protected]> >> wrote: >> >>> On Apr 20, 2015, at 23:51, Mihai Moldovan <[email protected]> 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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
