1

I managed to set up remote development on RPi with Netbeans 8.0.2 over direct connection to my laptop. my simple program compiled, run and debugged.

#include <iostream>
using namespace std;

int main() {
    cout<<"hello Raspberry Pi";
    int e=8;//to see something in variables view
    return 0;
}

I was satisfied with the result, but default RPi compiler is quite old (version 4.6.3) and does not support C++ 11, so I upgraded gcc and g++ to 4.8.2 and changed the links in /usr/bin. That solved the problem with -std=c++11 not being recognized.

But then another problem arose: while it the code still compiles and runs normally, it can no more be properly debugged: stepping through the code does not work, the debugger goes to disassembly instead, the breakpoint is ignored and the variables view is empty. May be I need to upgrade anything else? here is output of Netbeans build

Copying project files to /home/netbeans/.netbeans/remote/192.1.2.200/andrey-laptop-Windows-x86_64 at netbeans@192.1.2.200
Building project files list...
Checking directory structure...
Checking previously uploaded files...
Checking links...
Uploading changed files:
    Zipping 1 changed files...
    Uploading zip to netbeans@192.1.2.200...
    Unzipping changed files...
Checking exec permissions...
Uploading changed files finished successfully.

"/usr/bin/make" -f nbproject/Makefile-Debug.mk QMAKE= SUBPROJECTS= .build-conf
make[1]: Entering directory '/home/netbeans/.netbeans/remote/192.1.2.200/andrey-laptop-Windows-x86_64/C/Doc/NetBeansProjects/HelloRPi'
"/usr/bin/make"  -f nbproject/Makefile-Debug.mk dist/Debug/GNU-Linux-x86/hellorpi
make[2]: Entering directory '/home/netbeans/.netbeans/remote/192.1.2.200/andrey-laptop-Windows-x86_64/C/Doc/NetBeansProjects/HelloRPi'
mkdir -p build/Debug/GNU-Linux-x86
rm -f "build/Debug/GNU-Linux-x86/main.o.d"
g++    -c -MMD -MP -MF "build/Debug/GNU-Linux-x86/main.o.d" -o build/Debug/GNU-Linux-x86/main.o main.cpp
mkdir -p dist/Debug/GNU-Linux-x86
g++ -o dist/Debug/GNU-Linux-x86/hellorpi build/Debug/GNU-Linux-x86/main.o 
make[2]: Leaving directory '/home/netbeans/.netbeans/remote/192.1.2.200/andrey-laptop-Windows-x86_64/C/Doc/NetBeansProjects/HelloRPi'
make[1]: Leaving directory '/home/netbeans/.netbeans/remote/192.1.2.200/andrey-laptop-Windows-x86_64/C/Doc/NetBeansProjects/HelloRPi'

BUILD SUCCESSFUL (total time: 2s)
Jacobm001
  • 11,797
  • 7
  • 45
  • 56
Andrey Pro
  • 280
  • 1
  • 2
  • 8
  • I'm not a netbeans user but WRT "so I upgraded gcc and g++ to 4.8.2" -- why don't you just upgrade to Raspbian jessie? Sooner or later it has to happen. **4.9.2 is the default there.** Also, I would look and see if there is a way to configure netbeans to use a specific compiler before rearranging links, but sometimes a hack is the only solution. Of course if the default is 4.9.2 it won't matter... – goldilocks Feb 12 '16 at 15:36
  • [upgraded](https://www.raspberrypi.org/documentation/raspbian/updating.md) to no effect – Andrey Pro Feb 12 '16 at 16:37
  • That's just updating software in the current distro release -- you are obviously using Raspbian/Debian version 7, aka "wheezy". The current version (as of spring 2015) is version 8, aka "jessie". [See here](http://raspberrypi.stackexchange.com/q/26041/5538) about upgrading to that. You can tell the difference by looking at `/etc/issue`. – goldilocks Feb 12 '16 at 16:49
  • Ok upgraded the system. g++ got upfraded to 4.9 and gdb to 7.7 . And it didnt help. However I managed to find out something: when i start debug and try to run to the cursor, the netbeans shows message: _No source file named /home/netbeans/.netbeans/remote/192.1.2.200/andrey-laptop-Windows-x86_64/C/Doc/NetBeansProjects/HelloRPi/main.cpp._ – Andrey Pro Feb 17 '16 at 13:51
  • 1
    I created a new project, copied the source code and it worked. – Andrey Pro Feb 17 '16 at 14:39

1 Answers1

0

You should compile a compiler by hand with CFLAGS "-g -ggdb" and compile the GDB itself too, use last versions. I've faced same problem in different circumstances, but IDE restored it's normal debugging abilities after a recompile cycle I've mentioned upstrings. And - when you're replacing something in Debian systems - make SURE that you're using update-alternatives script, not just simple replacement

Alexey Vesnin
  • 926
  • 9
  • 16