It so happened that for quite a long career as a Windows and Embedded developer, fate brought me seriously with Linux just a few months ago. It was necessary to write a not very complicated console program. At that time, all my knowledge about Linux was taken from the course on operating systems at the university (10 years ago). But Stackoverflow, google and experience allowed to cope with the task fairly quickly. As a result, everything was written in Visual Studio Code under Ubuntu 14.04. True, the application for Linux was only a small client for the Windows server. Therefore, the result was not very satisfying to me, since it was cut off from the main project in Visual Studio. And only now I was able to transfer the code to the main project using Visual C ++ for Linux Development . In the process I had to solve several related problems. About this I will sit under the cut.
So, Visual C ++ for Linux Development is an extension for Visual Studio, which allows you to write code in many of the usual IDEs for Windows, and debug it directly in the target operating environment — Linux. It uses GCC and Remote GDB Debugger. For more information about the expansion can be found in the blog developers or translated to Habré .
Instructions on how to install, run, configure, etc. can be found on the links above. I had no problems with this. Questions started from the Linux system. Let me remind you that I use Ubuntu 14.04 LTS and the further presentation will go about it. If anyone is interested, I used the image for VirtualBox from osboxes.org .
Also, I beg you not to scold me much, I'm still not a guru in Linux. Better tell me if something can be done in a more optimal way.
Before you can use remote debugging, you need to install several components on a Linux system. As indicated in the instructions for the link above, this can be done by doing the following on the command line:
sudo apt-get install openssh-server g++ gdb gdbserver
Call the terminal in Ubuntu can be a combination of keys Ctrl + Alt + T.
I don’t remember if all this stuff starts right away or not, so just in case you can reboot.
If everything is done correctly, port 22 will be opened. You can verify this using the nmap
command.
But I could not immediately connect from under Visual Studio because the system for some reason did not let me under the sole user. I had to create another. This can be done in System Settings → User Account .
At the same time, do not forget to press the Unlock button in the upper right corner.
You can configure connections in Visual Studio in Tools → Options
Now you can run and debug a test project.
At the same time, the source code and the collected program file will be copied to Ubuntu (if this is not disabled in the project settings). All this can be found in the folder / home / <username> / projects .
In my case, it turned out like this:
You can run the program in Linux itself from the console:
Now, it seems, you can start working. I transferred the source files to Visual Studio and ... nothing compiled with me. It turned out that the project lacks .h files from include directories .
Together with Visual C ++ for Linux Development, many header files are also installed. They can be found here:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\Linux\include\usr
But this was not enough for my project.
The developer blog says the following about this:
Getting your include files Everyone loves IntelliSense, but we're not yet synchronizing the include files from your Linux system. Everyone has their own ways to either share or copy these files which is great.
In the future, this problem is promised to be solved, but now you’re cool. There is also an example with copying the entire directory of / usr / include using PuTTY .
But I do not like this way. Personally, I prefer to share a folder with header files. The list of directories to search for include files can be viewed by running the commands in the console.
$ touch ac $ gcc -v -E ac
I have enough folder /usr/include
.
In the case of my version of the system, before sharing this folder, you need to transfer it to the possession of the current user. This is done with the command sudo chown -R osboxes:test '/usr/include'
.
After that, you can open access to the folder. How to do it is written here .
After that, network paths can be written in Visual Studio as Include Directories.
This approach has the advantage that you will always work with the original header files and you will not need to synchronize anything. On the other hand, there will be problems when transferring development to another computer. Also, as I already wrote, I work with Ubuntu installed on a virtual machine on my computer. With this configuration, security problems go into the background.
But in other configurations, the actions I described above may be prohibited.
Thus, the problem of synchronization of header files must be solved on the basis of working conditions. Here the choice is yours.
The header files became visible and the compilation was successful. But the project could not be linked. The fact is that I use threads and the header file "pthread.h". In order for the linker to see the pthread library, you need to use the -pthread or -lpthread option.
For these purposes, there is a special setting in Visual C ++ for Linux Development:
But for some reason it does not work for me. This problem is temporary (the developers already know about it), but it needs to be solved here and now. You can work around this error using another option:
If you write g ++ -pthread in place of g ++, you get the correct linker string:
The same trick works for the compiler.
Now everything is compiled and linked. However, the program requires elevated rights, since it opens the input device file. Accordingly, debugging also needs to be run as an administrator. Now this option is not implemented in Visual C ++ for Linux Development, but there is one solution.
You can increase the rights of gdb and gdbserver commands
$ sudo chmod ugo+s /usr/bin/gdb $ sudo chmod ugo+s /usr/bin/gdbserver
Such advice can be found in the comments in the post on the developer blog .
This trick works, but it is not safe. In fact, you give away your system to anyone connecting to gdbservr. In my configuration, this is not scary, since everything is running on one of my computers, but in other conditions you need to be very careful with such actions.
And the last moment remained. My program reads settings from a text file. It is part of the Visual Studio project and must be copied to the folder with the executable file when compiled.
This can also be done in the project settings:
To simply copy the file as other sources, you can add it to the Sources To Copy field: @ (SourcesToCopyRemotely); config.txt
And you can copy it to another directory using Additional Sources To Copy.
The format of this setting
fulllocationpath1:=fullremotepath1;fulllocationpath2:=fullremotepath2
etc.
In my case, this line looks like this:
$(ProjectDir)config.txt:=$(RemoteOutDir)config.txt;
Everything is good, but here I have problems.
The point is that the $ (RemoteOutDir) macro is expanded into a path starting with the "~" character.
Apparently, this path is tied up with this setting:
So, when compiling everything works well. But when copying files for some reason ~ it is not perceived as a root directory, but simply as a folder name. That is, a folder is created with the name "~":
I failed to cope with this, so I simply copied the config.txt file manually. However, for this, I had to use the rights change for the folder again:
sudo chown -R osboxes: test '/ home / test'
Personally, I can say that the Visual C ++ for Linux Development extension helped me. Despite all the problems and a couple of bugs, he allowed me to quickly and efficiently solve the problem associated with developing for Linux.
Probably, it can be argued that there are more convenient ways, but I proceeded only from my experience and knowledge, and all this is mainly related to Windows.
ps Recently, a video from MSP Alexander Popovkin (@ Catharsis96) has appeared on the network, where he also gives an overview of this supplement.
Source: https://habr.com/ru/post/321228/