search for: libtapi

...:26 PM, Rui Ueyama <ruiu at google.com> wrote: > > Besides the features you pointed out, I think Xcode introduced a new way > of listing dynamic linking symbols, and I believe lld doesn't support that. > .tbd files, is that right? A colleague of mine pointed me to Apple's libtapi open source project [1], maybe I can learn more about these files from that library. In fact, there's been discussion about bringing libtapi to LLVM on the mailing list in the past, although I don't know if anything came of it. [2] I think the real issue is the lack of maintenance and owne...

...hiving much faster. Juergen, maybe uploading your initial patch to phabricator instead of attaching might get more traction? On Wed, Apr 25, 2018 at 8:53 AM Juergen Ributzka via cfe-dev < cfe-dev at lists.llvm.org> wrote: > The code on opensource.apple.com is the minimal code needed for libtapi > to read TBD files with ld64. The code I pushed to GitHub on the other side > includes the full TAPI tool source code. If you check the code you will see > that I already use the LLVM license for everything, because the goal has > always been to contribute this back to the community. &...

...initial patch to phabricator instead of >> attaching might get more traction? >> >> On Wed, Apr 25, 2018 at 8:53 AM Juergen Ributzka via cfe-dev < >> cfe-dev at lists.llvm.org> wrote: >> >>> The code on opensource.apple.com is the minimal code needed for libtapi >>> to read TBD files with ld64. The code I pushed to GitHub on the other side >>> includes the full TAPI tool source code. If you check the code you will see >>> that I already use the LLVM license for everything, because the goal has >>> always been to contribu...

...or 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, o...

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

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

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

...use for their platform, but a rather less generic tool. E.g., symbols starting with "_OBJC_CLASS_$" are recorded in the "objc-classes" field with the prefix removed, instead of just recording it as-is. So, I'd also caution that while the project of "import apple's libtapi into LLVM for LLD/MachO" and "Make a scheme to do interface shared-libs for ELF" might seem superficially related, I'd be very surprised if that actually ended up being the case. I would really not expect it to share just about anything at all other than the concept of being a te...

...his allows a dependency of the library to build concurrently even before the library has been built itself. This can be used to increase parallelism in the build or larger projects or operating systems. Misc: - display and operate on TBD files - automatically generate API tests from header files - libtapi, which is used by the linker (ld64) to parse the TBD files The functionality of the tool is currently limited to Mach-O object files, but that is not a technical limitation. In making the tool open source I hope others will be able to take advantage of it too and extend its functionality to other...

> 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? And, much simpler to support? I assume

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

...ry to build concurrently > even before the library has been built itself. This can be used to increase > parallelism in the build or larger projects or operating systems. > > *Misc:* > - display and operate on TBD files > - automatically generate API tests from header files > - libtapi, which is used by the linker (ld64) to parse the TBD files > > > The functionality of the tool is currently limited to Mach-O object files, > but that is not a technical limitation. In making the tool open source I > hope others will be able to take advantage of it too and extend its...

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

Hello all, I'm trying to better understand the state of Mach-O support in lld. The lld docs state that "the linker supports ELF (Unix), PE/COFF (Windows), Mach-O (macOS) and WebAssembly in descending order of completeness." [1] True to that statement, I found an email on this list from Jan 2018 stating that "MachO support in lld is not really ready for real world usage. It was

...ry to build concurrently > even before the library has been built itself. This can be used to increase > parallelism in the build or larger projects or operating systems. > > *Misc:* > - display and operate on TBD files > - automatically generate API tests from header files > - libtapi, which is used by the linker (ld64) to parse the TBD files > > > The functionality of the tool is currently limited to Mach-O object files, > but that is not a technical limitation. In making the tool open source I > hope others will be able to take advantage of it too and extend its...