Bug 228730 - java 7 update 21 breaks build in NetBeans 7.3, 7.2, ...
java 7 update 21 breaks build in NetBeans 7.3, 7.2, ...
Status: RESOLVED INCOMPLETE
Product: cnd
Classification: Unclassified
Component: -- Other --
7.3
PC Windows 8
: P4 (vote)
: 8.0
Assigned To: ilia
issues@cnd
73patch2-verified
:
: 227868 228976 229620 230140 230352 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-04-18 22:08 UTC by soldatov
Modified: 2014-03-06 04:37 UTC (History)
11 users (show)

See Also:
Issue Type: DEFECT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description soldatov 2013-04-18 22:08:31 UTC
Start NetBeans with java 7 update 17 and clean&build Welcome:
"/usr/bin/make" -f nbproject/Makefile-Debug.mk QMAKE= SUBPROJECTS= .clean-conf
.......
CLEAN SUCCESSFUL (total time: 2s)

"/usr/bin/make" -f nbproject/Makefile-Debug.mk QMAKE= SUBPROJECTS= .build-conf
............
BUILD SUCCESSFUL (total time: 3s)


Start NetBeans with java 7 update 21 and clean&build Welcome:

"/c/Users/valera/Documents/NetBeansProjects/Welcome_1/"D:/MinGW/msys/1.0/bin/make.exe"" -f nbproject/Makefile-Debug.mk QMAKE= SUBPROJECTS= .clean-conf
/bin/sh: /c/Users/valera/Documents/NetBeansProjects/Welcome_1/D:/MinGW/msys/1.0/bin/make.exe: No such file or directory
make.exe": *** [.clean-impl] Error 127


CLEAN FAILED (exit value 2, total time: 1s)
Comment 1 soldatov 2013-04-18 22:14:06 UTC
http://www.oracle.com/technetwork/java/javase/7u21-relnotes-1932873.html#jruntime

Changes to Runtime.exec

On Windows platform, the decoding of command strings specified to Runtime.exec(String), Runtime.exec(String,String[]) and Runtime.exec(String,String[],File) methods, has been improved to follow the specification more closely. This may cause problems for applications that are using one or more of these methods with commands that contain spaces in the program name, or are invoking these methods with commands that are not quoted correctly.

For example, Runtime.getRuntime().exec("C:\\My Programs\\foo.exe bar") is an attempt to launch the program "C:\\My" with the arguments "Programs\\foo.exe" and "bar". This command is likely to fail with an exception to indicate "C:\My" cannot be found.

The example Runtime.getRuntime().exec("\"C:\\My Programs\\foo.exe\" bar") is an attempt to launch the program "\"C:\\My". This command will fail with an exception to indicate the program has an embedded quote.

Applications that need to launch programs with spaces in the program name should consider using the variants of Runtime.exec that allow the command and arguments to be specified in an array.

Alternatively, the preferred way to create operating systems processes since JDK 5.0 is using java.lang.ProcessBuilder. The ProcessBuilder class has a much more complete API for setting the environment, working directory and redirecting streams for the process.
Comment 2 RoestVrijStaal 2013-04-23 14:54:43 UTC
I could confirm that this bug also exist on Java 6u45:

====
"/path/to/my/project/"C:/MinGW/msys/1.0/bin/make.exe"" -f nbproject/Makefile-Debug.mk QMAKE= SUBPROJECTS= .clean-conf
/bin/sh: /path/to/my/project/C:/MinGW/msys/1.0/bin/make.exe: No such file or directory
make.exe": *** [.clean-impl] Error 127


CLEAN FAILED (exit value 2, total time: 651ms)
====
It would be smarter of Oracle to inform and tutor other companies & programmers beforehand to use ProcessBuilder instead of blatantly remove older ways of functionality in new updates and let others enjoy the annoying surprise.
Comment 3 Andrew Krasny 2013-04-23 20:12:28 UTC
This *could* be that mentioned change in java triggered this behavior, but this is something in between java and MinGW. 

As far as I know, this bug is reproducible with mingw only.

As a workaround one can set make command (in toolchain configuration) to "make.exe" (instead of "c:/msys/1.0/bin/make.exe").
 
Also Path environment variable should be set like:
Path=c:\msys\1.0\bin;c:\MinGW\bin
before starting nb...
Comment 4 Andrew Krasny 2013-04-23 20:51:23 UTC
What I see now is that when java invokes a process it encloses executable in quotes (introduced u21?). Maybe this is a normal case on Windows. But looks like this makes msys's make.exe to fail. There is no problem with starting make, but unfortunately generated makefiles uses recursive make invocation. So when make tries to start another instance of make (from within the makefile) it expects (I think so) to find msys-style paths (/c/msys/1.0/bin/make) in it's args[0]. As a fallback it can work with c:\msys\1.0\bin\make.exe, but fails to do so with "c:\msys\1.0\bin\make.exe". As a result it tries to join working directory with args[0] and exec this and... fails.

Simple experiment that demonstrates this from cmd.exe (without NB):

1) No quotes => works fine:
C:\Documents and Settings\Andrew\Мои документы\NetBeansProjects\Welcome_1>c:\msys\1.0\bin\make.exe -f Makefile clean
/bin/make -f nbproject/Makefile-Debug.mk QMAKE= SUBPROJECTS= .clean-conf
make[1]: Entering directory `/c/Documents and Settings/Andrew/Мои документы/NetBeansProjects/Welcome_1'
rm -f -r build/Debug
rm -f dist/Debug/MinGW-Windows/welcome_1.exe
make[1]: Leaving directory `/c/Documents and Settings/Andrew/Мои документы/NetBeansProjects/Welcome_1'

C:\Documents and Settings\Andrew\Мои документы\NetBeansProjects\Welcome_1>


2) Fails with quotes:
C:\Documents and Settings\Andrew\Мои документы\NetBeansProjects\Welcome_1>"c:\msys\1.0\bin\make.exe" -f Makefile clean
/c/Documents and Settings/Andrew/Мои документы/NetBeansProjects/Welcome_1/"c:/msys/1.0/bin/make.exe" -f nbproject/Makefile-Debug.mk QMAKE= SUBPROJECTS= .clean-conf
/bin/sh: /c/Documents: No such file or directory
make.exe": *** [.clean-impl] Error 127

C:\Documents and Settings\Andrew\Мои документы\NetBeansProjects\Welcome_1>



3) As a 'workaround' MAKE variable can be set:

C:\Documents and Settings\Andrew\Мои документы\NetBeansProjects\Welcome_1>set MAKE=/c/msys/1.0/bin/make

C:\Documents and Settings\Andrew\Мои документы\NetBeansProjects\Welcome_1>"c:\msys\1.0\bin\make.exe" -f Makefile clean
/c/msys/1.0/bin/make -f nbproject/Makefile-Debug.mk QMAKE= SUBPROJECTS= .clean-conf
make[1]: Entering directory `/c/Documents and Settings/Andrew/Мои документы/NetBeansProjects/Welcome_1'
rm -f -r build/Debug
rm -f dist/Debug/MinGW-Windows/welcome_1.exe
make[1]: Leaving directory `/c/Documents and Settings/Andrew/Мои документы/NetBeansProjects/Welcome_1'

C:\Documents and Settings\Andrew\Мои документы\NetBeansProjects\Welcome_1>
Comment 5 Andrew Krasny 2013-04-23 21:42:58 UTC
http://hg.netbeans.org/cnd-main/rev/890dceeffc85
Comment 6 Quality Engineering 2013-04-25 02:18:22 UTC
Integrated into 'main-golden', will be available in build *201304242301* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/890dceeffc85
User: Andrew Krasny <akrasny@netbeans.org>
Log: Bug #228730 - java 7 update 21 breaks build in NetBeans 7.3, 7.2, ...
Comment 7 Alexander Pepin 2013-04-25 12:23:49 UTC
Nominated for 7.3 patch2
Comment 8 soldatov 2013-04-25 16:24:00 UTC
*** Bug 228976 has been marked as a duplicate of this bug. ***
Comment 9 Alexander Pepin 2013-04-29 15:18:41 UTC
Verified in build 20130428. Please push into 7.3.1 branch.
Comment 10 Alexander Pepin 2013-04-30 15:58:01 UTC
Pushed into 7.3 release
Comment 11 soldatov 2013-05-14 09:27:36 UTC
By default NetBeans creates 4 toolchains: Cygwin, Cygwin_4.x, MinGW and MinGW_TDM.

