[LLVMdev] Problem compiling LLVM under Cygwin/Mingw

[Alain Frisch]

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: http://alain.frisch.fr/flexdll.html
That could give a solution to make LLVM plugins work under Windows.



Alain
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: conf.log
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070807/e4b97ec6/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: build.log
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070807/e4b97ec6/attachment-0001.ksh>