This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
How to reproduce: 1. Tools > Options > C/C++ > Build Tools > Build Host > Edit 2. Add > (select host) > Next 3. Login > (enter login) > SSH Key File > (enter SSH key file) > Next 4. Default Tool Collection: GNU > Access Project files via: System level file sharing > Finish 5. Host now appears in the Build Hosts Manager. > OK 6. In Build Tools > Build Host > select new host -> Base Directory displays /usr/bin correctly -> All the other paths (C Compiler, C++ Compiler) are correct but red! When I press ... next to "C Compiler" (for example) the file chooser opens and displays the correct directory: /usr/bin and the directory contains the correct file: gcc. When I select the file, nothing changes and the path is still red. When I try to build my project (Shift + 11), "Resolve Missing Native Build Tools" pops up. My setup has worked for a long time. It still works with Netbeans 7.3, so I had to revert to 7.3.
It seems host is off-line. Does tools panel has warning in bottom like: Host xxx@xxx is not connected...
No, it does not. Also I have explicitly connected to my host using Services > C/C++ Build Hosts > (right-click host) > Connect and it is displayed as green. Still same symptom.
Is bug reproduced with clean user dir?
Can you specify which user dir you mean? Are you talking about C:\Users\xxx\AppData\Local\NetBeans\Cache\7.4beta?
Never mind. I found the user dir at C:\Users\xxx\AppData\Roaming\NetBeans\dev. I uninstalled Netbeans (which removed the abovementioned directory), then I re-installed Netbeans freshly. Same symptoms.
(In reply to Sebastian.Meier from comment #4) > Can you specify which user dir you mean? Are you talking about > C:\Users\xxx\AppData\Local\NetBeans\Cache\7.4beta? To start IDE with clean user dir: #./netbeans --userdir /tmp/newfolder
Please check output and exit code of command on remote host: #/usr/bin/test -x path where path is a absolute path to compiler
waiting for user response
> Please check output and exit code of command on remote host: > #/usr/bin/test -x path > where path is a absolute path to compiler I don't have /usr/bin/test on FreeBSD but: [root@pc124]# whereis gcc gcc: /usr/bin/gcc /usr/share/man/en.ISO8859-1/man1/gcc.1.gz /usr/ports/lang/gcc [root@pc124]# /usr/bin/gcc --help Usage: gcc [options] file... ... The exact same machine is working fine for 7.3 (and has been working since 6.9).
Workaround: create link to test in /usr/bin: #cd /usr/bin #ln -s /bin/test test
Andrew, probably hard coded path of "test" is not valid for some platforms. See method: RemoteServerList.isValidExecutable(ExecutionEnvironment env, String path) .... int exit_status = RemoteCommandSupport.run(env, "/usr/bin/test", "-x", path);
see also: RemoteHostInfoProviderFactory.RemoteHostInfo.fileExists()
(In reply to Alexander Simon from comment #10) > Workaround: > create link to test in /usr/bin: > #cd /usr/bin > #ln -s /bin/test test Ah, ok, I see what you mean now. /usr/bin/test is called by Netbeans. I created the symbolic link as you described above and the problem is gone.
fixed in cnd-main http://hg.netbeans.org/cnd-main/rev/cf4c4d623168
Integrated into 'releases/release74', will be available in build *201311111738* or newer. Wait for official and publicly available build. Changeset: http://hg.netbeans.org/releases/rev/7900a836a7c8 User: Vladimir Kvashin <vkvashin@netbeans.org> Log: fixed #235217 - Remote toolchain not detected correctly (transplanted from ad8a1765767701ec2cb28f481b40385277c1ffa8)
verified in NetBeans IDE 7.4 (Build 201311111738)