similar to: RFC: Contributing llvm-libtool (LLVM version of Apple's libtool)

*bitcode_strip* is a utility which is used to manipulate (leave / remove) bitcode segments in a Mach-O file. It is a part of Apple’s cctools and it is also distributed with Xcode. The man page of the tool is available here https://www.manpagez.com/man/1/bitcode_strip/. The functionality of *bitcode_strip* naturally maps onto llvm-objcopy’s model and requires only minimal additions to it.

Hi all, We’re planning to contribute a new implementation of LLD for Mach-O, using the same design as the COFF and ELF ports. This design has proven to work very well for those ports, and we’re keen to explore it for Mach-O as well. Our work is based on an initial prototype created by Peter Collingbourne and Rui Ueyama. Our initial commit is up for review at https://reviews.llvm.org/D75382.

Hey everyone! Recently there has been some progress on LLVM-based tools for manipulating MachO binaries: llvm-objcopy has been gaining a lot of important bits to support MachO (it's relatively close to the point where one can implement the strip-like functionality), llvm-lipo is functional and supports most of cctools' lipo options (https://llvm.org/docs/CommandGuide/llvm-lipo.html). There

On 2020-02-28, James Y Knight via llvm-dev wrote: >Nice! > >Your plan sounds great, and it'll be awesome to finally have a good MachO >LLD available. > >On Fri, Feb 28, 2020 at 4:32 PM Shoaib Meenai via llvm-dev < >llvm-dev at lists.llvm.org> wrote: > >> Hi all, >> >> We’re planning to contribute a new implementation of LLD for Mach-O, using

Hey Michael, I completely agree that setting the rpath properly the first time around is much preferred. But, changes to the binary, particularly during development is much quicker. Prebuilt libraries which are being repackaged is one use case that is missed. In the past, I’ve even used it to repair am incorrectly built library which was missing the library name. There are a few different

Was there any progress in the upstreaming effort? I'd be interested in having lld be able to link against tbd files, and I think it'd be cool if libtool -static could write tbd files (similar to thin archives on linux) since that should make archiving much faster. Juergen, maybe uploading your initial patch to phabricator instead of attaching might get more traction? On Wed, Apr 25, 2018

Great to hear, thanks! On Thu, Sep 20, 2018 at 1:56 PM Jake Ehrlich <jakehehrlich at google.com> wrote: > A member of my team +Armando Montanez <amontanez at google.com> is going to > drop a proposal for the ELF part of this soon (like sometime next week) and > will be working on the implementation. I'll be one of the reviewers for > anything that comes out of that so

Hey everyone! Objcopy is a powerful tool that allows one to modify object files in various manners, for example, modify symbols / symbol tables or copy / remove particular parts of a binary. It also serves as a basis for the strip tool. Currently, llvm-objcopy only supports ELF files while binutils' objcopy can handle Mach-O files as well. Besides extending the existing tool to support Mach-O

That's something I want to do as well for several reasons. That's an orthogonal issue however. On Tue, Oct 2, 2018, 10:21 AM Eric Christopher <echristo at gmail.com> wrote: > I'd give some consideration to moving the objcopy support itself into a > library inside llvm (possibly lib/Object as that makes the most sense) and > then the tool is just a thin wrapper on top

That sounds great to me, thanks Jake. I'm not Jurgen either, of course, but I'm happy to assist you if he is unavailable. I'm not also not qualified to audit the license, but do note Apple formally also released some code at https://opensource.apple.com/tarballs/tapi/. If there's anything else I can do to help, let me know. Cheers, John On 04/10/2018 06:13 PM, Jake Ehrlich

Hi Juergen, At a minimum I think adding the support to libobject, etc so the various llvm tools can read or even write files from/for OSX should be fairly non-controversial so how about go ahead and do that first (I'll happily review if you'd like) and then we can go from there to do anything else with TAPI and llvm? Sound good? -eric On Thu, Sep 7, 2017 at 5:01 PM Juergen Ributzka via

Hi, I can use ar combine two static libs into one lib via libtool. How to do it via libtool? Thanks! Regards Andrew

Hi @ll, Over the past years I have been looking into how to reduce the size of the SDK that ships with Xcode and how to improve build times for the overall OS inside Apple. The result is a tool called TAPI, which is used at Apple for all things related to text-based dynamic library files (.tbd). What are text-based dynamic library files? Text-based dynamic library files (TBDs) are a textual

I'm trying to build an executable for a program I wrote. The compilation steps go well, but the linking step fails with a libtool "version mismatch" error. My linking command has this prefix: /path/to/R/bin/R CMD LINK gcc -g -std=gnu99 ... etc. The error looks like this: libtool: Version mismatch error. This is libtool 2.2, but the libtool: definition of this LT_INIT comes from

I've encountered a new problem building gluster-2.0.1 that I did not have with gluster-2.0.0rc8. This is on a mandriva-2008.1-x86_64 system. ../../libtool: line 466: CDPATH: command not found ../../libtool: line 1144: func_opt_split: command not found libtool: Version mismatch error. This is libtool 2.2.6 Debian-2.2.6a-4, but the libtool: definition of this LT_INIT comes from an older

Hi. I want to add some code to flac and am having trouble building it out of cvs. I've had several problems, most of which were pretty easy to work around or had already been discussed here. But this one has me stumped (though I am admittedly new to autoconf, automake, and libtool). Here's the problem. autoconf does not see any definition for AC_PROG_LIBTOOL. There is such a

Hi, looking on the build scripts, I noticed on configure.ac ## <FIXME> ## Completely disable using libtool for building shlibs until libtool ## fully supports Fortran and C++. ## AC_ARG_WITH([libtool], ## [AS_HELP_STRING([--with-libtool],[use libtool for building shared libraries @ <:@yes@:>@])], ## [use_libtool="${withval}"], ## [use_libtool=yes]) ##

I'm not sure if this is related to me updating to gcc 4.6.0 or not, but in the gnulib/lib directory I get an error which comes down to the following libtool command running: $ ../../libtool --tag=CC --mode=compile gcc -std=gnu99 -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -g -O2 -MT c-ctype.lo -MD -MP -MF .deps/c-ctype.Tpo -c -o c-ctype.lo c-ctype.c ../../libtool: line 2075: c-ctype.c: command not

> Is that the complete output? Yes it is the complete output against "./runtest ./apitest --verbose topercent2"( after running make remove-cached-databases). I attached the snapshot of the output of commands but the size of the email got bigger than 40kb so i had to place the output as text. If I do not run "make remove-cached-databases" and run "./runtest ./apitest

Ok, I managed to compile the Ogg and Vorbis libs. Then, after modifying the file audio_out.c as follows: original: #include <dlfcn.h> modified: #include <win32/include/dlfcn.h> I was able to (finally!) compile libao. Then I tried to compile the module vorbis-tools, but uninvited problems came to my party. [...] > /usr/bin/ld: multiple definitions of symbol _getopt >