I'm trying to cross-compile LLVM with build=, host=target=. I'm using the following packages from Debian lenny: mingw32 4.2.1.dfsg-1 mingw32-binutils 2.18.50-20080109-1 mingw32-runtime 3.13-1 The first problem I hit was when I configured with CC, CXX, AR and RANLIB set to mingw cross-tools, but forgot to specify NM as well. This resulted in a load of warnings that scrolled off the screen: nm: AliasAnalysis.o: File format not recognized nm: AliasAnalysisCounter.o: File format not recognized nm: AliasAnalysisEvaluator.o: File format not recognized nm: AliasDebugger.o: File format not recognized nm: AliasSetTracker.o: File format not recognized nm: Analysis.o: File format not recognized ... followed by millions of undefined symbols when linking any executable: llvm[2]: Linking Debug executable opt /home/foad/llvm/objdir-mingw/tools/opt/Debug/AnalysisWrappers.o: In function `~CallGraphPrinter': /home/foad/svn/llvm-project/llvm/trunk/tools/opt/AnalysisWrappers.cpp:71: undefined reference to `llvm::ModulePass::~ModulePass()' /home/foad/svn/llvm-project/llvm/trunk/tools/opt/AnalysisWrappers.cpp:71: undefined reference to `llvm::ModulePass::~ModulePass()' /home/foad/llvm/objdir-mingw/tools/opt/Debug/AnalysisWrappers.o: In function `~ExternalFunctionsPassedConstants': /home/foad/svn/llvm-project/llvm/trunk/tools/opt/AnalysisWrappers.cpp:32: undefined reference to `llvm::ModulePass::~ModulePass()' /home/foad/svn/llvm-project/llvm/trunk/tools/opt/AnalysisWrappers.cpp:32: undefined reference to `llvm::ModulePass::~ModulePass()' /home/foad/llvm/objdir-mingw/tools/opt/Debug/AnalysisWrappers.o:AnalysisWrappers.cpp:(.debug_info+0x1ba6): undefined reference to `llvm::CallGraphLinkVar' ... The attached patch makes GenLibDeps.pl notice that nm has failed, so that the build fails immediately rather than giving more obscure errors later on. Thanks, Jay. -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.die Type: application/octet-stream Size: 892 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090417/6fc571e3/attachment.obj>
The next problem I have is: llvm[2]: Linking Debug executable opt /home/foad/llvm/objdir-mingw/Debug/lib/libLLVMSystem.a(DynamicLibrary.o):/home/foad/svn/llvm-project/llvm/trunk/lib/System/Win32/DynamicLibrary.inc:179: undefined reference to `___eprintf' collect2: ld returned 1 exit status I can work around this by removing the two references to __eprintf from lib/System/Win32/DynamicLibrary.inc, but... why are they there in the first place, and why don't I have __eprintf on my system? I see that these references were introduced here: http://llvm.org/viewvc/llvm-project?view=rev&revision=52037 but I don't understand what they are for. Do they let lli execute programs in which the compiler has hard-coded calls to __eprintf? Does that mean that __eprintf ought to be found in libgcc? Thanks, Jay.
Another observation: GettingStarted.html still gives these instructions for cross-compiling LLVM: 1. Configure and build LLVM as a native compiler. You will need just TableGen from that build. * If you have $LLVM_OBJ_ROOT=$LLVM_SRC_ROOT just execute make -C utils/TableGen after configuring. * Otherwise you will need to monitor building process and terminate it just after TableGen was built. 2. Copy the TableGen binary to somewhere safe (out of your build tree). 3. Configure LLVM to build with a cross-compiler. To do this, supply the configure script with --build and --host options that are different. The values of these options must be legal target triples that your GCC compiler supports. 4. Put the saved TableGen executable into the into $LLVM_OBJ_ROOT/{BUILD_TYPE}/bin directory (e.g. into .../Release/bin for a Release build). 5. Build LLVM as usual. ... but all this messing about with tblgen seems to be completely unnecessary now, presumably since this commit: http://llvm.org/viewvc/llvm-project?view=rev&revision=58981 Thanks, Jay.
> I can work around this by removing the two references to __eprintf > from lib/System/Win32/DynamicLibrary.inc, but... why are they there in > the first place, and why don't I have __eprintf on my system? > > I see that these references were introduced here: > > http://llvm.org/viewvc/llvm-project?view=rev&revision=52037 > > but I don't understand what they are for. Do they let lli execute > programs in which the compiler has hard-coded calls to __eprintf? Does > that mean that __eprintf ought to be found in libgcc?Does it perhaps relate to the old runtime/GCCLibraries/libgcc/eprintf.c, which was removed here: http://llvm.org/viewvc/llvm-project?view=rev&revision=41257 ? Thanks, Jay.
The next problem I have is: llvm[2]: Linking Debug executable llc /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/libstdc++.a(stubs.o):(.text+0x160): multiple definition of `_powf' /home/foad/llvm/objdir-mingw/Debug/lib/libLLVMCodeGen.a(RegAllocLinearScan.o):/usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/../../../../i586-mingw32msvc/include/math.h:576: first defined here collect2: ld returned 1 exit status math.h:576 says: __CRT_INLINE float __cdecl powf (float x, float y) {return (float) pow (x, y);} The definition of _powf in RegAllocLinearScan.o seems to be marked with some LINK_ONCE_DISCARD and COMDAT stuff, so I assume multiple such definitions shouldn't cause linker errors. I don't know what libstdc++'s stubs.o is for. If I create a bodged version of libstdc++ that doesn't include stubs.o, then llc links successfully! I've tried coming up with a small C++ app that gives the same linker error, but so far without success. Can anyone help? Thanks, Jay.
Jay Foad <jay.foad at gmail.com> writes:> Another observation: GettingStarted.html still gives these > instructions for cross-compiling LLVM:[snip]> ... but all this messing about with tblgen seems to be completely > unnecessary now, presumably since this commit: > > http://llvm.org/viewvc/llvm-project?view=rev&revision=58981The CMake build system also supports cross-compiling using the usual cmake process. Time ago, while testing the cmake build, I found the same problems as you. Anton indicated to me that there are issues with recent mingw support on debian. -- Oscar
Hello, Jay> The first problem I hit was when I configured with CC, CXX, AR and > RANLIB set to mingw cross-tools, but forgot to specify NM as well. > This resulted in a load of warnings that scrolled off the screen:Pretty strange I did not notice this problem before... Maybe because I have all-in-one binutils bult, which can recognize all variety of object formats. --- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University
Hello, Jay> The first problem I hit was when I configured with CC, CXX, AR and > RANLIB set to mingw cross-tools, but forgot to specify NM as well. > This resulted in a load of warnings that scrolled off the screen:Why don't just set normal --host/--build/--target options? It will pick the proper tools for you. --- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University
Hello, Jay> but I don't understand what they are for. Do they let lli execute > programs in which the compiler has hard-coded calls to __eprintf? Does > that mean that __eprintf ought to be found in libgcc?Yes. And I believe it was there, at least for "official mingw gcc", which is 3.4.5. Could you please investigate why you don't have this in your libgcc? Is it gcc v3 vs v4 issue? --- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University
Hello, Jay> I don't know what libstdc++'s stubs.o is for. If I create a bodged > version of libstdc++ that doesn't include stubs.o, then llc links > successfully! > > I've tried coming up with a small C++ app that gives the same linker > error, but so far without success.Sounds like broken compiler and/or mingw runtime. This perfectly explains, why mingw gcc 4.2.x is still considered as 'experimental'. What if you just try 3.4.6 instead? --- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University
On Apr 17, 2009, at 8:31 AM, Jay Foad wrote:> Another observation: GettingStarted.html still gives these > instructions for cross-compiling LLVM: > > 1. Configure and build LLVM as a native compiler. You will need > just TableGen from that build. > * If you have $LLVM_OBJ_ROOT=$LLVM_SRC_ROOT just execute > make -C utils/TableGen after configuring. > * Otherwise you will need to monitor building process and > terminate it just after TableGen was built. > 2. Copy the TableGen binary to somewhere safe (out of your build > tree). > 3. Configure LLVM to build with a cross-compiler. To do this, > supply the configure script with --build and --host options that are > different. The values of these options must be legal target triples > that your GCC compiler supports. > 4. Put the saved TableGen executable into the into > $LLVM_OBJ_ROOT/{BUILD_TYPE}/bin directory (e.g. into .../Release/bin > for a Release build). > 5. Build LLVM as usual. > > ... but all this messing about with tblgen seems to be completely > unnecessary now, presumably since this commit: > > http://llvm.org/viewvc/llvm-project?view=rev&revision=58981 >Quite right. Fixed. Thanks for pointing that out! -Jim
>> The first problem I hit was when I configured with CC, CXX, AR and >> RANLIB set to mingw cross-tools, but forgot to specify NM as well. >> This resulted in a load of warnings that scrolled off the screen: > Why don't just set normal --host/--build/--target options? It will > pick the proper tools for you.Good point - thanks! I was using --host=mingw32, and I didn't know that it would find the cross-tools automatically if I used --host=i586-mingw32msvc. Thanks, Jay.
> The attached patch makes GenLibDeps.pl notice that nm has failed, so > that the build fails immediately rather than giving more obscure > errors later on.Would you mind applying the patch? Thanks, Jay. -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.die Type: application/octet-stream Size: 892 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090420/41f08849/attachment.obj>
On Mon, Apr 20, 2009 at 3:32 AM, Jay Foad <jay.foad at gmail.com> wrote:>> The attached patch makes GenLibDeps.pl notice that nm has failed, so >> that the build fails immediately rather than giving more obscure >> errors later on. > > Would you mind applying the patch? >Sure. But could you add a message to the "die" commands? Something like: close DEFS or die "Could not close: $!"; ? -bw
I get: llvm[1]: Compiling Signals.cpp for Debug build In file included from /home/foad/svn/llvm-project/llvm/trunk/lib/System/Signals.cpp:33: /home/foad/svn/llvm-project/llvm/trunk/lib/System/Win32/Signals.inc: In function ‘LONG LLVMUnhandledExceptionFilter(_EXCEPTION_POINTERS*)’: /home/foad/svn/llvm-project/llvm/trunk/lib/System/Win32/Signals.inc:191: warning: format ‘%08X’ expects type ‘unsigned int’, but argument 3 has type ‘DWORD’ /home/foad/svn/llvm-project/llvm/trunk/lib/System/Win32/Signals.inc:195: warning: format ‘%08X’ expects type ‘unsigned int’, but argument 3 has type ‘DWORD’ /home/foad/svn/llvm-project/llvm/trunk/lib/System/Win32/Signals.inc:195: warning: format ‘%08X’ expects type ‘unsigned int’, but argument 4 has type ‘DWORD’ /home/foad/svn/llvm-project/llvm/trunk/lib/System/Win32/Signals.inc:195: warning: format ‘%08X’ expects type ‘unsigned int’, but argument 5 has type ‘DWORD’ /home/foad/svn/llvm-project/llvm/trunk/lib/System/Win32/Signals.inc:195: warning: format ‘%08X’ expects type ‘unsigned int’, but argument 6 has type ‘DWORD’ /home/foad/svn/llvm-project/llvm/trunk/lib/System/Win32/Signals.inc:218: warning: format ‘%04d’ expects type ‘int’, but argument 4 has type ‘DWORD’ /home/foad/svn/llvm-project/llvm/trunk/lib/System/Win32/Signals.inc:227: warning: format ‘%d’ expects type ‘int’, but argument 4 has type ‘DWORD’ /home/foad/svn/llvm-project/llvm/trunk/lib/System/Win32/Signals.inc:229: warning: format ‘%04d’ expects type ‘int’, but argument 3 has type ‘DWORD’ MinGW's <windef.h> and MSDN both agree that DWORD is a typedef for "unsigned long": http://msdn.microsoft.com/en-us/library/cc230318(PROT.10).aspx so here is a patch to fix these warnings by changing %d to %lu, etc. Thanks, Jay. -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.dword Type: application/octet-stream Size: 1508 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090421/8f065de8/attachment.obj>
Jay Foad wrote:> I'm trying to cross-compile LLVM with build=, host=target=. I'm using > the following packages from Debian lenny: > > mingw32 4.2.1.dfsg-1 > mingw32-binutils 2.18.50-20080109-1 > mingw32-runtime 3.13-1 > > The first problem I hit was when I configured with CC, CXX, AR and > RANLIB set to mingw cross-tools, but forgot to specify NM as well. > This resulted in a load of warnings that scrolled off the screen: > > nm: AliasAnalysis.o: File format not recognized > nm: AliasAnalysisCounter.o: File format not recognized > nm: AliasAnalysisEvaluator.o: File format not recognized > nm: AliasDebugger.o: File format not recognized > nm: AliasSetTracker.o: File format not recognized > nm: Analysis.o: File format not recognized > ... > > followed by millions of undefined symbols when linking any executable: > > llvm[2]: Linking Debug executable opt > /home/foad/llvm/objdir-mingw/tools/opt/Debug/AnalysisWrappers.o: In > function `~CallGraphPrinter': > /home/foad/svn/llvm-project/llvm/trunk/tools/opt/AnalysisWrappers.cpp:71: > undefined reference to `llvm::ModulePass::~ModulePass()' > /home/foad/svn/llvm-project/llvm/trunk/tools/opt/AnalysisWrappers.cpp:71: > undefined reference to `llvm::ModulePass::~ModulePass()' > /home/foad/llvm/objdir-mingw/tools/opt/Debug/AnalysisWrappers.o: In > function `~ExternalFunctionsPassedConstants': > /home/foad/svn/llvm-project/llvm/trunk/tools/opt/AnalysisWrappers.cpp:32: > undefined reference to `llvm::ModulePass::~ModulePass()' > /home/foad/svn/llvm-project/llvm/trunk/tools/opt/AnalysisWrappers.cpp:32: > undefined reference to `llvm::ModulePass::~ModulePass()' > /home/foad/llvm/objdir-mingw/tools/opt/Debug/AnalysisWrappers.o:AnalysisWrappers.cpp:(.debug_info+0x1ba6): > undefined reference to `llvm::CallGraphLinkVar' > ... > > The attached patch makes GenLibDeps.pl notice that nm has failed, so > that the build fails immediately rather than giving more obscure > errors later on. >I see (the hard way) that this patch also turns the fallback code for broken pipes on cmd.exe command shell into dead code (which breaks native MinGW build/ActivePerl ). That said, dying on totally absent nm makes sense. Attaching patch to retain die on absent nm while permitting the fallback code to run. Kenneth Boyd -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: GenLibDeps.pl.patch URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090428/2c9db298/attachment.ksh>