similar to: Problem with mingw32 DLL build

On Tue, Mar 1, 2016 at 4:21 PM Reid Kleckner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > First, I'd like to say it would be great if we could get away from relying > on these globally unique pass IDs represented as addresses of globals. Long > ago I tried to hack up a DLL build of LLVM and quickly discovered that > these IDs are the biggest source of dllimported

> On Sep 30, 2016, at 12:57 PM, Carsten Mattner <carstenmattner at gmail.com> wrote: > > On Fri, Sep 30, 2016 at 6:35 PM, Teresa Johnson <tejohnson at google.com> wrote: >> I just built a stage-1 compiler from the 3.9 release bits and built >> the lldb from head sources which worked fine. Let me try again using >> 3.9 build compiler to build 3.9 bits. >

On Fri, Sep 30, 2016 at 10:19 PM, Teresa Johnson <tejohnson at google.com> wrote: > > > On Fri, Sep 30, 2016 at 1:11 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > > > > > > On Sep 30, 2016, at 12:57 PM, Carsten Mattner <carstenmattner at gmail.com> > > > wrote: > > > > > > On Fri, Sep 30, 2016 at 6:35 PM, Teresa

On Tue, Sep 27, 2016 at 6:53 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > > > On Sep 27, 2016, at 2:18 AM, Carsten Mattner <carstenmattner at gmail.com> > wrote: > > > >> On Mon, Sep 26, 2016 at 11:02 PM, Teresa Johnson <tejohnson at google.com> > wrote: > >> I'll either need to get a reproducer from you and/or try to repro

Lately I've been using some utilities to increase the number of logic errors caught at compile time. I thought they might be useful to the LLVM project. I'd appreciate feedback on the below proposal. Would the community find these useful? -David RFC: Strong typedef utilities for LLVM -------------------------------------- Abstract -------- This proposal

my build environment: Win7 x64 VStudio 2017 Community Edition 15.8.4 (latest) CMake 3.12.1 (x86) git 2.19.0 (latest, x64) Python 2.7.2 (x86) my build steps: open VS2017 x64 developer command prompt cd D:\projects\fun\jit_tests mkdir llvm cd llvm git clone https://github.com/llvm-mirror/llvm mkdir llvm-build cd llvm-build cmake -G "Visual Studio 15 2017 Win64" -DBUILD_SHARED_LIBS=ON

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

Dear all, while trying to build llvm with shared libraries using GCC (tested both in Ubuntu 14.04 and Ubuntu 16.04) as in cmake -G Ninja -DBUILD_SHARED_LIBS=ON I run into the following link error lib/Transforms/IPO/CMakeFiles/LLVMipo.dir/PartialInlining.cpp.o: In function `llvm::ForwardDominanceFrontierBase<llvm::BasicBlock>::ForwardDominanceFrontierBase()':

Hi, Is it possible to generate pass (shared object) from Cmake? I tried to use add_llvm_library() however it produces only static libs. Thanks, Mariusz.

On Mon, Apr 10, 2017 at 8:42 AM, C Bergström <cbergstrom at pathscale.com> wrote: > -DBUILD_SHARED_LIBS=OFF should be exactly that, but as I think > someone else indicated there's a bit of work for it to actually be > what it advertises to be. Mehdi wrote it's correct for all of the listed dynlibs to be installed. > This could get gray when you consider that you really

No worries, thanks for the update. Teresa On Mon, Sep 26, 2016, 7:16 AM Carsten Mattner <carstenmattner at gmail.com> wrote: > On Mon, Sep 26, 2016 at 3:52 PM, Teresa Johnson <tejohnson at google.com> > wrote: > > > > ThinLTO needs to create as many temporary files as there are input > > modules to the link. From your 'ls' below, it doesn't look

So I've been looking around for people who have built shared libraries on windows and have run in to a bit of a stumbling block. I'm able to compile without the BUILD_SHARED_LIBS flag but if I put turn the flag on as follows: cmake -G "MinGW Makefiles" -DCMAKE_BUILD_TYPE:STRING=Release -DBUILD_SHARED_LIBS:BOOL=ON ../llvm-2.7 Then call: mingw32-make I get: ... Linking CXX

Hi Nico, Reid, and Anton, I missed the discussion when I implemented dllexport/dllimport for our local tree. I essentially implemented your approach#1. I was trying to avoid the various external_linkage + some_attribute approaches because it seems that external_linkage would imply the external linkage without the dllimport/dllexport semantics, and there may be existing compiler codes that rely on

Hello, while improving and extending support for dllexport/import I have noticed that the current way these are implemented is problematic and I would like some input on how to proceed. Currently dllexport/dllimport is treated as linkage type. This conflicts with inlined functions because there is no linkage for the combination of both. On first though, combining both doesn't make sense, but

mg <mariusz.grad at googlemail.com> writes: > Is it possible to generate pass (shared object) from Cmake? ? Please name the library or libraries you want to build as shared objects. > I tried to use add_llvm_library() however it produces only static > libs. As mentioned on http://www.llvm.org/docs/CMake.html : cmake -DBUILD_SHARED_LIBS=ON path/to/llvm/source This builds all

> On Jul 2, 2015, at 2:05 PM, Jim Grosbach <grosbach at apple.com> wrote: > >> >> On Jul 2, 2015, at 1:17 PM, Ethan J. Johnson <ejohns48 at cs.rochester.edu <mailto:ejohns48 at cs.rochester.edu>> wrote: >> >> Hi all, >> >> I am working on creating a MachineFunctionPass to perform an analysis on X86 code. After a bit of trouble, I was

Óscar Fuentes <ofv at wanadoo.es> wrote: > The following message is a courtesy copy of an article > that has been posted to gmane.comp.compilers.llvm.devel as well. > > nobled <nobled at dreamwidth.org> writes: > >> The LLVM 2.7 release notes say you can use ./configure --enable-shared >> to build LLVM as a shared library (libLLVM2.7.so), and the LLVM tools

On 23.04.2013 19:10, Gao, Yunzhong wrote: > I missed the discussion when I implemented dllexport/dllimport for our local tree. I > essentially implemented your approach#1. I was trying to avoid the various > external_linkage + some_attribute approaches because it seems that external_linkage > would imply the external linkage without the dllimport/dllexport semantics, and there > may

I tried the new cmake-based build system to build Opus on Linux and macOS. I'm not familiar with cmake but based on instructions I found online I used it as follows: - mkdir build - cd build - cmake -DCMAKE_INSTALL_PREFIX:PATH=<install-path> .. - make - ctest - make install Although the "make" command completed, it reported that optimizations were disabled:

The LLVM 2.7 release notes say you can use ./configure --enable-shared to build LLVM as a shared library (libLLVM2.7.so), and the LLVM tools will link against that instead of including the static libraries, so I was wondering: Is there a way to configure LLVM the same way using CMake (so it can work on Windows)? In the other direction, is there an equivalent ./configure flag to setting