[llvm-dev] [cfe-dev] [RFC] Open sourcing and contributing TAPI back to the LLVM community

[Andrew Kelley via llvm-dev]

On Mon, Apr 9, 2018 at 10:11 PM, John Ericson via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> > Regardless of any of that, given that TBD files _are_ an integral part
> of the apple platform, supporting them is certainly a necessity in order to
> have a working apple linker. So, if making LLD work for Apple/MachO is the
> justification for adding TBD support to LLVM, that seems self-evidently a
> reasonable thing to do. On the other hand, it looks like the LLD mach-o
> code is unmaintained and nobody seems to be much interested in it. And
> having code for reading TBD files in LLVM seems not terribly interesting,
> unless it is as part of a project to make the LLD MachO linker actually
> functional and supported.
>
> Yes. I hope this can be reason enough. Hobbyists could push for LLD
> support for Mach-O besides Apple, and if LLD is to displace other linkers
> this is a necessary component as you say. Better to upstream now before the
> code diverges than more work later? Conversely if nothing happens, I doubt
> libtapi would be a greater drag on the codebase than the MachO LLD code, so
> whatever cost/benefit analysis exists for keeping that around could also
> apply to this.



Speaking for the Zig project here, our goal is to support cross-compilation
for any target, on any target, without requiring installation of any
target-specific SDK. So, for example, these use cases:
 * on linux, compile & link a binary targeting macos
 * on windows, compile & link a binary targeting macos

This works today, although it depends on a patch to LLD to fix the MACH-O
linker that is not high enough quality to upstream.

So we have a vested interest in improving the MACH-O linker, and in fact a
Zig community member has fixed at least one bug in MACH-O LLD:
reviews.llvm.org/D35387

I don't fully understand how TBD or TAPI works, but I hope that it results
in improvements to the MACH-O linker.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180410/8d503873/attachment.html>