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
"Alan Garny" <agarny at hellix.com> writes:>> 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.
> >> 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/msy > > 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... :) > > 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