mingw build problems

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.

Sure. But could you add a message to the "die" commands? Something like:

close DEFS or die "Could not close: $!";

?

The "or die" is intended to catch the case where nm returned a
non-zero exit status, so nm will already have printed some error
messages. $! doesn't appear to have a useful value at this point. How
about the attached, which gives:

$ GenLibDeps.pl -flat lib
/usr/local/bin/nm: lib/libLLVMfoo.a: File format not recognized
nm failed at /home/foad/svn/llvm-project/llvm/trunk/utils/GenLibDeps.pl line 69

?

Thanks,
Jay.

patch.die2 (922 Bytes)

> Anyway, I'd vote for removing all references to __eprintf from
> lib/System/Win32/DynamicLibrary.inc.
Agree. Julien, what do you think?

That's fine with me. I'll test it once the change is made.

Here's the patch. I can't commit it myself.

Thanks,
Jay.

patch.eprintf (755 Bytes)

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":

so here is a patch to fix these warnings by changing %d to %lu, etc.

Thanks,
Jay.

patch.dword (1.47 KB)

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'.

I came up with a small test case and reported this bug to the Debian
package maintainers here:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=525016

Thanks,
Jay.

Hello, Jay

>> > Anyway, I'd vote for removing all references to __eprintf from
>> > lib/System/Win32/DynamicLibrary.inc.
>> Agree. Julien, what do you think?
>
> That's fine with me. I'll test it once the change is made.

Here's the patch. I can't commit it myself.

Your patches applied. Thanks!

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'.

I came up with a small test case and reported this bug to the Debian
package maintainers here:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=525016

I've been using an ugly makefile hack (attached) to work around this
bug when cross-compiling for MinGW.

Jay.

patch.muldefs (616 Bytes)

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

GenLibDeps.pl.patch (602 Bytes)

Hi, Jay

> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=525016

I've been using an ugly makefile hack (attached) to work around this
bug when cross-compiling for MinGW.

Sounds like a proper workaround since we cannot assume that fixes from
mainline gcc will ever be backported to "stable" versions.

Applied, thanks!