Cygwin and Cygwin_4.x works nicely before and after fix
MinGW works nicely after fix
MinGW_TDM fails in both cases (MinGW_TDM is equal to MinGW)
Comment 12 soldatov 2013-05-14 10:31:55 UTC
In NetBeans 7.3 patch 2 I can't create new project via "C/C++ Project with Existing Sources" wizard (small Qt sample - calculator)
Comment 13 soldatov 2013-05-15 10:19:29 UTC
(In reply to comment #12)
> In NetBeans 7.3 patch 2 I can't create new project via "C/C++ Project with
> Existing Sources" wizard (small Qt sample - calculator)
Workaround:
 replace C:/MinGW/msys/1.0/bin/make.exe on make.exe in Tools|Options
 remove cygwin (if cygwin exist, then NetBeans will use cygwin's make in any case)
Comment 14 soldatov 2013-05-15 14:13:23 UTC
Verified in NetBeans 7.3 patch 2
Comment 15 Quality Engineering 2013-05-17 09:53:57 UTC
Integrated into 'main-golden', will be available in build *201305170640* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/2ff0794e14c5
User: Andrew Krasny <akrasny@netbeans.org>
Log: Addfix for Bug #228730 (See comment #11)
Comment 16 Alexander Pepin 2013-05-20 09:54:36 UTC
Additional fix is verified in trunk. MinGW_TDM is now working correctly.
Comment 17 Andrew Krasny 2013-05-20 12:22:47 UTC
*** Bug 227868 has been marked as a duplicate of this bug. ***
Comment 18 soldatov 2013-05-23 08:05:55 UTC
*** Bug 230140 has been marked as a duplicate of this bug. ***
Comment 19 Egor Ushakov 2013-05-23 12:22:31 UTC
*** Bug 229620 has been marked as a duplicate of this bug. ***
Comment 20 Andrew Krasny 2013-06-19 18:30:28 UTC
*** Bug 230352 has been marked as a duplicate of this bug. ***
Comment 21 cogman 2013-08-31 10:02:54 UTC
This issue still seems to exist. I've tested it on JRE 7-u25 with netbeans 7.4beta, 7.3.1, and Dev 201308310001 Using Mingw-64 gcc 4.8.1 rev 5

"Makefile:115: recipe for target 'all' failed
process_begin: CreateProcess(NULL, /C/MingW64/mingw64/bin/make.exe -f CMakeFiles\Makefile2 all, ...) failed.
make (e=2): The system cannot find the file specified.

make: *** [all] Error 2


BUILD FAILED (exit value 2, total time: 57ms)"
Comment 22 cogman 2013-08-31 10:07:51 UTC
It should be noted that I don't have mysys installed, I do have cygwin installed, and make is not in my path variable.

I can work around this by dumping my mingw version of make into the path and then just setting my make path to just "make.exe" but that is a bit annoying.
Comment 23 MackSix 2013-08-31 11:16:38 UTC
(In reply to cogman from comment #22)
> It should be noted that I don't have mysys installed, I do have cygwin
> installed, and make is not in my path variable.
> 
> I can work around this by dumping my mingw version of make into the path and
> then just setting my make path to just "make.exe" but that is a bit annoying.

Make may work right unless it is in the environment path variable, it is a requirement.
Comment 24 MackSix 2013-08-31 11:17:55 UTC
(In reply to MackSix from comment #23)
> (In reply to cogman from comment #22)
> > It should be noted that I don't have mysys installed, I do have cygwin
> > installed, and make is not in my path variable.
> > 
> > I can work around this by dumping my mingw version of make into the path and
> > then just setting my make path to just "make.exe" but that is a bit annoying.
> 
> Make may work right unless it is in the environment path variable, it is a
> requirement.

I mean to say, it may _not_ work right.
Comment 25 Andrew Krasny 2013-09-02 11:42:30 UTC
cogman,

this is not supported configuration. Please either install cygwin and use cygwin gcc/make or install mingw+msys and use make from msys..

I agree, that this is an issue and maybe it will be addressed, but not in this release.

=Andrew
Comment 26 jogshy 2013-09-02 15:43:08 UTC
I have installed JRE 1.7u25 and Netbeans 7.3.1 and MinGW64/MSYS.
This error still persists:

/bin/sh: /d/kaka/CppDynamicLibrary_1/D:/MSYS/bin/make.exe: No such file or directory
"/d/kaka/CppDynamicLibrary_1/"D:/MSYS/bin/make.exe"" -f nbproject/Makefile-Debug.mk QMAKE= SUBPROJECTS= .clean-conf
make.exe": *** [.clean-impl] Error 127


CLEAN FAILED (exit value 2, total time: 201ms)

For some reason chains the project's dir with the MSYS's make dir.
Pls, fix it.
Comment 27 Andrew Krasny 2013-09-02 16:49:00 UTC
jogshy, 

have you tried proposed workarounds (comments 3,4,13)?
Could you, please, try with the latest dev build?
Comment 28 ilia 2014-01-10 08:05:30 UTC
Waiting for user response.
Comment 29 pabristow 2014-02-20 10:36:04 UTC
I have the same problem - but ONLY WITH VCC4N  (OK with Mingw)

I have Java update 51 (current)windows 8 32 bit.  

c:\msys\1.0\bin.exe exists ;c:\MinGW\bin  (and no cygwin)

PATH

C:\Windows\System32>set path
Path=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v
1.0\;C:\Program Files\TortoiseSVN\bin;C:\Program Files\TortoiseGit\bin;C:\Program Files\Windows Kits
\8.0\Windows Performance Toolkit\;C:\Program Files\Microsoft SQL Server\110\Tools\Binn\;C:\Program f
iles\boost\;C:\Program Files\Common Files\Acronis\SnapAPI\;c:\msys\1.0\bin;c:\MinGW\bin
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC

mingw

"/C/msys/bin/make.exe" -f nbproject/Makefile-Debug.mk QMAKE= SUBPROJECTS= .build-conf
make.exe[1]: Entering directory `/d/Documents/NetBeansProjects/Welcome_1'

VCC4n

"/d/Documents/NetBeansProjects/Welcome_1/"C:/msys/bin/make.exe"" -f nbproject/Makefile-Debug.mk QMAKE= SUBPROJECTS= .build-conf
/bin/sh: /d/Documents/NetBeansProjects/Welcome_1/C:/msys/bin/make.exe: No such file or directory
make.exe": *** [.build-impl] Error 127

Base directory 

C:\MinGW\bin

C:\Users\Paul\AppData\Roaming\NetBeans\VCC4N_0.3.3_beta\tools

Both have the expected c:/msys/bin/make.exe as make tool (entering just make.exe is not allowed).

Both show the expected C++ compiler:

C:\MinGW\bin\g++.exe
C:\Users\Paul\AppData\Roaming\NetBeans\VCC4N_0.3.3_beta\tools\msvc_caller.exe

Versions show the expected Make Tool GNU Make 3.81 for both (and the expected compilers).

NetBeans 7.3 and 8 beta show this fatal problem.
Comment 30 MackSix 2014-02-20 12:58:36 UTC
> 
> Both have the expected c:/msys/bin/make.exe as make tool (entering just
> make.exe is not allowed).
> 

If your path is actually c:/msys/1.0/bin/make.exe then why do you have c:/msys/bin/make.exe in your NetBeans tool chain?
Comment 31 pabristow 2014-02-25 14:55:38 UTC
Corrected PATH and now is referring to c:\msys\bin\

and also tried changed version of GNU make with varying results.

This problem has disappeared, but another remains, again for VCC4N which is not finding
msvc_caller.conf which I have raised on sourceforge VCC4N wiki.

I am confused (especially with 3 machines, 3 OS, 3 version of Netbeans, 3 version of make, 3 version of Java : 1 working and 2 not working), but ...

Why did it work OK for MinGW, but failed to find make.exe correctly for VCC4N?

What is 'correct' version of make?

What is search path for make?

As a Microsofty what, where and why is a *nix "/usr/bin/make"?

But Thanks.
Comment 32 Robin-Whittle 2014-02-26 10:55:02 UTC
I spent many hours trying to get NB C/C++ 8.0 Beta to recognize a make program:

  http://forums.netbeans.org/viewtopic.php?p=155011

Even if there is no impediments as noted in this bug to NB recognizing and using make.exe, I understand that there are only some versions which are suitable.  So it can be a challenge finding an installer for MinGW or whatever which has a suitable make.exe.  These always install a whole set of other programs, but perhaps the user already has the compiler, debugger and library of their choice already installed, and just wants a make.exe which NB will work with.  These installers may dynamically choose which software to install, so a particular installer, typically identified in instructions by its URL, might produce good results one month and not the next.

Installers may or may not alter the Windows PATH environment variable.  These make.exe programs evidently need some DLLs, so there are path questions about where they are located too, with potential trouble if another DLL of the same name is on the PATH but is incompatible.

Perhaps a workaround to these problems, changing JVM behavior and quoting difficulties would be to create a make.exe program using NB-compatible source code as a single executable without any DLLs, and to patch a few lines of the source code to cope with argv[0] being quoted or not.  This make.exe could be placed in any location at all.  As far as I know, make.exe doesn't need to be compatible with any other build tools and there's no need for it to be 64 bits.  All it needs to do is satisfy NB's requirements, at least on a Windows system.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo