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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20111113/882d99aa/attachment.html>
2011/11/13 Alan Garny <agarny at hellix.com>:> 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 > > makePlease 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
2011/11/13 Alan Garny <agarny at hellix.com>:> 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
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.dllOk, 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-stdcxxOk, 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
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.dllOk, 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-stdcxxOk, 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
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: 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