llvm dev - Apr 2009 - [LLVMdev] mingw build problems

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=58981
The 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>