similar to: Combining install-distribution with binary stripping

I discovered that I can hack around my particular problem by placing set_property(TARGET clang PROPERTY INTERFACE_LINK_LIBRARIES) at the end of tools/driver/CMakeLists.txt. I'd prefer to fix this properly though, of course. On 12/1/17, 4:18 PM, "llvm-dev on behalf of Shoaib Meenai via llvm-dev" <llvm-dev-bounces at lists.llvm.org on behalf of llvm-dev at lists.llvm.org>

Adding Juergen to the thread. On Fri, Mar 15, 2019, 12:20 PM Shoaib Meenai via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Ping. > > > > Would anyone be opposed to me trying to revive the in-tree Mach-O TAPI > code? > > > > Thanks, > > Shoaib > > > > *From: *Shoaib Meenai <smeenai at fb.com> > *Date: *Wednesday, March 6, 2019 at

Actually, sorry, my fix was for the case where you had other arguments beginning with @ that weren't response files, whereas yours has actual response files, so my patch won't help there. CCing Reid and Hans, who did a bunch of the implementation in this area. From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Shoaib Meenai via llvm-dev <llvm-dev at

Hi all, It looks like Juergen landed the TextAPI libraries for Mach-O in https://reviews.llvm.org/D53945, and also had several follow-ups, but then it was deleted entirely by r347874. I'm not sure if the entire deletion was intentional, since the commit message only mentions reverting a certain series of patches; CC Hans. In any case, I'm wondering if there are plans to revive it, since

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.

I’m happy to run them, although I’d appreciate a pointer to the appropriate documentation. From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Tobias Hieta via llvm-dev <llvm-dev at lists.llvm.org> Reply-To: Tobias Hieta <tobias at plexapp.com> Date: Wednesday, September 30, 2020 at 11:15 AM To: Hans Wennborg <hans at chromium.org> Cc: llvm-dev <llvm-dev at

https://reviews.llvm.org/rL353906 introduced (presumably accidentally) the "b" top-level directory to the monorepo. The files should be moved to their proper location, but I'm also wondering if there's any way to prevent accidental top-level additions like this. Thanks, Shoaib -------------- next part -------------- An HTML attachment was scrubbed... URL:

I'm an idiot and sent to llvm-commits instead of llvm-dev. Fixing. On 10/17/17, 5:09 PM, "llvm-commits on behalf of Shoaib Meenai via llvm-commits" <llvm-commits-bounces at lists.llvm.org on behalf of llvm-commits at lists.llvm.org> wrote: Hi all (CC beanz for cmake advice), I'm running into a cmake problem when I try to cross-compile a

I looked into this further. ld64 has a macho_nlist abstraction over the various underlying nlist structures [1]. On x86-64, the P::getP referenced in n_value will resolve to [2], which in turn goes to [3], which calls OSReadLittleInt64. On a little endian machine, OSReadLittleEndian just calls _OSReadInt64 [4], which in turn does a pointer arithmetic and cast and then dereferences the pointer [5].

Judging by this path: needed by 'tools/lld/Common/VCSVersion.inc' It looks to me like this is **not** a monorepo layout (if it were, lld would not appear in the tools directory). Therefore the LLVM_ENABLE_PROJECTS=lld is not even doing anything. I don't know how to build without a monorepo these days, and I also don't know what the most recent guidance setting up a monorepo is,

I have made some further investigation. My conclusion is that GNU ld does not do better than lld. Making the --defsym behavior ideal is difficult in the current framework. GNU ld has some unintended behaviors. ld.bfd a.o --defsym 'd=foo' --gc-sections -o a => GNU ld retains .text_foo ld.bfd a.o --defsym 'd=foo+3' --gc-sections -o a => GNU ld drops .text_foo ld.bfd a.o

Hi Sjoerd, On Fri, May 3, 2019 at 8:19 AM Sjoerd Meijer via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > I read that out-of-order cores are supported. How about in-order cores? > Would it be easy/difficult to add support for that? > > Cheers, > Sjoerd. > > I don't think that it would be difficult to support in-order superscalar cores. However, it would

Hey Chris, Sedat was asking for a way to "to speedup my build" and those blog posts were really helpful to me. Anyway LLVM_DISTRIBUTION_COMPONENTS sounds very cool, hope you will push your code soon! On Tue, Mar 1, 2016 at 11:32 PM, Chris Bieneman <cbieneman at apple.com> wrote: > Fabio, the work I was mentioning here is an extension beyond those blog > posts. > >

Hi, I recently hit this on a project using a build system that relies heavily on nested response files. We found we could only have 21 response files total before getting errors related to the unexpanded response files. I tracked it down to this code in llvm/lib/Support/CommandLine.cpp // If we have too many response files, leave some unexpanded. This avoids // crashing on

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

> On Mar 2, 2016, at 4:22 PM, Sedat Dilek <sedat.dilek at gmail.com> wrote: > > I got some more inspirations on how to speedup my build and integrated > the URLs into my scripts (attached). > > For example to use GOLD as linker or to use '-O3' OptLevel maybe in > combination with LTO and PGO (using '-O3 -flto -fprofile-use'). LTO *will* slow down

Hi all (CC llvm-rc contributors), I've been attempting to cross-compile LLVM for Windows using clang-cl. LLVM's build system embeds resource files for MSVC builds, so I was hoping to use llvm-rc for that portion. cmake invokes the resource compiler with arguments joined to their options (e.g. `/D_WIN32`, `/fofoo.res`, etc.), which rc.exe supports, but llvm-rc expects arguments to be

I was looking at the SymbolTable code in LLD COFF and ELF recently, and I’m confused by the use of CachedHashStringRef. From what I understand, a CachedHashStringRef combines a StringRef with a computed hash. There’s no caching going on in the CachedHashStringRef itself; that is, if you construct CachedHashStringRef("foo"), and then construct a second

Now that we’re on the Git monorepo, is there an updated script for cherry-picking commits into the release branch? llvm/utils/release/merge.sh appears to still use SVN, and llvm/utils/release/merge-git.sh uses git-svn. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200116/5c791bd2/attachment.html>

If you want to use your key to authenticate, you need to set your remote URL to the SSH one: git remote set-url --push origin git at github.com:llvm/llvm-project.git You can get the SSH URL by going to https://github.com/llvm/llvm-project/ and clicking on Clone or download to get the appropriate URL ... it should give you the option to Clone with SSH. I've not had a ton of luck with HTTPS