Bugzilla – Full Text Bug Listing
| Summary: | Eclipse PATH environment variable in 64-bit on Win7 not working | ||
|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Loaden <loaden> |
| Component: | cdt-build | Assignee: | cdt-build-inbox <cdt-build-inbox> |
| Status: | CLOSED DUPLICATE | QA Contact: | Doug Schaefer <cdtdoug> |
| Severity: | normal | ||
| Priority: | P3 | CC: | aleherb+eclipse, cdtdoug, jamesblackburn+eclipse, loaden |
| Version: | 7.0.1 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
Loaden
Moving to Debug for comment. Not sure if this is CDT specific? Moving to cdt, we have our own spawner. How exactly do you set your path in eclipse? Is it "c:\mingw\bin;$PATH"? (In reply to comment #3) > How exactly do you set your path in eclipse? Is it "c:\mingw\bin;$PATH"? My environment setting is: ---- C/C++ > Build > Environment PATH=${eclipse_home}/bin INCLUDE=${eclipse_home}/include LIB=${eclipse_home}/lib ---- I am using CMake for build, the error log: (Cannot run program "cmake" (in directory "D:\DengYC\LoveDEV\share\workspace\TestGUI"): CreateProcess error=2, ?????????) Then I am created a BAT file, here is the content: @echo off set PATH=%CD%\bin;%PATH% set INCLUDE=%CD%\include set LIB=%CD%\lib start eclipse.exe If start eclipse by the BAT file, then all works fine! And, this issue only happens in 64-bit Win7, In x86 win7 and with the same configure, there not have this issue. One of the issues that could be there is that ${eclipse_home} ends with a backslash. So you end with something like "eclipse\path\/bin".
I'd suggest to use recent CDT 8 build from http://download.eclipse.org/tools/cdt/builds/ to troubleshoot path issues. It prints the path in the console if make not found.
I think this is a dup of bug 236330. There is no spawner for x86_64, therefore Runtime.exec is used which does not search for the executable in the provided environment, but only in the current process env. (In reply to comment #5) > One of the issues that could be there is that ${eclipse_home} ends with a > backslash. So you end with something like "eclipse\path\/bin". > I'd suggest to use recent CDT 8 build from > http://download.eclipse.org/tools/cdt/builds/ to troubleshoot path issues. It > prints the path in the console if make not found. I don't think this is backslash question. Because if I changed the value to "${eclipse_home}bin", It still won't work. I will try CDT 8 late and will feedback here. (In reply to comment #7) > (In reply to comment #5) > > One of the issues that could be there is that ${eclipse_home} ends with a > > backslash. So you end with something like "eclipse\path\/bin". > > I'd suggest to use recent CDT 8 build from > > http://download.eclipse.org/tools/cdt/builds/ to troubleshoot path issues. It > > prints the path in the console if make not found. > I don't think this is backslash question. > Because if I changed the value to "${eclipse_home}bin", It still won't work. > I will try CDT 8 late and will feedback here. Here is CDT 8.0 test log, I am using VC Compiler now. ---- **** Rebuild of configuration Debug for project test **** **** Internal Builder is used for build **** cl /c /EHs /MD /Zi /nologo /Fo:main.obj ..\main.cpp Error: Cannot run program "cl" (in directory "D:\DengYC\LoveDEV\workspace\test\Debug"): CreateProcess error=2, ????????? Build error occurred, build is stopped Time consumed: 31 ms. ----- It's can't run "cl", The meaning is CDT can't find the PATH of cl. After add the VC's bin directory to system PATH. Now the log like this: **** Internal Builder is used for build **** cl /c /EHs /MD /Zi /ID:\DengYC\LoveDEV\include /nologo /Fo:main.obj ..\main.cpp main.cpp link /debug /nologo /OUT:good.exe main.obj LINK : fatal error LNK1181: cannot open input file 'main.obj' Build error occurred, build is stopped Time consumed: 656 ms. CDT can't build too, but we can sure CDT can find the cl.exe now. (In reply to comment #6) > I think this is a dup of bug 236330. There is no spawner for x86_64, therefore > Runtime.exec is used which does not search for the executable in the provided > environment, but only in the current process env. I am now sure this is dup issue. But if using x86, works well with the SAME setting. *** This bug has been marked as a duplicate of bug 236330 *** Hi, CDT Term! I found a new information, If I use "cmd /C cmake .." command, It should works well!! |