search for: lto_librari

Dear LLVM community I need some help please. I want to use LLVM's clang and lld within a MacOSX sandboxed app. This is because sandboxing does not allow calls to /usr/bin/clang. The clang binary works fine to compile a file, but ld64.lld comes up with the error "cannot find framework". However similar arguments using /usr/bin/ld instead of ld64.lld works fine. Here are the

Hi. I'm using LLVM 5.0.1 on macOS 10.12. I have a very simple program (program.c): int main() {} When attempting to compile with LLD, I get this output: $ clang -fuse-ld=lld program.c /opt/llvm/5.0.1/bin/ld.lld: error: unknown argument: -no_deduplicate /opt/llvm/5.0.1/bin/ld.lld: error: unknown argument: -dynamic /opt/llvm/5.0.1/bin/ld.lld: error: unknown argument: -arch

AFAIK, ld does not use DYLD_LIBRARY_PATH to lookup libLTO.dylib but contains a reference to @executable_path/../lib/libLTO.dylib. The only way I managed to load a different LTO library than the default one is to create a symlink pointing to the actual ld binary (as returned by 'xcrun -find ld') and making sure the library I want to load is placed at ../lib/libLTO.dylib relatively to this

For dogfooding the compiler I normally use is a LTO bootstrap of clang. On linux that is simple to do that since clang passes the correct plugin to the linker. On OS X ld64 uses libLTO.so it finds via DYLD_LIBRARY_PATH. Should clang set that before running the linker? Is there a better way for clang to tell the linker which libLTO.so to use? Cheers, Rafael

I believe what's happening here is that clang translates the -fuse-ld=lld into calling the ld.lld executable, which is actually the ELF LLD linker, not the Mach-O one. On 6.0, the Mach-O linker symlink is called ld64.lld instead (and clang has been changed to call out to that name) to disambiguate the two. For 5.0, I'm not sure how best to force the Mach-O linker (I'm not familiar with

Hi, llvm developers. I can't find a lld-dev mail list, so just mail to here. ld in macOS is legacy, lld a more modern linker. I have test, `-fuse-ld=lld, -Wl,--as-needed `, but its output is: /usr/local/bin/ld.lld: error: unknown argument: -dynamic /usr/local/bin/ld.lld: error: unknown argument: -arch /usr/local/bin/ld.lld: error: unknown argument: -search_paths_first

Looks like your static library is not even pulled into the link command so the static library is not even in the snapshot. From the link command in the snapshot, the static library is not on the command line from snapshot: /Applications/Xcode-11.3.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld -Z -demangle -object_path_lto

Hi Tobias The problem is that your static archive has a SYMDEF that is empty, so linker thinks the static library provided doesn't contain any symbol. The reason for that is you are using the `ranlib` from Xcode, which is too old to understand the new bitcode object files produced by llvm 10. There are lots of ways to fix that: * The standard way to create static library on macOS is to use

We do it by setting DYLD_LIBRARY_PATH. That overrides the normal @executable_path lookup. On Nov 12, 2013, at 10:09 AM, Jean-Daniel Dupas <devlists at shadowlab.org> wrote: > AFAIK, ld does not use DYLD_LIBRARY_PATH to lookup libLTO.dylib but contains a reference to @executable_path/../lib/libLTO.dylib. > > The only way I managed to load a different LTO library than the default

I'm seeing something similar. clang is using HOST_LINK_VERSION, obtained from ld64, as the default for -mlinker-version. This causes Darwin.cpp to add the arguments you are seeing, but not handled by lld. Perhaps -fuse-ld should be considered in addition to -mlinker-version when adding these arguments. As a workaround, you can try passing -mlinker-version. Looks like anything < 133

MachO support in lld is not really ready for real world usage. It was able to bootstrap itself a couple of years ago, but, it has not really been maintained or further developed since. I would recommend that you use ld64 if you are intending to build MachO binaries. > On Jan 7, 2018, at 9:57 AM, Don Hinton via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I'm seeing

Thanks for your reply. Two questions: 1). Will ld64.lld be fixed in LLVM v11.0 and when is this likely to be? 2). You mention Apple’s linker, by which I assume you mean GNU’s ld. Is it possible to get a binary version of ld (preferably that does not use other things from /usr/bin)? Thanks > On 7 May 2020, at 12:26, James Y Knight <jyknight at google.com> wrote: > > The MachO

This is usually a problem that is not using llvm-ar. I cannot reproduce this problem with either llvm 10.0 or TOT version. Which linker version are you using? You can also try pass "-Wl,-debug_snapshot" to the command where the error produces and then locate the "*.ld-snapshot" in /tmp directory and attach that as a reproducer. Steven > On Jul 22, 2020, at 8:41 AM, Teresa

Dear all, I am not sure whether this is a right place to ask basic questions about usage of CLang/LLVM, but also not sure if there is any other mailing list for such. Kindly point me to such a list in such case. I had built mainline CLang/LLVM on OSX and tried to use it with CMake. I had override following variables in CMake:

Does LLVM 8 work in macOS 10.9.5? -- Mark

W dniu 2019-04-04 o 09:18, Tim Northover pisze: > On Wed, 3 Apr 2019 at 19:05, Audiovisart via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Does LLVM 8 work in macOS 10.9.5? > It should do. The released binaries appear to have been compiled so > they can run on that version, and Apple Clang 6.0 (from the newest > Xcode that runs on 10.9) meets the build