Sysprogs forums › Forums › VisualGDB › Failure with C++ tutorials
- This topic has 2 replies, 2 voices, and was last updated 9 years, 10 months ago by grumpyboris.
-
AuthorPosts
-
January 13, 2015 at 19:04 #965grumpyborisParticipant
I am new to Linux but have many years of Windows development experience. I need to produce something for the Beaglebone Black and of course it needs to be done yesterday. Hence I am evaluating VisualGDB to see if it can get me up and running quickly.
I am using:
Beaglebone Black flashed with BBB-eMMC-flasher-2013.09.04.img
VisualGDB-4.3r2-trial.msi
Vis Std 2013 Professional Update 4
Windows 8.1 EnterpriseI have followed the two tutorials for C++ development. The first (remote build) works as expected. Although it does ask if I want to correct mismatching environment for PS1 between console “u@h;w.$” and command mode “u@h:w$”, which I select “FixValue”.
I have had problems with the second tutorial, which is my preferred approach, that of cross-compilling on the Windows box.
The first problem is that the Toolchain Test Fails with"no such file or directory" "Expected return code 108. Actual return code 127".
If I ignore this I can go on to build the sample app which works but debugging the app fails with
"The gdbserver has exited with code 1"
and the GDBServer log displays
"Cannot exec /tmp/BBDemo2: No such file or directory. Child exited with status 127 No program to debug. GDBserver exiting."
But the file is there according to “file ./hello”. Running “readelf -l ./hello” shows that it is “requesting program interpreter /lib/ld-linux-armhf.so.3” which I can’t find.
If I deploy directly and run on the BBB again I get “Permission denied”. I tried “/lib/ld-linux.so.3 ./hello” which worked. So I set up a link
"ln -s -v /lib/ld-linux.so.3 /lib/ld-linux-armhf.so.3"
and running directly on the device now works.
But when running from the debugger I get a segmentation fault and this appears to occur in the loader (/lib/ld-linux.so.3) as Vis Std is trying to load its symbols.
I tried synchronising the sysroot but this led to build errors and IntelliSense errors. Note that the local sysroot directory was set to “c:sysgccbeaglebonearm-linux-gnueabihfsysroot”.
46 errors in total:-
"'__syscall_slong_t' does not name a type" in beaglebonearm-linux-gnueabihfsysrootusrincludetime.h (line 123) expected initializer before '__THROWNL' in beaglebonearm-linux-gnueabihfsysrootusrincludepthread.h (line 123) etc...
It would seem that I have some problem with the toolchain and/or syncing it between the BBB and the Windows box.
Could someone advise how to progress with this given that I’m not a linux person.
Thanks
January 18, 2015 at 19:20 #3520supportKeymasterHi,
Most likely you are using a corrupt image. Please download a fresh image from the Beaglebone website and re-flash it. Regarding IntelliSense, the error messages are caused by Visual Studio’s IntelliSense engine not being able to handle some GCC-specific constructs. We are currently working on a clang-based IntelliSense engine that will resolve this problem. We will be releasing a preview build within the next few weeks. Please feel free to give it a try once it is out.
January 19, 2015 at 10:31 #3521grumpyborisParticipantWell I don’t know if its finger trouble on my part or something else I’ve changed but the automatic download (during project create) for C++ on Beaglebone Black with Angstrom distro was actually downloading the Debian toolchain to my windows dev box. So it works when remote building (on BBB) but local (windows) builds, and the sysroot sync fail. That toolchain was installed at “c:sysgccbeaglebonearm-linux-gnueabihfsysroot”.
I got the correct toolchain installed from this location – http://gnutoolchains.com/beaglebone/ and everything started to work OK (no errors not even IntelliSense errors). This toolchain was installed as “c:sysgccbeaglebonearm-angstrom-linux-gnueabisysroot”.
Now all I have to do is work out how to get gsoap built…
-
AuthorPosts
- You must be logged in to reply to this topic.