> On Apr 22, 2015, at 11:23, Mihai Moldovan <[email protected]> wrote: > > 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.
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 > [email protected] > https://lists.macosforge.org/mailman/listinfo/macports-dev
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
