Ticket #114 (closed bug: fixed)

Opened 6 years ago

Last modified 4 years ago

Win32 build failure due to incorrect `make` detection

Reported by: bjoern Owned by: coke
Priority: normal Milestone:
Component: build Version:
Severity: medium Keywords:
Cc: Language:
Patch status: Platform: win32

Description

Trying to build parrot on a Win32 system with both Visual Studio.NET 2003 and MinGW installed fails for me (both mingw32-make and nmake are in the path)

... mingw32-make: Entering directory `c:/.../parrot-0.8.2/compilers/pge' c:\Perl\bin\perl.exe -MExtUtils::Command -e rm_f PGE.pbc ..\..\runtime\parrot\library\PGE.pbc c:\Perl\bin\perl.exe -e "" >PGE\builtins_gen.pir /usr/bin/sh: c:Perlbinperl.exe: command not found mingw32-make: *** [PGE.pbc] Error 127 mingw32-make: Leaving directory `c:/.../parrot-0.8.2/compilers/pge' NMAKE : fatal error U1077: 'mingw32-make' : return code '0x2' Stop. ...

Presumably this is caused by unescaped backslashes in the Perl path. I had to manually set MAKE=nmake to make it build. Parrot should not use mingw32-make when using the Visual C++ compiler.

Change History

Changed 6 years ago by rblasch

  • owner set to rblasch
  • platform set to win32
  • status changed from new to assigned

Strange, I have both VC and MinGW as well, and don't have any problems with the mixed execution. What puzzles me is the "/usr/bin/sh" part. Seems like for some reason "sh" is used to execute the command for your, instead of "cmd", which of course has a different opinion about backslashes.

But I agree that if VC is used as a compiler, nmake should be preferred. This should be fixed in the next release.

Changed 6 years ago by rurban

Cannot reproduce. Maybe a make realclean was missing? /usr/bin/sh must not be there

Changed 5 years ago by jkeenan

  • component changed from none to build

Changed 5 years ago by coke

bjoern, is this still an issue for you? Followup commenters were unable to reproduce your issue.

Changed 4 years ago by coke

  • status changed from assigned to new
  • owner changed from rblasch to coke

Changed 4 years ago by coke

  • status changed from new to assigned

Changed 4 years ago by coke

  • status changed from assigned to closed
  • resolution set to fixed

Marking as resolved; haven't heard any complaints, rurban++ marked it as fixed back in r34976, but that was before trac2email was setup, so it's only on the mailing list.

We're moving towards a LCD makefile, so hopefully these sorts of issues will be less likely to occur in the future even if someone does use the "wrong" make.

Note: See TracTickets for help on using tickets.