On Apr 22, 2015, at 12:23 PM, Mihai Moldovan <[email protected]> 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_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
