Hello Anton,
Thanks for your help!
Anton Korobeynikov wrote:
Oh, this seems to be killer mix 
GCC (at least native mingw32 port)
has known problems being running on Vista.
I've been using this combination for a month without a problem. (But indeed, I've heard about weird things too.)
Is LLVM supposed to work with this version of GCC (probably using the -mno-cygwin option to get a Mingw-like behavior)?
Honestly speaking, I never tried this. I always used "plain" mingw32
plus msys as a shell. Wiki mentions exactly this case.
Actually, I did not do anything special with ./configure, so I guess LLVM was configured to use Cygwin's GCC (without -mno-cygwin). So I was using one of the supported configurations:
checking build system type... i686-pc-cygwin
checking host system type... i686-pc-cygwin
checking target system type... i686-pc-cygwin
checking type of operating system we're going to host on... Cygwin
checking target architecture... x86
If I pass "--host=i386-pc-mingw32" to configure, the compilation fails almost immediatly:
llvm[1]: Compiling DynamicLibrary.cpp for Debug build
In file included from DynamicLibrary.cpp:34:
Win32/DynamicLibrary.inc:19:22: dbghelp.h: No such file or directory
In file included from DynamicLibrary.cpp:34:
Win32/DynamicLibrary.inc:27: warning: ignoring #pragma comment
Win32/DynamicLibrary.inc: In static member function `static bool llvm::sys::DynamicLibrary::LoadLibraryPermanently(const char*, std::string*)':
Win32/DynamicLibrary.inc:120: error: `EnumerateLoadedModules' undeclared (first use this function)
Win32/DynamicLibrary.inc:120: error: (Each undeclared identifier is reported only once for each function it appears in.)
I'll try to compile LLVM first in pure Cygwin mode. I attach the output of ./configure (conf.log) and of make (build.log), in case you can find something weird in it. I've also tried to fix the errors directly in SelectionDAG.cpp by resolving by hand the ambiguous call, e.g.:
@@ -341,7 +341,7 @@
LoadSDNode *LD = cast<LoadSDNode>(N);
ID.AddInteger(LD->getAddressingMode());
ID.AddInteger(LD->getExtensionType());
- ID.AddInteger(LD->getLoadedVT());
+ ID.AddInteger((int) LD->getLoadedVT());
ID.AddPointer(LD->getSrcValue());
ID.AddInteger(LD->getSrcValueOffset());
ID.AddInteger(LD->getAlignment());
(and similarly for all the other ambiguous calls in SelectionDAG.cpp).
Does the coercion look reasonnable here? I guess that more recent versions of GCC are clever enough to lift the ambiguity. That should not depend on the OS. Is anyone still using GCC 3.4.4?
With these modifications, I could compile LLVM without any further problem. Maybe the fix above should be included if this is the only problem with GCC 3.4.4?
llvm[3]: Compiling PredicateSimplifier.cpp for Debug build
PredicateSimplifier.cpp: In member function `bool <unnamed>::VRPSolver::below(llvm::Instruction*)':
PredicateSimplifier.cpp:1417: warning: control reaches end of non-void function
PredicateSimplifier.cpp: In member function `bool <unnamed>::DomTreeDFS::dominates(llvm::Instruction*, llvm::Instruction*)':
PredicateSimplifier.cpp:247: warning: control reaches end of non-void function
That's strange. Is it possible to update to gcc 3.4.5? (I'm using this
for windows builds).
It doesn't seem to be packaged in Cygwin, and I cannot break the existing system, so I will try to continue with the current version.
Can you try to look into preprocessed source? How
is assert() expanded there?
The assert at line 241 is expanded into:
((!"Instructions not found in parent BasicBlock?") ? (void)0 : __assert("PredicateSimplifier.cpp", 241, "!\"Instructions not found in parent BasicBlock?\""));
llvm[3]: Linking Debug Loadable Module LLVMHello.dll
mklib: link: warning: undefined symbols not allowed in i686-pc-cygwin shared libraries
It seems, that configure machinery was confused by mix of cygwin
environment and mingw32 tools. Can you try to reconfigure with
--host=i386-pc-mingw32 ?
See above. It was actually a pure Cygwin installation (sorry for the confusion).
In fact LLVM plugins (which are shared
libraries) are not supported on windows due to difference in linker
stuff (static vs dynamic).
I know what you mean. FWIW, I've been working on a way to emulate POSIX-like dlopen API under Windows: Alain Frisch: FlexDLL
That could give a solution to make LLVM plugins work under Windows.
Alain
conf.log (15.8 KB)
build.log (22.6 KB)