GCC driver-driver [was: Re: standard way to require c++11?]
Landon J Fuller
landonf at macports.org
Wed Oct 14 09:40:21 PDT 2015
On Apr 22, 2015, at 12:23 PM, Mihai Moldovan <ionic at macports.org> wrote:
>
>> 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 universal.
[snip]
>
> 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]
Sorry, I just now saw this e-mail.
I wrote an independent MIT-licensed implementation of the ‘driver-driver’ for FatELF:
https://github.com/landonf/haiku-buildtools/blob/fatelf/fatelf/utils/fatelf-gcc.c
Some minor work would be required to extricate it from the fatelf-utils code so that it can stand alone, and to replace the ‘fatelf_glue_cmd’ with lipo(1), but all the difficult bits related to GCC argument handling, etc, are done.
-landonf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20151014/31c134cc/attachment.html>
More information about the macports-dev
mailing list