VS2017 - How to configure project for remote debugging - c++

I want to create an MP3 player on my Raspberry Pi (OS: Raspbian). The problem is, that i don't have any experience with Linux programming, and I'm having a huge problem with project configuration, becouse of cross platform compiling. I want to add two liblaries:
mpg123
libao
I'm able to compile the code on linux machine with gcc -O2 test.cpp -lmpg123, but I can't force Visual Studio to make see those libs.
I'm also having a problem with using wiringPi lib while I'm trying to remote debugging my program, since I have to run it as root for GPIO configuration. Is there any way for any way to force Visual Studio to run my compiled code with root privilages?

Personally I come from a long history of C/C++/MFC/Windows programming with no Linux experience at all. I started programming for the Raspberry a year or so ago, when I got one from my son for my birthday. With a C/C++ history it's really not that hard, but you just have to read in a bit because on Linux a lot is the same, and a lot isn't :). Just read and read and in time, you're an experienced Linux programmer! It takes some time I'm afraid.
So, I'm sort of an experienced newbie on this I think :). I found a lot of info on www.die.net (and other Linux man pages). If you search there for a function, say printf(), look at the (3) pages - they explain how you should use 'm.
But although VS2017 does a really good job on this, it's not always going as smooth as you would like. Sometimes it's just necessary to reboot your Raspberry, restart VS and try again. The Linux cross-compiling is quite new in VS and isn't perfect yet.
A few tips:
Use a Raspberry with a fresh Stretch image to start with. Of course after a sudo apt-get update && sudo apt-get -y upgrade.
Set the debugger in Visual Studio to gdb instead of gdbserver. This will prevent certain debugging problems.
Place all your source files (.h and .cpp) in the main folder of your project alongside the main.cpp. If you place them in different directories and then include in your project, you can debug your program but you won't be able to step through.
Start simple and debug your program often when you're developing. Don't add too much code before your next check. In a cross-compile setup there are just a lot more things than normal that can (and will) go wrong.
VS2017 has default Linux include files in C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\Linux\include. If you need others, place them in a folder of you own and include the path.
With cross-compiling VS itself doesn't do any compiling, you use it to maintain your project. When the project has to be compiled, all necessary files are copied to the Raspberry and the compiler and linker there are invoked by VS.
On your question how to configure a project for remote debugging: it's probably best to start with the Blink example in Visual Studio 2017 (File, New, Project, Installed, Visual C++, Cross Platform, Linux => Blink). It should run without problems. From there, you can build further on your project.
In the Blink example, they use wiringPiSetupSys() and the remote command gpio export 17 out to run your program without sudo. I've found that changing that to wiringPiSetup() and disabling the remote command, it still is possible to run and debug the program. On the Raspberry I can run the program from it's folder by issuing ./[programname]. If that doesn't work for you, you could run the program by issuing sudo ./[programname].

Related

Raspberry Pi crashes when building OpenFrameWorks project in Eclipse CDT

