similar to: [LLVMdev] bugpoint (and possibly others) need to be compiled with -rdynamic

Attached is a patch that fixes it for the cmake build. I'm not positive this is the right place to put it and I really have no idea where the check should go when using the autotools. -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm-rdynamic.patch Type: application/octet-stream Size: 663 bytes Desc: not available URL:

Hi, I noticed that the following regression tests fail when building a config generated with CMake. When building with a config generated with configure, all is well. I get the same results when using gcc-4.2.1 and clang-trunk. It seems to me that there's a glitch in de CMake config somewhere. I doing a verbose build right now to investigate, but maybe someone already knows what's

Hi, I am observing a deadlock with llvm-lit on windows 7. When I attached a debugger, the communicate() call is blocked. In file utils/lit/lit/TestRunner.py > # FIXME: There is probably still deadlock potential here. Yawn. > procData = [None] * len(procs) > procData[-1] = procs[-1].communicate() I am invoking python directly on windows to run the unit tests.

> What version of cmake are you using? I am getting the opposite > behavior: every binary is linked using -rdynamic :-( BTW, I reported llvm.org/pr15543 to track this. Cheers, Rafael

On 21 August 2012 13:39, Stephen Checkoway <s at pahtak.org> wrote: > Attached is a patch that fixes it for the cmake build. I'm not positive this is the right place to put it and I really have no idea where the check should go when using the autotools. What version of cmake are you using? I am getting the opposite behavior: every binary is linked using -rdynamic :-( Cheers, Rafael

On Mar 20, 2013, at 12:14 PM, Stephen Checkoway <s at pahtak.org> wrote: > I assume the CMAKE_SHARED_LIBRARY_LINK_C_FLAGS and CMAKE_SHARED_LIBRARY_LINK_CXX_FLAGS could be set empty initially and then for those that need it, set it (or something else) to -rdynamic. Attached is a small patch that sets CMAKE_SHARED_LIBRARY_LINK_CXXFLAGS to "" (as per your patch which I

On Mar 19, 2013, at 12:03 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> What version of cmake are you using? I am getting the opposite >> behavior: every binary is linked using -rdynamic :-( > > BTW, I reported llvm.org/pr15543 to track this. When I first sent the email (in August of last year), I was using cmake 2.8.8. I now appear to be using 2.8.9

> Attached is a small patch that sets CMAKE_SHARED_LIBRARY_LINK_CXXFLAGS to "" (as per your patch which I didn't notice initially), and then sets opt, bugpoint, and JITTests to have the property ENABLE_EXPORTS set to 1. This passes -Wl,--export-dynamic on BSD and Linux (and others) and --export-all-symbols on cygwin. > > I'm not sure if there are others that should be

Now that autoconf is going away soon, I figured I'd try building using CMake. I checked out llvm, cfe and lldb from the SVN server, and followed the basic build instructions. cmake -DBUILD_SHARED_LIBS=OFF -DCMAKE_INSTALL_PREFIX=/tools/llvm/svn_head -DLLVM_TARGETS_TO_BUILD="X86;CppBackend" -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON ../llvm Everything worked well, and in

Hello. I've built and `make chech-all` rc3 tarballs using CMake build on FreeBSD 8-STABLE system. Here are results: Failing Tests (10): Clang :: Index/crash-recovery-code-complete.c Clang :: Index/crash-recovery-reparse.c Clang :: Index/crash-recovery.c LLVM :: BugPoint/crash-narrowfunctiontest.ll LLVM :: BugPoint/metadata.ll LLVM :: BugPoint/remove_arguments_test.ll

For a while now I have noticed that when I build LLVM using CMake on my OS X machine there are two dynamically linked libraries, BugpointPasses and LLVMHello, that are built with the extension ".so" instead of the extension ".dylib". This has been causing four test cases to fail when running "make check". The attached patch modifies add_llvm_loadable_module in the

Thanks - I'll try this tonight. Assuming it works, should these variables be added to the docs at http://llvm.org/docs/CMake.html ? On Wed, Jan 13, 2016 at 10:26 PM, Andrew Wilkins <axwalk at gmail.com> wrote: > > > On Thu, 14 Jan 2016 at 11:02 David Jones via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Now that autoconf is going away soon, I

On Tue, Sep 27, 2016 at 11:17 PM, Teresa Johnson <tejohnson at google.com> wrote: > Sure, I will try this and let you know. Unfortunately, though, I > have another big work commitment that is going to eat up most of my > time through Thu, although I may be able to find some time to try > it. No worries, if I get around it before you do, I will :). > I think so - what is

On Mar 26, 2014, at 6:56 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > On 3/26/2014 11:39 AM, İsmail Dönmez wrote: >> >> make check-all but yes make check would suffice. Thanks! > > I see two reported failures: > > > FAIL: LLVM :: BugPoint/compile-custom.ll (459 of 9992) > ******************** TEST 'LLVM ::

Hi, I am a newbie in LLVM. I am very impressed with this forum and appreciate your help and time. I am trying to include llvm IR parser in my codebase, the way I wanna do is generate llvm's shared object (.so) file and use it in my project. So far I haven't been able to generate correct .so's. When I build a debug build with gmake (have llvm and clang in my sandbox), I get the

While considering statically linking against libc++ (and other runtime libraries from LLVM), I rebuilt LLVM 4.0 with -DBUILD_SHARED_LIBS=OFF. There are still some .so's in llvm/lib, and only one of them seems to exist exclusively as a DSO (libLTO). There's also livLLVMLTO.a, but I doubt LTO is used after linking a binary so this just looks odd to an uninformed LLVM outside and not

Hi Takumi, I am not sure if it this change, but recently we started to build LLVMHello.so and BugpointPasses.so on OS X. A few bugpoint tests are failing, because they are looking for a dylib that doesn’t exist. Could you please take a look? Thanks -Juergen On Feb 10, 2014, at 2:34 AM, NAKAMURA Takumi <geek4civic at gmail.com> wrote: > Steve, excuse me to respond you partially. >

No, it has the wrong value. I tried it with cmake 2.8.9 and 2.8.12.2. Both of them set the variable to “.so”. On Feb 12, 2014, at 5:29 PM, NAKAMURA Takumi <geek4civic at gmail.com> wrote: > Juergen, > > Thanks to let me know. I guess r200762 (and r200763) might affect. > > Although I won't check this on darwin box, I suspect the line in > HandleLLVMOptions.cmake;

Hi all, My example compiler is working fine on Linux, including the extern'd functions (via -rdynamic flag on linker), but a friend on a MacOS (Darwin) cannot find the extern'd function. LLVM ERROR: Program used external function 'printVar' which could not be resolved! I've read some posts on the web indicating problems with the -rdynamic option on Mac's GCC, but I'm

Hi all, while writing a testcase thate needed to do a grep containg {, I found that the DejaGNU test framework didn't handle those very well. It's a bit of a fuss to escape accolades properly, but most of all the framework seemed to silently ignore errors in the escaping (and just not run the command then). See [1]. Fixing the framework resulted in 80 of the tests failing. I spent the