similar to: Shipping LLVM.dll for the C API with the Windows installer.

We already half-have this, the LLVM_BUILD_LLVM_C_DYLIB cmake option builds a shared object which exports the llvm-c interface but it only works on Darwin. tools/llvm-shlib/CMakeLists.txt is where how this is done is defined, and it looks like it does it by: * build LLVM.so * use nm+awk+sed to pick out the symbols starting with LLVM * build LLVM-C.so using a -reexport_library linker option

The following is an older commandline i used. Have a more recent one at home. But basically you can write it as batch and trigger it within a target during the build(never got targets into correct order, i am a cmake noob) So for reference, i'll post this one and look for the recent one at home(if that didn't go down with my recent hdd crash): cmd /Q /V:ON /c "for /F

Made a bit of headway here: https://reviews.llvm.org/D35077 Cheers, Jakob. On Thu, Apr 6, 2017 at 2:34 PM, Alexander Benikowski <sebal007 at googlemail.com> wrote: > Maybe someone can use this as a startingpoint to add the windows-specific > commandblock which is triggered instead of the Darwin one together with a > proper setup of targets to have the libs build before. > >

Thanks for starting! Btw here is my CMD version: cmd /Q /V:ON /c "for /F "tokens=4" %l in ('dir llvm*.lib') do (for /F "tokens=2" %e in ('dumpbin /linkermember:1 %l ^| findstr "_LLVM"') do (set symbolname=%e & echo !symbolname:~1!))" You run it in the directory with all the llvm*.lib (yes the ThinLTO is excluded in this example but can

I am sorry, just noticed i repeated myself :( 2017-07-10 15:20 GMT+02:00 Alexander Benikowski <sebal007 at googlemail.com>: > Thanks for starting! > Btw here is my CMD version: > > cmd /Q /V:ON /c "for /F "tokens=4" %l in ('dir llvm*.lib') do (for /F > "tokens=2" %e in ('dumpbin /linkermember:1 %l ^| findstr "_LLVM"') do

On Wed, Dec 23, 2015 at 9:38 PM, Aaron Ballman <aaron at aaronballman.com> wrote: > On Wed, Dec 23, 2015 at 3:28 PM, Reid Kleckner <rnk at google.com> wrote: >> On Wed, Dec 23, 2015 at 11:25 AM, Aaron Ballman via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >>> >>> On Wed, Dec 23, 2015 at 1:55 PM, Jakob Bornecrantz <wallbraker at

r257499 On Sun, Jan 10, 2016 at 1:23 PM, Jakob Bornecrantz <wallbraker at gmail.com> wrote: > On Thu, Dec 24, 2015 at 1:28 AM, Jakob Bornecrantz <wallbraker at gmail.com> > wrote: > > On Wed, Dec 23, 2015 at 9:38 PM, Aaron Ballman <aaron at aaronballman.com> > wrote: > >> On Wed, Dec 23, 2015 at 3:28 PM, Reid Kleckner <rnk at google.com> wrote:

On Wed, Dec 23, 2015 at 11:25 AM, Aaron Ballman via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Wed, Dec 23, 2015 at 1:55 PM, Jakob Bornecrantz <wallbraker at gmail.com> > wrote: > > On Wed, Dec 23, 2015 at 5:49 PM, Aaron Ballman <aaron at aaronballman.com> > wrote: > >> On Wed, Dec 23, 2015 at 11:29 AM, Jakob Bornecrantz via llvm-dev > >>

I was looking to write a cross platform utility that worked with ELF/DWARF files. I need the utility to run on OS X, Linux and Windows. I figured I could use clang/llvm to build this tool. I've made good progress on OS X. Before I got too far, though. I decided to verify that I can build the code on Windows. I downloaded the 3.8.0 Windows installer from the llvm downwloads page, ran the

I'm building on Windows x64 using cmake, Ninja and VS 2013 express on Windows 7. So I have been using the LLVMSharp method on getting a usable loadable LLVM.dll[1][2]. This have worked out of the box before so it is a regression, I tracked it down to commit r250501. That commit breaks this commit, other users have also run into this specific problem[3][4]. I tried looking into the

On Wed, Dec 23, 2015 at 5:49 PM, Aaron Ballman <aaron at aaronballman.com> wrote: > On Wed, Dec 23, 2015 at 11:29 AM, Jakob Bornecrantz via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> I'm building on Windows x64 using cmake, Ninja and VS 2013 express on Windows 7. >> >> So I have been using the LLVMSharp method on getting a usable loadable >>

FWIW, I've got a powershell script that builds an exports.def file for recognizable C functions. You could adapt it to Python and make it part of the official build if the LLVM community thinks it will be beneficial to have libLLVM.dll The script is located here: https://github.com/mjsabby/LLVMSharp/blob/master/GenLLVMDLL.ps1 On Wed, Apr 1, 2015 at 9:03 AM, Reid Kleckner <rnk at

Upon reading http://llvm.org/docs/GettingStarted.html it says I can build shared libs, but when going to the CMake doc ( http://llvm.org/docs/CMake.html) it says Shared libraries are not supported on Windows and not recommended for other OSes. Is there a reason why? At least for on Windows. -------------- next part -------------- An HTML attachment was scrubbed... URL:

As the topic says, are there any plans for adding this before the 3.8 release? Cheers, Jakob.

Ok, I have just found the cause of the error messages I am getting, and it now makes sense to me why the 'normal' build works fine on Windows, Linux and OS X, and why my personal build works on Linux and OS X, but not on Windows. However, I still don't understand why I am getting the error messages I am getting. Anyway, it has to do with wanting to export some classes and function,

Actually, adding a LLVM_EXPORT macro would be positive for other environments, because you can then build LLVM as a shared library with -fvisibility=hidden and use LLVM_EXPORT to only make public symbols visible. There are several advantages to this, as noted here: http://gcc.gnu.org/wiki/Visibility From: Reid Kleckner Sent: Wednesday, May 08, 2013 6:21 PM To: Peng Cheng Cc: LLVMdev at

According to http://llvm.org/docs/CMake.html, "Shared libraries are not supported on Windows and not recommended in the other OSes". The problem is that static libraries have some limitations, especially when linked into multiple shared libraries, the global data of llvm could have multiple copies leading to undefined behaviors. This has caused much pains during my usage of llvm. My

On Wed, 4 Nov 2009 17:42:26 +0000 Jakob Bornecrantz <jakob at vmware.com> wrote: > Hi Jerome > > On 4 nov 2009, at 15.58, Jerome Glisse wrote: > > > > Note: For reference my issue is with cursor on old radeon hw, > > cursor must be in the next 128M from the crtc scanout buffer. We > > got issue when someone start to resize their screen at which > >

Hi all, I've been thinking about how best to represent MachO's LC_REEXPORT_DYLIB (used even by libSystem.dylib to provide its various sub-components[*]). It looks like this functionality would naturally fall into the InputGraph, in analogy with Groups and Archives. Unfortunately, it's rather more dynamic than the existing cases: we don't know the needed files before parsing the

Hi All, Pragmatic Dave Thomas tells me that Rails Recipes (http://pragmaticprogrammer.com/titles/fr_rr) is now shipping! He and Andy apparently have over a ton of books to deliver. If you''ve ordered a paper book, it''s soon on the way. If you''ve been waiting, now''s the time. Amazon is also has the book in stock