[LLVMdev] Build LLVM as a DLL on Windows x86
Alan Garny
Hi,
I need to build a shared version of LLVM on Windows, Linux (both x86 and x64) and Mac OS X. So far, I have been able to build LLVM on Linux and Mac OS X, and it’s all working fine as confirmed by a small LLVM test code that I wrote.
However, on Windows, even though I get a DLL, that DLL doesn’t contain any (exported) functions (according to DLL Export Viewer; see http://www.nirsoft.net/utils/dll_export_viewer.html).
Now, I know that shared libraries are not supported on Windows using CMake (according to http://www.llvm.org/docs/CMake.html) which would have been my preferred building choice, but I didn’t see anything against them not being supported using Autotools, so I thought I would try it that way (as I successively did on Linux and Mac OS X). So, based on the documentation at http://www.llvm.org/docs/GettingStarted.html, I installed MinGW/MSYS (http://sourceforge.net/projects/mingw/), selecting C++ Compiler, MSYS Basic System and MinGW Developer ToolKit from the list of components to install. Then, I installed Python (http://www.python.org/download/; version 2.7.2 not 3.x) even though it’s not listed as a pre-requirement, but without it, it doesn’t work, so… Note that version 3.x of Python didn’t work for me, I had to use version 2.7.2. Otherwise, I obviously had to do something like export PATH=/c/Python27:$PATH to make it accessible from a shell prompt. Otherwise, I haven’t installed binutils since I don’t seem to need it…?
Anyway, from there, I got LLVM's source code (see http://www.llvm.org/releases/), unpacked it and:
cd <LLVM-ROOT>
mkdir ../LLVM-build
cd ../LLVM-build
../<LLVM-ROOT>/configure --disable-docs --enable-shared --enable-targets=host
make
As you can tell, I am not using gmake (I don’t have it, but maybe it comes with binutils?), but make. I imagine it shouldn’t make any difference…? Whatever the case, and as mentioned earlier, even though I do get a (~15MB big) DLL, it doesn’t contain any (exported) functions.
Otherwise, I tried the above building process with the trunk version of LLVM, but to no avail. Maybe this will be possible with the forthcoming LLVM 3.0…? Anyway, any help on the above would be much appreciated…
Cheers, Alan.
NAKAMURA Takumi
> Anyway, from there, I got LLVM's source code (see
> http://www.llvm.org/releases/), unpacked it and:
>
> cd <LLVM-ROOT>
>
> mkdir ../LLVM-build
>
> cd ../LLVM-build
>
> ../<LLVM-ROOT>/configure --disable-docs --enable-shared
> --enable-targets=host
>
> make
Please try --enable-optimizations. debug symbols might choke building
DLL (aka tools/llvm-shlib).
If you would not solve, feel free to send to me directly, config.log
and build log.
...Takumi
_______________________________________________
LLVM Developers mailing list
LLV...@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
NAKAMURA Takumi
> Now, I know that shared libraries are not supported on Windows using CMake
> (according to http://www.llvm.org/docs/CMake.html) which would have been my
> preferred building choice, but I didn’t see anything against them not being
> supported using Autotools, so I thought I would try it that way (as I
> successively did on Linux and Mac OS X). So, based on the documentation at
> http://www.llvm.org/docs/GettingStarted.html, I installed MinGW/MSYS
> (http://sourceforge.net/projects/mingw/), selecting C++ Compiler, MSYS Basic
> System and MinGW Developer ToolKit from the list of components to install.
> Then, I installed Python (http://www.python.org/download/; version 2.7.2 not
> 3.x) even though it’s not listed as a pre-requirement, but without it, it
> doesn’t work, so… Note that version 3.x of Python didn’t work for me, I had
> to use version 2.7.2. Otherwise, I obviously had to do something like export
> PATH=/c/Python27:$PATH to make it accessible from a shell prompt. Otherwise,
> I haven’t installed binutils since I don’t seem to need it…?
You need binutils, esp. ld, nm, objdump.
FYI, how to browse export table in DLL with objdump;
$ objdump -x XXX.dll
> As you can tell, I am not using gmake (I don’t have it, but maybe it comes
> with binutils?), but make. I imagine it shouldn’t make any difference…?
> Whatever the case, and as mentioned earlier, even though I do get a (~15MB
> big) DLL, it doesn’t contain any (exported) functions.
GNU make is essential to msys build. I guess msysdtk would have it.
> Otherwise, I tried the above building process with the trunk version of
> LLVM, but to no avail. Maybe this will be possible with the forthcoming LLVM
> 3.0…? Anyway, any help on the above would be much appreciated…
AFAIK, on msys, trunk and release_30 is almost fine.
http://bb.pgr.jp/builders/clang-i686-msys
Though, here is no builder on win32 with --enable-shared.
ps. you might need also --enable-optimized --enable-shared --enable-embed-stdcxx
HTH, ...Takumi
Alan Garny
> > Otherwise,
> > I haven't installed binutils since I don't seem to need it.?
>
> You need binutils, esp. ld, nm, objdump.
>
> FYI, how to browse export table in DLL with objdump; $ objdump -x
> XXX.dll
Ok, I got the latest version of binutils from
http://sourceforge.net/projects/mingw/files/MinGW/Base/binutils/.
> > As you can tell, I am not using gmake (I don't have it, but maybe it
> > comes with binutils?), but make. I imagine it shouldn't make any
> difference.?
> > Whatever the case, and as mentioned earlier, even though I do get a
> > (~15MB
> > big) DLL, it doesn't contain any (exported) functions.
>
> GNU make is essential to msys build. I guess msysdtk would have it.
I could find a copy of msysDTK at
http://sourceforge.net/projects/mingw/files/Other/Unsupported/MSYS/msysDTK/,
but not only is the 'latest' version a very old version (2003!), but once
installed I couldn't find a copy of gmake in it.
> > Otherwise, I tried the above building process with the trunk version
> > of LLVM, but to no avail. Maybe this will be possible with the
> > forthcoming
> LLVM
> > 3.0.? Anyway, any help on the above would be much appreciated.
>
> AFAIK, on msys, trunk and release_30 is almost fine.
> http://bb.pgr.jp/builders/clang-i686-msys
> Though, here is no builder on win32 with --enable-shared.
>
> ps. you might need also --enable-optimized --enable-shared --enable-
> embed-stdcxx
Ok, starting from my original setup (i.e. MinGW/MSYS and Python), I added
binutils (http://sourceforge.net/projects/mingw/files/MinGW/Base/binutils/),
but not gmake (since I couldn't find it). From there, I built a shared
version of LLVM using configure with --disable-docs --enable-embed-stdcxx
--enable-optimized --enable-shared --enable-targets=host.
Note that according to configure --help, --enable-optimized shouldn't be
required since optimization is enabled by default. The same for embedding
libstdc++. Still, I thought I would give it a try and see how it goes.
Anyway, the bottom line is that I got the usually 'big' DLL file, but...
still no exported symbols (according to DLL Export Viewer;
http://www.nirsoft.net/utils/dll_export_viewer.html). objdump reported more
information though (including, possibly, some exported functions).
Anyway, I tried to use the resulting DLL in my (Qt-MinGW based) application,
but to no avail... So, kind of back to square one, sorry... :(
I wish the documentation on how to build a shared version of LLVM on Windows
was up-to-date (e.g. the need for Python is not mentioned) and links to
where to get prerequisites mentioned. I would be happy to help with this,
but I would first need to be able to build LLVM... Otherwise, it would be
nice, too, to have CMake to fully work with LLVM... :)
Alan
Kevin Kelley
> AFAIK, on msys, trunk and release_30 is almost fine.
> http://bb.pgr.jp/builders/clang-i686-msys Though, here is no builder
> on win32 with --enable-shared.
I'm having a problem now, building Release Candidate 3 on msys
(using msysGit environment, which I find the easiest to set up and keep
isolated);
with --enable-optimized --enable-shared, I get errors that look like this:
llvm[1]: Linking all LLVMLibs together for LLVM-3.0
llvm[1]: Collecting global symbols of LLVM-3.0
llvm[1]: Linking all libs together for static libstdc++.a
llvm[1]: Making dummy -lstdc++ to lib
llvm[1]: Collecting global symbols of stdc++
llvm[1]: Generating exports for LLVM-3.0
llvm[1]: Generating LLVM-3.0.def
llvm[1]: Linking Release Shared Library LLVM-3.0.dll
c:/dev/llvm/build-rc3/Release/lib/libLLVMCodeGen.a(RegAllocPBQP.o):fake:(.text$_
ZN4PBQP5Graph7addNodeERKNS_6VectorE[PBQP::Graph::addNode(PBQP::Vector
const&)]+0
x9c): undefined reference to
`std::_List_node_base::_M_hook(std::_List_node_base
*)'
c:/dev/llvm/build-rc3/Release/lib/libLLVMCodeGen.a(RegAllocPBQP.o):fake:(.text$_
ZN4PBQP19HeuristicSolverImplINS_10Heuristics6BriggsEE15computeSolutionEv[PBQP::H
euristicSolverImpl<PBQP::Heuristics::Briggs>::computeSolution()]+0x76):
undefine
d reference to `std::_List_node_base::_M_hook(std::_List_node_base*)'
c:/dev/llvm/build-rc3/Release/lib/libLLVMCodeGen.a(RegAllocPBQP.o):fake:(.text$_
ZN4PBQP19HeuristicSolverImplINS_10Heuristics6BriggsEE5setupEv[PBQP::HeuristicSol
verImpl<PBQP::Heuristics::Briggs>::setup()]+0xcd): undefined reference
to `std::
_List_node_base::_M_hook(std::_List_node_base*)'
c:/dev/llvm/build-rc3/Release/lib/libLLVMCodeGen.a(RegAllocPBQP.o):fake:(.text$_
ZN4PBQP19HeuristicSolverImplINS_10Heuristics6BriggsEE5setupEv[PBQP::HeuristicSol
verImpl<PBQP::Heuristics::Briggs>::setup()]+0x210): undefined reference
to `std:
:_List_node_base::_M_hook(std::_List_node_base*)'
... and so on.
I last built with RC1 and it went fine; this thread prompted me to test
RC3, and I got this.
It looks a little bit like stdlib-style problems, so I added the
--enable-embed-stdcxx, but
got the same result. All the errors seem to be coming from
register-allocator stuff, has
something changed there recently?
Kevin
Alan Garny
> I'm having a problem now, building Release Candidate 3 on msys (using
> msysGit environment, which I find the easiest to set up and keep
> isolated); with --enable-optimized --enable-shared, I get errors that look
like this:
I haven't really experimented much with LLVM 3.0, but I was wondering
whether you could share with me the way you personally build a shared
version of LLVM? I have yet to get passed the stage where I can generate a
'valid' DLL for LLVM...
Cheers, Alan.
Kevin Kelley
> On 11/13/2011 8:57 PM, NAKAMURA Takumi wrote:
>> AFAIK, on msys, trunk and release_30 is almost fine.
>> http://bb.pgr.jp/builders/clang-i686-msys Though, here is no builder
>> on win32 with --enable-shared.
> I'm having a problem now, building Release Candidate 3 on msys
> (using msysGit environment, which I find the easiest to set up and keep
> isolated);
> with --enable-optimized --enable-shared, I get errors that look like this:
A fresh build of a 2.9-era source tree, in my msysgit environment where
3.0rc3 just failed,
just completed; so I think there's a regression in recent LLVM, with
respect to the DLL build.
Óscar Fuentes
>> GNU make is essential to msys build. I guess msysdtk would have it.
>
> I could find a copy of msysDTK at
> http://sourceforge.net/projects/mingw/files/Other/Unsupported/MSYS/msysDTK/,
> but not only is the 'latest' version a very old version (2003!), but once
> installed I couldn't find a copy of gmake in it.
msysDTK is *not* required (nor useful) for building LLVM. Plain MSYS
used to include a `make' command.
[snip]
> I wish the documentation on how to build a shared version of LLVM on Windows
> was up-to-date (e.g. the need for Python is not mentioned) and links to
> where to get prerequisites mentioned. I would be happy to help with this,
> but I would first need to be able to build LLVM... Otherwise, it would be
> nice, too, to have CMake to fully work with LLVM... :)
The CMake build should work on Windows, with either VS or MinGW. LLVM
DLL's on Windows are not supported by the CMake build because the LLVM
source code lacks the symbol export directives, not because the CMake
build is missing anything. The autoconf build exploits a feature of
MinGW's binutils that auto-exports all symbols, like in Linux. It is a
bit fragile. Building the big DLL would be also possible with the CMake
build using the same technique, but AFAIR nobody cared too much.
Alan Garny
> >
> > I could find a copy of msysDTK at
> >
> http://sourceforge.net/projects/mingw/files/Other/Unsupported/MSYS/msy
> > (2003!), but once installed I couldn't find a copy of gmake in it.
>
> msysDTK is *not* required (nor useful) for building LLVM. Plain MSYS used
> to include a `make' command.
Indeed...
> > I wish the documentation on how to build a shared version of LLVM on
> > Windows was up-to-date (e.g. the need for Python is not mentioned) and
> > links to where to get prerequisites mentioned. I would be happy to
> > help with this, but I would first need to be able to build LLVM...
> > Otherwise, it would be nice, too, to have CMake to fully work with
> > LLVM... :)
>
> The CMake build should work on Windows, with either VS or MinGW. LLVM
> DLL's on Windows are not supported by the CMake build because the LLVM
> source code lacks the symbol export directives, not because the CMake build
> is missing anything.
There is at least that. I mean, there isn't the usual __declspec(dllimport) / __declspec(dllexport), but I believe I did come across (at least) another issue when I first tried to do a CMake build.
> The autoconf build exploits a feature of MinGW's
> binutils that auto-exports all symbols, like in Linux. It is a bit fragile. Building
> the big DLL would be also possible with the CMake build using the same
> technique, but AFAIR nobody cared too much.
That's too bad, I would have thought that it would have been useful to quite a few people...? Personally, I have already spent a lot of time trying to get a DLL for LLVM (too much time when I consider how quickly and easily I was able to get a shared library for LLVM on Linux and Mac OS X), but I find it difficult to tell what is wrong with my build environment.
Wouldn't it be possible for the LLVM team to release a shared library for LLVM? After all, there are already LLVM binaries for Mingw32/x86...
Alan
Alan Garny
> > Otherwise,
> > I haven't installed binutils since I don't seem to need it.?
>
> You need binutils, esp. ld, nm, objdump.
>
> FYI, how to browse export table in DLL with objdump; $ objdump -x XXX.dll
Ok, I got the latest version of binutils from
http://sourceforge.net/projects/mingw/files/MinGW/Base/binutils/.
> > As you can tell, I am not using gmake (I don't have it, but maybe it
> > comes with binutils?), but make. I imagine it shouldn't make any
> difference.?
> > Whatever the case, and as mentioned earlier, even though I do get a
> > (~15MB
> > big) DLL, it doesn't contain any (exported) functions.
>
> GNU make is essential to msys build. I guess msysdtk would have it.
I could find a copy of msysDTK at
http://sourceforge.net/projects/mingw/files/Other/Unsupported/MSYS/msysDTK/,
but not only is the 'latest' version a very old version (2003!), but once
installed I couldn't find a copy of gmake in it.
> > Otherwise, I tried the above building process with the trunk version
> > of LLVM, but to no avail. Maybe this will be possible with the
> > forthcoming
> LLVM
> > 3.0.? Anyway, any help on the above would be much appreciated.
>
> AFAIK, on msys, trunk and release_30 is almost fine.
> http://bb.pgr.jp/builders/clang-i686-msys
> Though, here is no builder on win32 with --enable-shared.
>
> ps. you might need also --enable-optimized --enable-shared --enable-
> embed-stdcxx
Ok, starting from my original setup (i.e. MinGW/MSYS and Python), I added
binutils (http://sourceforge.net/projects/mingw/files/MinGW/Base/binutils/),
but not gmake (since I couldn't find it). From there, I built a shared
version of LLVM using configure with --disable-docs --enable-embed-stdcxx
--enable-optimized --enable-shared --enable-targets=host.
Note that according to configure --help, --enable-optimized shouldn't be
required since optimization is enabled by default. The same for embedding
libstdc++. Still, I thought I would give it a try and see how it goes.
Anyway, the bottom line is that I got the usually 'big' DLL file, but...
still no exported symbols (according to DLL Export Viewer;
http://www.nirsoft.net/utils/dll_export_viewer.html). objdump reported more
information though (including, possibly, some exported functions).
Anyway, I tried to use the resulting DLL in my (Qt-MinGW based) application,
but to no avail... So, kind of back to square one, sorry... :(
I wish the documentation on how to build a shared version of LLVM on Windows
was up-to-date (e.g. the need for Python is not mentioned) and links to
where to get prerequisites mentioned. I would be happy to help with this,
but I would first need to be able to build LLVM... Otherwise, it would be
nice, too, to have CMake to fully work with LLVM... :)
Alan
Alan Garny
for the indirect help!). The 'culprit' was DLL Expert Viewer
(http://www.nirsoft.net/utils/dll_export_viewer.html). It kept reporting
that there were no exported functions, so I (wrongly) assumed that something
had gone wrong while, using PEInfo
(http://www.pazera-software.com/products/peinfo/) I could see that
everything was, in fact, correct. I have just tested things in my
application and now everything works as expected and as on Linux and Mac OS
X.
Alan
Csaba Raduly
> For what is worth, I have been able to trace my problem (thanks Kevin Kelley
> for the indirect help!). The 'culprit' was DLL Expert Viewer
> (http://www.nirsoft.net/utils/dll_export_viewer.html). It kept reporting
> that there were no exported functions, so I (wrongly) assumed that something
> had gone wrong while, using PEInfo
> (http://www.pazera-software.com/products/peinfo/) I could see that
> everything was, in fact, correct.
There's also
http://www.dependencywalker.com/
Csaba
--
GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
The Tao of math: The numbers you can count are not the real numbers.
Life is complex, with real and imaginary parts.
"Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds
"People disagree with me. I just ignore them." -- Linus Torvalds
NAKAMURA Takumi
> On 11/14/11, Alan Garny wrote:
>> For what is worth, I have been able to trace my problem (thanks Kevin Kelley
>> for the indirect help!). The 'culprit' was DLL Expert Viewer
>> (http://www.nirsoft.net/utils/dll_export_viewer.html). It kept reporting
>> that there were no exported functions, so I (wrongly) assumed that something
>> had gone wrong while, using PEInfo
>> (http://www.pazera-software.com/products/peinfo/) I could see that
>> everything was, in fact, correct.
>
> There's also
>
> http://www.dependencywalker.com/
Why not "objdump -x" ? :D
...Bikeshed
Alan Garny
> >> Kelley for the indirect help!). The 'culprit' was DLL Expert Viewer
> >> (http://www.nirsoft.net/utils/dll_export_viewer.html). It kept
> >> reporting that there were no exported functions, so I (wrongly)
> >> assumed that something had gone wrong while, using PEInfo
> >> (http://www.pazera-software.com/products/peinfo/) I could see that
> >> everything was, in fact, correct.
> >
> > There's also
> >
> > http://www.dependencywalker.com/
>
> Why not "objdump -x" ? :D
Because it's not as convenient? :)