similar to: [lld] Well lld support some advanced features like gnu linker in macOS?

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

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

Does LLVM 8 work in macOS 10.9.5? -- Mark

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

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:

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

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

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

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

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

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

Always show info like ''operation not supported''. Any workaround? Thanks. Fred -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20110316/2f58e589/attachment.html>

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

On Sat, Oct 14, 2017 at 10:25 AM, Don Hinton <hintonda at gmail.com> wrote: > Hi Jack: > > Looks like I missed this one in my recent change. > > Please let me know if this solves your problem: > > $ git diff > diff --git a/utils/TableGen/InfoByHwMode.cpp > b/utils/TableGen/InfoByHwMode.cpp > index 7e1e1864356..8d3636432aa 100644 > ---

Is anyone else seeing this bootstrap failure on current svn trunk? [ 6%] Linking CXX executable ../../bin/llvm-tblgen cd /sw/src/fink.build/llvm60-6.0.0-1/build/stage1/utils/TableGen && /sw/bin/cmake -E cmake_link_script CMakeFiles/llvm-tblgen.dir/link.txt --verbose=1 /sw/src/fink.build/llvm60-6.0.0-1/opt-bin/ccclang++ -fno-common -fPIC -fvisibility-inlines-hidden -Werror=date-time

Following a blend of instructions on 3 web pages, I have succeeded in getting LLVM 3.2 (with clang, extras, and compiler-rt) building - but not testing - on Xcode. I used CMake 2.8.10 GUI to create the Xcode project file. Below are my notes. First, I believe CMake ends up setting things up so that Xcode has 1 warning after scanning the project having to do with hires images or some such… it takes

On Sat, Oct 14, 2017 at 11:25 AM, Don Hinton <hintonda at gmail.com> wrote: > Hi Jack: > > Yes, I was just looking at that. Seems like TableGen wasn't done along > with the rest of llvm. I'll work up a complete patch shortly. > > Btw, I'm curious how this happened. Do you have a stale CMakeCache.txt by > any chance? You might check the value for

On Sat, Oct 14, 2017 at 11:25 AM, Don Hinton via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi Jack: > > Yes, I was just looking at that. Seems like TableGen wasn't done along with > the rest of llvm. I'll work up a complete patch shortly. This also broke the build for MSVC when doing a debug build (though no builder seems to be picking up the failure!). After