Build LLVM as a DLL on Windows x86

Project Infrastructure LLVM Dev List Archives
1

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

mkdir …/LLVM-build

cd …/LLVM-build

…//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.

2

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

3

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
(MinGW - Minimalist GNU for Windows download | SourceForge.net), selecting C++ Compiler, MSYS Basic
System and MinGW Developer ToolKit from the list of components to install.
Then, I installed Python (Download Python | Python.org; 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

4

Hi Takumi,

> 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
MinGW - Minimalist GNU for Windows - Browse /MinGW/Base/binutils at SourceForge.net.

> 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
MinGW - Minimalist GNU for Windows - Browse /Other/Unsupported/MSYS/msysDTK at SourceForge.net,
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 (MinGW - Minimalist GNU for Windows - Browse /MinGW/Base/binutils at SourceForge.net),
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;
DLL Export Viewer - view exported functions list in Windows DLL). 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... :frowning:

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... :slight_smile:

Alan

5

Hi Takumi,

> 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
MinGW - Minimalist GNU for Windows - Browse /MinGW/Base/binutils at SourceForge.net.

> 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
MinGW - Minimalist GNU for Windows - Browse /Other/Unsupported/MSYS/msysDTK at SourceForge.net,
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 (MinGW - Minimalist GNU for Windows - Browse /MinGW/Base/binutils at SourceForge.net),
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;
DLL Export Viewer - view exported functions list in Windows DLL). 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... :frowning:

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... :slight_smile:

Alan

6

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

7

Hi Kevin,

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.

8

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.

Kevin

9

"Alan Garny" <agarny@hellix.com> writes:

GNU make is essential to msys build. I guess msysdtk would have it.

I could find a copy of msysDTK at
MinGW - Minimalist GNU for Windows - Browse /Other/Unsupported/MSYS/msysDTK at SourceForge.net,
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... :slight_smile:

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.

10

>> GNU make is essential to msys build. I guess msysdtk would have it.
>
> I could find a copy of msysDTK at
>
MinGW - Minimalist GNU for Windows - Browse Files at SourceForge.net
> sDTK/, 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.

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... :slight_smile:

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

11

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
(DLL Export Viewer - view exported functions list in Windows DLL). It kept reporting
that there were no exported functions, so I (wrongly) assumed that something
had gone wrong while, using PEInfo
(PEInfo - Portable Executable (EXE, DLL) analyzer - Pazera Software) 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

From: llvmdev-bounces@cs.uiuc.edu [mailto:llvmdev-bounces@cs.uiuc.edu]
On Behalf Of Alan Garny
Sent: 14 November 2011 16:07
To: 'Óscar Fuentes'
Cc: llvmdev@cs.uiuc.edu
Subject: Re: [LLVMdev] Build LLVM as a DLL on Windows x86

> >> GNU make is essential to msys build. I guess msysdtk would have it.
> >
> > I could find a copy of msysDTK at
> >
>
MinGW - Minimalist GNU for Windows - Browse Files at SourceForge.net
> > sDTK/, 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.

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... :slight_smile:
>
> 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

12

There's also

http://www.dependencywalker.com/

Csaba

13

Why not "objdump -x" ? :smiley:

...Bikeshed

14

>> 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
>> (DLL Export Viewer - view exported functions list in Windows DLL). It kept
>> reporting that there were no exported functions, so I (wrongly)
>> assumed that something had gone wrong while, using PEInfo
>> (PEInfo - Portable Executable (EXE, DLL) analyzer - Pazera Software) I could see that
>> everything was, in fact, correct.
>
> There's also
>
> http://www.dependencywalker.com/

Why not "objdump -x" ? :smiley:

Because it's not as convenient? :slight_smile: