[LLVMdev] llvm build errors on windows/mingw32
Ronald Pijnacker
When I try to build llvm on windows/mingw32, I get the following error:
In file included from c:/work/mingw/src/llvm/lib/System/Signals.cpp:33:
c:/work/mingw/src/llvm/lib/System/Win32/Signals.inc: In function 'LONG LLVMUnhandledExceptionFilter(_EXCEPTION_POINTERS*)':
c:/work/mingw/src/llvm/lib/System/Win32/Signals.inc:275: error: exception handling disabled, use -fexceptions to enable
make[1]: *** [/c/work/mingw/src/build.llvm/lib/System/Release/Signals.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory `/c/work/mingw/src/build.llvm/lib/System'
Thanks,
Ronald
_______________________________________________
LLVM Developers mailing list
LLV...@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
罗勇刚(Yonggang Luo)
solve this problem, and by the way, are you using msys as the building
env? It's seems that mingw/cmake is working but mingw/msys, and I
didn't ever try with mingw/cygwin:) thanks.
2009/10/1, Ronald Pijnacker <pijn...@dse.nl>:
--
从我的移动设备发送
此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
罗勇刚(Yonggang Luo)
Óscar Fuentes
> Well, Now I get the solution.
> Please, someone can apply the patch.
>
> Just modify the makefile resident in lib/System
I'm afraid this patch is not acceptable. It activates C++ exception
support unconditionally while building libLLVMSystem, which is used
everywhere.
You'll better investigate why exception support is required for MSYS
while all other configure-based builds work fine without it.
[snip]
--
Óscar
罗勇刚(Yonggang Luo)
I'm afraid this patch is not acceptable. It activates C++ exception
support unconditionally while building libLLVMSystem, which is used
everywhere.
You'll better investigate why exception support is required for MSYS
while all other configure-based builds work fine without it.
sincerely,
Yonggang Luo
Jay Foad
> while all other configure-based builds work fine without it.
Surely it's required for any system that uses
lib/System/Win32/Signals.inc, because there's code in that file that
uses try/catch.
MingW is the only system I know of that uses that file; Cygwin
pretends to be Unix-like, so it uses lib/System/Unix/Signals.inc
instead. So I'd suggest the attached (untested) patch.
Jay.
Ronald Pijnacker
Yes, I get the same error.
Dimitry Andric
> Well, Now I get the solution.
> Please, someone can apply the patch.
>
> Just modify the makefile resident in lib/System
>
> But, a new error is appeared
> llvm[2]: Linking Debug unit test ADT
> d:/objs/llvm/msys/Debug/lib/libLLVMSystem.a(Process.o):e:/Downloads/llvm-trunk/lib/System/Win32/Process.inc:78:
> undefined reference to `GetProcessMemoryInfo@12'
GetProcessMemoryInfo should be defined in psapi.lib, but AFAICS mingw32
doesn't have this import lib. It is included in the MS Platform SDK,
but I'm not sure whether you can link that into mingw32 programs...
Ronald Pijnacker
> > Well, Now I get the solution.
> > Please, someone can apply the patch.
> >
> > Just modify the makefile resident in lib/System
> >
> > But, a new error is appeared
> > llvm[2]: Linking Debug unit test ADT
> > d:/objs/llvm/msys/Debug/lib/libLLVMSystem.a(Process.o):e:/Downloads/llvm-trunk/lib/System/Win32/Process.inc:78:
> > undefined reference to `GetProcessMemoryInfo@12'
>
> GetProcessMemoryInfo should be defined in psapi.lib, but AFAICS mingw32
> doesn't have this import lib. It is included in the MS Platform SDK,
> but I'm not sure whether you can link that into mingw32 programs...
Ronald
Dimitry Andric
> Surely it's required for any system that uses
> lib/System/Win32/Signals.inc, because there's code in that file that
> uses try/catch.
>
> MingW is the only system I know of that uses that file; Cygwin
> pretends to be Unix-like, so it uses lib/System/Unix/Signals.inc
> instead. So I'd suggest the attached (untested) patch.
It won't work as-is, because HOST_OS is not defined at that point in the
Makefile. Including Makefile.config helps, at least in my case. :)
E.g:
Index: lib/System/Makefile
===================================================================
--- lib/System/Makefile (revision 83249)
+++ lib/System/Makefile (working copy)
@@ -11,6 +11,12 @@
LIBRARYNAME = LLVMSystem
BUILD_ARCHIVE = 1
+include $(LEVEL)/Makefile.config
+
+ifeq ($(HOST_OS),MingW)
+REQUIRES_EH := 1
+endif
+
EXTRA_DIST = Unix Win32 README.txt
include $(LEVEL)/Makefile.common
Dimitry Andric
>> On 2009-10-02 01:07, 罗勇刚(Yonggang Luo) wrote:
>>> d:/objs/llvm/msys/Debug/lib/libLLVMSystem.a(Process.o):e:/Downloads/llvm-trunk/lib/System/Win32/Process.inc:78:
>>> undefined reference to `GetProcessMemoryInfo@12'
>> GetProcessMemoryInfo should be defined in psapi.lib, but AFAICS mingw32
>> doesn't have this import lib. It is included in the MS Platform SDK,
>> but I'm not sure whether you can link that into mingw32 programs...
> msdn suggests kernel32, but that is already included.
My apologies, I was mistaken, as Yonggang pointed out to me privately;
mingw32 does come with a libpsapi.lib file, but in your case it does not
get added to the libs to be linked with, apparently.
In my case, the configure script does check for the existence of
libpsapi.a, and adds both a HAVE_LIBPSAPI define to config.h, and
-lpsapi to LIBS.
Can you find anything in your config.log file about libpsapi?
Ronald Pijnacker
> >>> undefined reference to `GetProcessMemoryInfo@12'
> >> GetProcessMemoryInfo should be defined in psapi.lib, but AFAICS mingw32
> >> doesn't have this import lib. It is included in the MS Platform SDK,
> >> but I'm not sure whether you can link that into mingw32 programs...
> > msdn suggests kernel32, but that is already included.
>
> My apologies, I was mistaken, as Yonggang pointed out to me privately;
> mingw32 does come with a libpsapi.lib file, but in your case it does not
> get added to the libs to be linked with, apparently.
>
> In my case, the configure script does check for the existence of
> libpsapi.a, and adds both a HAVE_LIBPSAPI define to config.h, and
> -lpsapi to LIBS.
>
> Can you find anything in your config.log file about libpsapi?
#define HAVE_LIBPSAPI 1
in config.h
Ronald
Ronald Pijnacker
> > >>> undefined reference to `GetProcessMemoryInfo@12'
> > >> GetProcessMemoryInfo should be defined in psapi.lib, but AFAICS mingw32
> > >> doesn't have this import lib. It is included in the MS Platform SDK,
> > >> but I'm not sure whether you can link that into mingw32 programs...
> > > msdn suggests kernel32, but that is already included.
> >
> > My apologies, I was mistaken, as Yonggang pointed out to me privately;
> > mingw32 does come with a libpsapi.lib file, but in your case it does not
> > get added to the libs to be linked with, apparently.
> >
> > In my case, the configure script does check for the existence of
> > libpsapi.a, and adds both a HAVE_LIBPSAPI define to config.h, and
> > -lpsapi to LIBS.
> >
> > Can you find anything in your config.log file about libpsapi?
>
> #define HAVE_LIBPSAPI 1
> in config.h
When I put -lpsapi after -lLLVMSystem, it links ok.
Benjamin Kramer
Am 02.10.2009 um 21:07 schrieb Ronald Pijnacker:
> I had a close look at the link line, and -lpsapi is specified before
> -lLLVMSystem (which is giving the error).
> When I put -lpsapi after -lLLVMSystem, it links ok.
I commited a fix for this problem and a modified version of Jay's
patch here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090928/088265.html
I hope MingW builds work again now :)
Dimitry Andric
>> I had a close look at the link line, and -lpsapi is specified before
>> -lLLVMSystem (which is giving the error).
>> When I put -lpsapi after -lLLVMSystem, it links ok.
>
> I commited a fix for this problem and a modified version of Jay's
> patch here:
> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090928/088265.html
>
> I hope MingW builds work again now :)
Now the problem comes from another side, as GNU ld seems rather picky
about the library order:
$ g++ -I/d/Home/Dim/Src/llvm/include -I/d/Home/Dim/Src/llvm/obj/include -I/d/Home/Dim/Src/llvm/obj/unittests/Transforms/Utils -I/d/Home/Dim/Src/llvm/unittests/Transforms/Utils -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -I/d/Home/Dim/Src/llvm/utils/unittest/googletest/include/ -Wno-variadic-macros -g -fno-exceptions -Woverloaded-virtual -pedantic -Wno-long-long -Wall -W -Wno-unused-parameter -Wwrite-strings -g -L/d/Home/Dim/Src/llvm/obj/Debug/lib -L/d/Home/Dim/Src/llvm/obj/Debug/lib -o Debug/UtilsTests.exe /d/Home/Dim/Src/llvm/obj/unittests/Transforms/Utils/Debug/Cloning.o -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMTarget -lLLVMMC -lLLVMCore -lLLVMSupport -lLLVMSystem -lpthread -lpsapi -limagehlp -lm -lGoogleTest -lUnitTestMain
d:/Home/Dim/Src/llvm/obj/Debug/lib/libGoogleTest.a(gtest.o):gtest.cc:(.text$_ZN4llvm14raw_os_ostreamC1ERSo[llvm::raw_os_ostream::raw_os_ostream(std::basic_ostre
am<char, std::char_traits<char> >&)]+0x1e): undefined reference to `vtable for llvm::raw_os_ostream'
d:/Home/Dim/Src/llvm/obj/Debug/lib/libGoogleTest.a(gtest.o):gtest.cc:(.text$_ZN4llvm23convertible_fwd_ostreamD1Ev[llvm::convertible_fwd_ostream::~convertible_fw
d_ostream()]+0x2b): undefined reference to `llvm::raw_os_ostream::~raw_os_ostream()'
d:/Home/Dim/Src/llvm/obj/Debug/lib/libGoogleTest.a(gtest.o):gtest.cc:(.text$_ZN4llvm23convertible_fwd_ostreamD0Ev[llvm::convertible_fwd_ostream::~convertible_fw
d_ostream()]+0x2b): undefined reference to `llvm::raw_os_ostream::~raw_os_ostream()'
collect2: ld returned 1 exit status
E.g. now libGoogletest.a requires some symbols from libLLVMSupport.a,
and it has been moved to the end of the linking command line.
When I make the order:
-lGoogleTest
-lUnitTestMain
-lLLVMTransformUtils
-lLLVMipa
-lLLVMAnalysis
-lLLVMTarget
-lLLVMMC
-lLLVMCore
-lLLVMSupport
-lLLVMSystem
-lpthread
-lpsapi
-limagehlp
-lm
it links okay. I have tested a similar fix as r83252, which I saw you
just committed, and that seems to work. At least, it's far into the
examples directory by now, without problems...
Dimitry Andric
> it links okay. I have tested a similar fix as r83252, which I saw you
> just committed, and that seems to work. At least, it's far into the
> examples directory by now, without problems...
Apologies for replying to myself, but I just want to confirm that it now
(with r83252) builds completely to the end. Thanks for the quick fix.
Ronald Pijnacker
> > it links okay. I have tested a similar fix as r83252, which I saw you
> > just committed, and that seems to work. At least, it's far into the
> > examples directory by now, without problems...
>
> Apologies for replying to myself, but I just want to confirm that it now
> (with r83252) builds completely to the end. Thanks for the quick fix.
>
Thanks. Indeed it builds ok now.
Ronald