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

[John Ericson via cfe-dev]

 > 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.

 > On 04/09/2018 06:39 PM, Greg Parker via cfe-dev wrote:

 >> On Apr 9, 2018, at 3:23 PM, James Y Knight via cfe-dev 
<cfe-dev at lists.llvm.org> wrote:

 >> I'm not really clear on the actual benefits of the TBD file, and why 
Apple migrated to them in the first place. Shouldn't a dynamic library 
containing only the relevant parts (e.g. the dynamic symbol table) be 
roughly comparable in size?...

 > File size is one reason...

For the record, other small benefits are

  - The inclusion of the path to the actual library, which as far as I 
know is not something that can be done with a stub library. This allows 
easy absolute or relative (with R(UN)PATH) linking. Comparatively, 
passing the right -rpath and -rpath link is manual and (in my opinion) 
harder to understand and cumbersome, and also not a solution for 
absolute linking. I work with Nixpkgs of NixOS, where absolute path 
linking is frequently an objective as part of a general principle of 
avoiding indirection.

  - YAML. The option for line-oriented structure allows for easy diffing 
with conventional line-based diffing tools, which is useful for 
debugging compatability issues. (e.g. Why did my new version remove 
symbols? Why did my security update change anything at all?). Of course 
one can just objdump and diff, but that wouldn't happen automatically 
with version control, for example.

John