similar to: llvm-config linking too much?

I'm trying to build LLVM 3.5.1 on Windows, almost successfully; the remaining stumbling block is getting static linking for release builds. The problem is that the .vcxproj is interpreted by msbuild to compile with the /MD option instead of /MT, as detailed in: https://stackoverflow.com/questions/28262372/getting-msbuild-to-use-mt-staticrelease Haven't got any answers on that question,

$(llvm-config --libs | tr " " "\n" | grep gtest) returns: -lgtest_main -lgtest instead of non-valid: -lLLVMgtest_main -lLLVMgtest It also fixes: $(ld): cannot find -lLLVMgtest $(ld): cannot find -lLLVMgtest_main --- unittests/Makefile.unittest | 2 +- utils/llvm-build/llvmbuild/componentinfo.py | 4 ++-- utils/llvm-build/llvmbuild/main.py |

On Fri, Jul 10, 2015 at 11:39 PM, Eric Christopher <echristo at gmail.com> wrote: > > > On Fri, Jul 10, 2015 at 3:37 PM Russell Wallace <russell.wallace at gmail.com> > wrote: > >> I'm trying to figure out exactly what the function and status of the >> different linking tools is. The impression I get is: >> >> 1. For linking multiple bitcode

On Sun, Feb 28, 2010 at 9:07 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Sun, Feb 28, 2010 at 1:02 PM, Russell Wallace > <russell.wallace at gmail.com> wrote: >> What's the largest integer such that something like 'return ((a * b) / >> c) >> d' works correctly on all major platforms? > > Twice the size of a pointer, i.e. 64 bits on

Ah! Okay. A quick test of llvm-lto gets an error: llvm-lto: error adding file 'main.bc': Linking COMDATs named '??_7_Iostream_error_category at std@@6B@': invalid selection kinds! Would it be the case that llvm-lto is also deprecated in favor of the gold plugin? On Tue, Feb 10, 2015 at 4:47 PM, Teresa Johnson <tejohnson at google.com> wrote: > LTOCodeGenerator is used

When I use clang on Windows to compile a program using regular expressions to intermediate code, then run the result through llvm-link and finally try to generate an executable, I get an error. All of these ingredients are necessary; it works if the program doesn't use regular expressions, and it works if I compile it directly instead of going via intermediate code. The use of the exact

On Mon, Jul 27, 2015 at 7:24 AM, Russell Wallace <russell.wallace at gmail.com> wrote: > On Fri, Jul 10, 2015 at 11:39 PM, Eric Christopher <echristo at gmail.com> > wrote: > >> >> >> On Fri, Jul 10, 2015 at 3:37 PM Russell Wallace < >> russell.wallace at gmail.com> wrote: >> >>> I'm trying to figure out exactly what the

On Fri, Jul 10, 2015 at 3:37 PM Russell Wallace <russell.wallace at gmail.com> wrote: > I'm trying to figure out exactly what the function and status of the > different linking tools is. The impression I get is: > > 1. For linking multiple bitcode (either binary or text format) files > together, llvm-link is the current and future intended tool. > > 2. For

I'm trying to figure out exactly what the function and status of the different linking tools is. The impression I get is: 1. For linking multiple bitcode (either binary or text format) files together, llvm-link is the current and future intended tool. 2. For converting bitcode files into (machine code) object files, llc is the current and future intended tool. 3. For linking multiple object

On Sun, Feb 28, 2010 at 1:02 PM, Russell Wallace <russell.wallace at gmail.com> wrote: > On Sun, Feb 28, 2010 at 8:58 PM, Eli Friedman <eli.friedman at gmail.com> wrote: >> In terms of correctness, it should work except for the fact that the >> LLVM code generators don't implement more complicated operations on >> such integers, like multiplication, division,

> On Mar 23, 2018, at 16:11, Andres Freund via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > (sorry if the CC's are inappropriate, they seemed relevant based on a > git log of IRMover.cpp) > > I'm using LLVM to implement Just-in-Time compilation for PostgreSQL. One > part of that is doing inlining of operators. For that I'm using bitcode

Following on from my last question, based on such information as I've been able to find on Google, I get the impression llvm-link is effectively deprecated / not actively maintained, because the focus of whole-program optimization is now on the gold plugin. Is that the case, or am I missing something? Running searches over the source tree, it seems the Linker class that actually implements

Looking again at your link line, I think static library has to appear after their uses. So try to put the .o before the list of library. -- Mehdi > On Mar 25, 2016, at 12:41 AM, Russell Wallace <russell.wallace at gmail.com> wrote: > > Yeah, seems to. > > a at a-VirtualBox:~$ nm /home/a/build//lib/libLLVMSupport.a | grep ZN4llvm4outsEv > U

> On Mar 26, 2018, at 17:09, Andres Freund <andres at anarazel.de> wrote: > > Hi, > > On 2018-03-26 16:44:05 -0700, Duncan P. N. Exon Smith wrote: >>> The second approach is to *not* cache modules but re-read them from disk >>> (or memory, but that's irrelevant here). That works without any sort of >>> asserts, but "leaks" memory

On Mon, Jul 27, 2015 at 9:59 AM, Russell Wallace <russell.wallace at gmail.com> wrote: > On Mon, Jul 27, 2015 at 5:52 PM, Reid Kleckner <rnk at google.com> wrote: > >> I think your original description of the situation is accurate. llvm-link >> will take multiple bitcode files and spit out a big ball o' bitcode, but >> that's usually not sufficient for

Building LLVM itself involves Cmake, but what's the best way to build a C++ program that needs to link with the LLVM libraries? If you're trying to optimise for making life as easy as possible for users and people creating binary packages, in the normal course of events, autotools is recommended. But the tutorial mentions running llvm-config to get things like library paths - does

Hi, (sorry if the CC's are inappropriate, they seemed relevant based on a git log of IRMover.cpp) I'm using LLVM to implement Just-in-Time compilation for PostgreSQL. One part of that is doing inlining of operators. For that I'm using bitcode pre-generated using clang. The current code uses a single LLVMContext & Orc to generate the code. That largely workes well. But inlining

On Mon, Jul 27, 2015 at 5:52 PM, Reid Kleckner <rnk at google.com> wrote: > I think your original description of the situation is accurate. llvm-link > will take multiple bitcode files and spit out a big ball o' bitcode, but > that's usually not sufficient for LTO, which is the main use case that we > want to support. > To be clear I understand you: the reason

Yeah, seems to. a at a-VirtualBox:~$ nm /home/a/build//lib/libLLVMSupport.a | grep ZN4llvm4outsEv U _ZN4llvm4outsEv U _ZN4llvm4outsEv 0000000000000000 b _ZGVZN4llvm4outsEvE1S 0000000000000000 T _ZN4llvm4outsEv 0000000000000000 r _ZZN4llvm4outsEvE19__PRETTY_FUNCTION__ 0000000000000000 b _ZZN4llvm4outsEvE1S U _ZN4llvm4outsEv I can try building

There are several m4 macros that let you write autoconf detection for llvm. I recently needed to implement one. Have a look here: https://github.com/google/autofdo/blob/master/m4/ax_llvm.m4 Diego. On Wed, Mar 23, 2016 at 12:48 PM, Russell Wallace via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Building LLVM itself involves Cmake, but what's the best way to build a C++ >