I'm working on a Raspberry Pi 3 with OS Raspbian Jessie. I'm using Eclipse CDT (for C/C++) and am trying to learn about OpenFrameWorks:
http://openframeworks.cc/
I installed everything according to the guides and imported everything to Eclipse. I thought it seemed to work out, but when I try to run some test-code I get the error "Unable to launch, binary not found." I look it up and find a potential solution, that I have to build the actual project first.
This is my problem, when I try to build the project Eclipse gets to about 20% and then the entire Raspberry freezes, forcing me to force a restart. How can I continue from here on out? I don't know if I still should try to build the project through Eclipse or if there is another way to actually run some test code for OpenFrameWorks.
I don't know if this is the best place to ask about this, but I'm thankful for all answers.
Eclipse is super slow on Raspberry Pi.
I recommend using the provided setup scripts to install dependencies. After you compile OF, use make files to compile projects.
In terms of editing code, I recommend using a light weight text editor (geany for example). I've tried CodeBlocks and Qt Creator, which are faster/less resource intensive than eclipse, but still pretty heavy for a system with limited resources.
Another option is to combine your computer the RPi:
Use projectGenerator to generate a project for both Raspberry Pi and your computer/IDE
Edit/test/iterate on your computer
When ready to run on RPi, sync the project using your preferred method(e.g. SSH/SFTP/git/etc.), then use make -j4(to use all 4 cores) in the RPi project folder.
The pro is you the quick compile/feedback times you're used to on your computer.
The con is this method won't work for RPi specific code (e.g. accessing GPIO, PiCamera, etc.)
Another option is to setup cross compilation, but getting everything ready is a bit laborious. (Although, once it's done, it saves time on the long run).

VSCode c++ configuring for vc toolchain

I'm trying to start a work in vscode , latest C++ plugin version supports ms debugger, so as I'm mostly working under windows it was a signal to try this.
c++ tools plugin from MS and cmake tools were installed.
my test project was however not built . the problem is clear , but I need an advice from experienced vscode users how to solve this right.
cmake doesn't see vc compiler.
(after using QtCreator) I expected that vscode could detect vc installation... however that's not so. ok, I have a two ways:
fill environment variables INCLUDE/LIB/PATH with a headers, libs and binaries
just run vcvarsall.bat x64
Second way is a simple and reliable. so final question is:
how to run .bat at the begining of vscode start?
(I don't mean write another bat/cmd, prepare the environment and run vscode inside the same script after that)
Although the question is fairly old, I'll try to give a useful answer, in case others stumble across, just like I did.
I believe what you are trying to achieve is not possible. Code inherits the environment it was started with. If you did not launch it from a developer command prompt, you will not be able build and debug. (Building might be possible if every task first starts the vcvarsall.bat, but that slows things down by a lot. Debugging I think will still not work.)
If you are willing to, you can check out vector-of-bools CMake Tools extension which does build automation as well as automatic MSVC detection. It builds using CMake (thus you need to write your build scripts using CMake), but it will take care of building just by pressing F7, like what most VS users are familiar with.

How to make a c++ project run on a different PCs

I developed a small c++ program in Visual Studio 2012 on Windows7, 64bit (let's call it PC1). On that pc it runs fine!
Since I didn't have a versioning control system like SVN at hand, I copied ALL the project data (the exact folder structure, DLLs, source files, project files...) to a usb stick and moved it to another computer.
On that other engine there's Visual Studio 2010 on Windows7, 64bit (PC2).
So I just changed the platform toolset to v100 as described here.
I successfully compiled the project on PC2 (clean, build) and wanted to run the exe, but the command prompt stayed empty.
I then tried to debug and added a breakpoint at the very first line of main - which wasn't reached, the command prompt was still empty.
Ok, a usb stick is certainly not the most secure solution for data storage, so I gave it another try and moved it again - the problem remains.
Visual Studio's output on PC2 is the same as on PC1, so I couldn't find any anomalies there.
Yeah, there might be many error sources, so where can I start?
And how can I get a more verbose output for troubleshooting?
Or is this even a common phenomenon (perhaps due to different VS versions) and there's an simple way fix it?
This is not a full solution, but at least I'm a tiny step ahead:
In my last comment I wrote:
I took your advices into account and created a brand new project on PC2, VS2010. I exactly followed this guide: http://frozenhamster.wordpress.com/2011/02/11/lapack-on-windows-with-visual-studion-2010/
That didn't work either, so I removed I "out-commented" everything except for a single cout. Voila, that worked!
But as soon as I make use of the desired Armadillo (LAPACK and BLAS), the project compils but does not run.
What's going wrong here?
I don't get any compiler errors!

c++ program failed to run on another pc with libgcc error

I wrote some simple code in C++, and I built it and ran it on my laptop, and everything as working. When I tried to run the .exe file on my brother's laptop, it gave me this error The program can't start because libgcc_s_sjlj-1.dll is missing from your computer. Try reinstalling the program to fix this problem. Am I missing something that I should have added or something?
Note: I don't know if it matters or not, but I'm using Code::Blocks.
Thanks
It matters because you used Code::Blocks. If you don't know about it, you most probably used Code::Blocks with MinGW. Install it on that machine followed by a reboot may fix it.
C++ programs need to have a runtime library -- you can think of it as needing .NET Framework to run C# or JRE to run Java programs. Visual C++ uses msvcrt (known as Visual C++ Runtime). Many installations of Windows seem to come with msvcrt by default which may explain why people using MSVC is less likely to run into issues like this.
If you statically link the CRT (C Run Time) you can lift the requirements of the clients having to have the DLL files installed, at the expense of having a larger .exe file.
A relevant SO answer: The program can't start because libgcc_s_dw2-1.dll is missing
You can place that DLL in the same folder as the .exe on your release and it should work

Building Qt cross compile from windows

[edit] Sorry, I out thought myself. I was using a .bat file to set environment variables that wasn't set up properly. When I went to a straight VS2005 command prompt, the configure ran fine. Sorry for the noise.[/edit]
I'm trying to compile qt-everywhere-opensource for embedded. I'm using MSVC2005. However, I guess I am confused on the process. I am getting compiler errors during the configure step. I thought the configure step was just trying to generate the needed makefiles, so I'm not sure what it is trying to compile.
I expected to modify the mkspec, but I'm not sure if during configure I should point to windows headers or sdk headers. I know during the build phase I should point to sdk headers, but I'm not getting that far.
I can change the errors by modifying INCPATH, there's also a QMAKE_INCDIR that seems to have an effect. It occurred to me that since I pulled the source, maybe configure needs to build the compiler tools, in which case I should point to MSVC headers. I also tried downloading the SDK and adding the path to it's bin folder to my path ahead of the -everywhere- source, but that didn't fix the problem and I don't want to jack up my system too much testing things.
Hope someone out there can help!
When you install Qt from source under Win32, you must:
Extend the PATH variable to include $(QTDIR)\bin, where $(QTDIR) is the directory where you installed Qt.
Open a Visual Studio command prompt in $(QTDIR); a plain old Windows command prompt won't do (unless you run vcvars.bat to load Visual Studio's environment variables; but opening a Visual Studio command prompt directly is better).
At this point, configure should run properly, after which you can run nmake.
I suggest that you clear your previous installation attempts from your system before you try these steps.