similar to: LLVM static libs

Hi all, I would like to have better C API for LLVM JIT, as I have plans to use it from Rust. I've sent already a patch [1] that adds possibility to create custom memory managers based on SectionMemoryManager using C API. What I would like to have now is a possibility to access ORC through C API somehow. The problem here is that ORC uses templates heavily. So I'm looking for any

> On Jan 14, 2016, at 11:22 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> >> On Jan 14, 2016, at 9:38 AM, Chris Bieneman via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> >>> On Jan 14, 2016, at 5:18 AM, Dan Liew <dan at su-root.co.uk> wrote: >>> >>> On 14 January 2016 at 11:24, David Jones via llvm-dev

Lang, aren't you going to be the major (only?) player when it comes to Orc APIs, if you're not opposed to it having them in the C bindings proper will certainly help. That's my vote, I understand it is different from the previous cases but the API surface area here is relatively small. On Mon, Sep 7, 2015 at 5:37 PM, Lang Hames <lhames at gmail.com> wrote: > Hi Jauhien, >

Hi, On Tue, Jan 19, 2016 at 7:18 PM, Chris Bieneman <beanz at apple.com> wrote: > The LLVM libraries are not API stable (especially not the ones you generate with BUILD_SHARED_LIBS). Those libraries are really not intended to ship. I know that's why I need them versioned. Currently we (openSUSE) ship libLLVM package which will install libLLVMFooBar.so.3.7 files and llvm-devel

Hi, On Tue, Jan 19, 2016 at 8:09 PM, Chris Bieneman <beanz at apple.com> wrote: > I think the right solution here is to fix LLVM_BUILD_LLVM_DYLIB and LLVM_LINK_LLVM_DYLIB (which should work) rather than fixing BUILD_SHARED_LIBS which was never intended to work for this use case. > > Either way, patches welcome. This seems to be due to your commit http://reviews.llvm.org/D13841 ,

Hi folks, I’m trying to port some code built on top of LLVM/Clang to Windows, however I just discovered that the precompiled versions from releases.llvm.org are missing all the libLLVM* and libclang* dlls. Also, some tools (e.g. opt) are missing on Windows as well. I’m curious whether it’s a technical limitation (i.e. certain things don’t work on Windows), or something else? For the others out

Hi, For lllvm 3.7 and before BUILD_SHARED_LIBS=ON would produce versioned shared libs like libLLVMLTO.so (symlink) libLLVMLTO.so.3.7 (symlink) libLLVMLTO.so.3.7.0 (real file) now it just builds an unversioned libLLVMLTO.so file which I believe is a problem because when a program links to llvm it generates a runtime dependency on libLLVMLTO.so instead of libLLVMLTO.so.3.7.0 which will break

> On Jan 14, 2016, at 5:18 AM, Dan Liew <dan at su-root.co.uk> wrote: > > On 14 January 2016 at 11:24, David Jones via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Thanks - I'll try this tonight. >> >> Assuming it works, should these variables be added to the docs at >> http://llvm.org/docs/CMake.html ? > > Yes. It probably makes

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

Hi, In SUSE we have recently switched from building LLVM as multiple shared libraries (using BUILD_SHARED_LIBS) to building it as a single shared library (using LLVM_BUILD_LLVM_DYLIB). The multiple shared libraries build was causing issues and apparently it is only meant for LLVM developers. Our guidelines prohibit linking against static libraries unless there is no other option. After this

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

Hi, On Tue, Jan 26, 2016 at 6:57 PM, ChrisBieneman <beanz at apple.com> wrote: > Yes, I'm aware of the change that caused this. It was when I stopped setting SOVERSION as a target property on all shared libraries. That change was deliberate in order to match functionality between CMake and the autoconf build. > > In the autoconf build we didn't actually set the SOVERSION on

On Mon, Sep 7, 2015 at 5:37 PM Lang Hames <lhames at gmail.com> wrote: > Hi Jauhien, > > A few people have requested a C API for ORC. I don't think ORC's ready for > a stable C API, but I'm not opposed to providing C bindings that will > probably be reasonably stable in practice (though with no guarantees). I've > actually already knocked up some trivial

Hello, I've spent some time hacking up the Debian packaging to use CMake instead of autotools; it's still a work in progress, but it works. It's a bit of a mess, though, primarily because there are differences in the output of the CMake and autotools builds. On my Ubuntu machine, the dependencies for clang-3.6 look like this: $ ldd /usr/bin/clang-3.6 linux-vdso.so.1 =>

Hi Yin, I second David's words. I use shared libs myself on debug builds, but static builds with gold on a local disk is pretty feasible. Before I used gold, I had to have 16GB of RAM on my laptop, now I need less than 8GB for static builds. On 28 January 2016 at 23:58, Yin Ma via cfe-dev <cfe-dev at lists.llvm.org> wrote: > It is O.K. I just hope BUILD_SHARED_LIBS=ON is tested

On 02/05/2019 11:26 AM, Michał Górny wrote: > On Tue, 2019-02-05 at 11:23 -0800, Tom Stellard wrote: >> On 02/05/2019 08:07 AM, Michał Górny wrote: >>> On Tue, 2019-02-05 at 07:36 -0800, Tom Stellard via Release-testers >>> wrote: >>>> Hi, >>>> >>>> The release_70 branch is ready for the 7.1.0 release. I have updated the

On 02/05/2019 08:07 AM, Michał Górny wrote: > On Tue, 2019-02-05 at 07:36 -0800, Tom Stellard via Release-testers > wrote: >> Hi, >> >> The release_70 branch is ready for the 7.1.0 release. I have updated the >> version and pushed a fix for https://bugs.llvm.org/show_bug.cgi?id=39427, >> which is the only bug we will be fixing in this release. >> >>

Hi Andrew, since today, I get: $ llvm-config --link-shared --libs engine llvm-config: error: libLLVM-3.8svn.so is missing Looking at the log, this is most likely caused by your recent change. cmake shared library builds generate separate .so files analogous to the static library builds, e.g. libLLVMCodeGen.so (no version suffix, curiously enough). It would be nice if that wasn't broken

Hello everyone, A while back I hit an issue where the presence of multiple OpenCL runtimes on a single system triggered errors in libLLVM caused by redeclaring command line arguments [0]. There's been some discussion on the bug report and a pointer to a slightly older report, unrelated to OpenCL, but most likely about the same issue [1]. OpenCL uses an ICD loader library to abstract away

On Tue, 2019-02-05 at 16:13 -0800, Tom Stellard wrote: > On 02/05/2019 11:32 AM, Tom Stellard via Release-testers wrote: > > On 02/05/2019 11:26 AM, Michał Górny wrote: > > > On Tue, 2019-02-05 at 11:23 -0800, Tom Stellard wrote: > > > > On 02/05/2019 08:07 AM, Michał Górny wrote: > > > > > On Tue, 2019-02-05 at 07:36 -0800, Tom Stellard via