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