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?
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
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
This was my problem. Thanks to all of you who responded!
/g