Hello everyone, I've run across a problem building LLVM 2.7 with Mingw on Win7. When I try make VERBOSE=1, it churns away happily for a while and then produces: /c/Perl/bin/perl /c/Programs32/llvm-2.7/utils/GenLibDeps.pl -flat /c/Programs 32/llvm-2.7/obj/Release/lib "/mingw/bin/nm" > /c/Programs32/llvm-2.7/obj/tools/ llvm-config/LibDeps.txt.tmp 'c:' is not recognized as an internal or external command, operable program or batch file. nm failed at c:/Programs32/llvm-2.7/utils/GenLibDeps.pl line 232. Out of curiousity, I added to the GenLibDeps.pl error message, and discovered that it thought nm was failing on c:/Programs32/llvm-2.7/obj/Release/lib/libLLVMARMAsmParser.a However, I can't manage to reproduce the failure by hand: /mingw/bin/nm c:/Programs32/llvm-2.7/obj/Release/lib/libLLVMARMAsmParser.a | sed -e 's/^[ 0]* U //' | sort | uniq produces sensible looking output, and /mingw/bin/nm c:/Programs32/llvm-2.7/obj/Release/lib/libLLVMARMAsmParser.a | sed -e 's/^[ 0]* U //' | sort | uniq | grep "c:" finds nothing. I'm not much of a Perl and/or Makefile hacker, so I'm not sure where to go next. Has anyone seen this before?
On 6/22/2010 2:47 PM, J. Garrett Morris wrote:> Hello everyone, > > I've run across a problem building LLVM 2.7 with Mingw on Win7. When > I try make VERBOSE=1, it churns away happily for a while and then > produces: > > /c/Perl/bin/perl /c/Programs32/llvm-2.7/utils/GenLibDeps.pl -flat /c/Programs > 32/llvm-2.7/obj/Release/lib "/mingw/bin/nm"> /c/Programs32/llvm-2.7/obj/tools/ > llvm-config/LibDeps.txt.tmp > 'c:' is not recognized as an internal or external command, operable > program or batch file. > nm failed at c:/Programs32/llvm-2.7/utils/GenLibDeps.pl line 232. >Which Perl are you using? * The stock LLVM/configure build process requires the binary Perl distribution from the MingW project, which uses sh as the command shell. * Windows-native Perls use cmd.exe (on Win7, at least) so will fail, with this exact error message, without counter-measures. (I'll have to repull SVN to see what the current required patches are; they're not that difficult.) Note that if you build Perl from official source with MingW, with default options, you'll end up with cmd.exe as the command shell.> However, I can't manage to reproduce the failure by hand: > > /mingw/bin/nm c:/Programs32/llvm-2.7/obj/Release/lib/libLLVMARMAsmParser.a | > sed -e 's/^[ 0]* U //' | sort | uniq > > produces sensible looking output, and >I presume that command line was in sh. It'll die in cmd.exe with the error message you see. (It doesn't help that it's very likely it'll find Win7 sort rather than the POSIX-y MingW sort in cmd.exe .) Kenneth
J. Garrett Morris <jgmorris at cs.pdx.edu> wrote:> Hello everyone, > > I've run across a problem building LLVM 2.7 with Mingw on Win7. When > I try make VERBOSE=1, it churns away happily for a while and then > produces: > > /c/Perl/bin/perl /c/Programs32/llvm-2.7/utils/GenLibDeps.pl-flat /c/Programs32/llvm-2.7/obj/Release/lib "/mingw/bin/nm" /c/Programs32/llvm-2.7/obj/tools/llvm-config/LibDeps.txt.tmp> 'c:' is not recognized as an internal or external command, operable > program or batch file. > nm failed at c:/Programs32/llvm-2.7/utils/GenLibDeps.pl line 232. > > Out of curiousity, I added to the GenLibDeps.pl error message, and > discovered that it thought nm was failing on > > c:/Programs32/llvm-2.7/obj/Release/lib/libLLVMARMAsmParser.a > > However, I can't manage to reproduce the failure by hand: > > /mingw/bin/nm > c:/Programs32/llvm-2.7/obj/Release/lib/libLLVMARMAsmParser.a | > sed -e 's/^[ 0]* U //' | sort | uniq > > produces sensible looking output, and > > /mingw/bin/nm > c:/Programs32/llvm-2.7/obj/Release/lib/libLLVMARMAsmParser.a | > sed -e 's/^[ 0]* U //' | sort | uniq | grep "c:" > > finds nothing. I'm not much of a Perl and/or Makefile hacker, so I'm > not sure where to go next. Has anyone seen this before?I've seen this -- I think. The problem is that somewhere, maybe it was in GenLibDeps.pl, there are sed substitutions that use ':' as the separator -- so, when a path is encountered that includes the 'c:' prefix, it chokes. Not knowing where that absolute path was coming from, I hacked around it by searching $(LLVM_ROOT)/Makefile.config and changing paths to the '/c/...' form. Using CMake, instead of ./configure, seems to be a bit less error-prone, at least for me. Kevin Kelley
On Tue, Jun 22, 2010 at 2:29 PM, Kenneth Boyd <zaimoni at zaimoni.com> wrote:> Which Perl are you using? > * The stock LLVM/configure build process requires the binary Perl > distribution from the MingW project, which uses sh as the command shell.This was my problem. Thanks to all of you who responded! /g