Так получилось, что за достаточно долгую карьеру Windows и Embedded разработчика судьба свела меня по серьезному с Linux всего лишь несколько месяцев назад. Нужно было написать не очень сложную консольную программу. На тот момент все мои знания о Linux были взяты из курса по операционным системам в вузе (10 лет назад). Но Stackoverflow, google и опыт позволили достаточно быстро справиться с задачей. В итоге все было написано в Visual Studio Code под Ubuntu 14.04. Правда, приложение под Linux являлось только лишь небольшим клиентом для Windows сервера. Поэтому результат не очень удовлетворял меня, так как был оторван от основного проекта в Visual Studio. И только сейчас я смог перенести код в основной проект с помощью Visual C++ for Linux Development. В процессе мне пришлось решить несколько сопутствующих проблем. Об этом я рассажу под катом.
Итак, Visual C++ for Linux Development — это расширение для Visual Studio, позволяющее писать код в привычной многим IDE под Windows, а отлаживать его прямо в целевой операционной среде — Linux. При этом используется GCC и Remote GDB Debugger. Более подробно о расширении можно прочитать в блоге разработчиков или в переводе на хабре.
Инструкции того, как установить, запустить, настроить и т.д. можно найти по ссылкам выше. У меня с этим не возникло никаких проблем. Вопросы начались со стороны Linux системы. Напомню, что я использую Ubuntu 14.04 LTS и дальнейшее изложение пойдет именно про нее. Если ком интересно, я использовал образ для VirtualBox с сайта osboxes.org.
Так же, прошу сильно меня не ругать, я все-таки в Linux далеко не гуру. Лучше подскажите, если что-то можно сделать более оптимальным путем.
Отладка первой программы
Перед тем, как использовать удаленную отладку, нужно установить несколько компонентов на Linux системе. Как указано в инструкциях по ссылке выше, это можно сделать, выполнив в командной строке следующее:
sudo apt-get install openssh-server g++ gdb gdbserverВызвать терминал в Ubuntu можно комбинацией клавиш Ctrl+Alt+T.
Я не помню, запускается ли все это хозяйство сразу или нет, по этому на всякий случай можно перезагрузиться.
Если все сделано правильно, то будет открыт порт 22. Проверить это можно используя команду nmap.
Но сразу подключиться из-под Visual Studio у меня не удалось, так как система почему то не пускала меня под единственным пользователем. Пришлось создать другого. Это можно сделать в System Settings->User Account.
При этом, не забыв нажать кнопку Unlock в верхнем правом углу.
Настроить подключения в Visual Studio можно в окне Tools->Options
Теперь можно запустить и отладить тестовый проект.
При этом в Ubuntu будут скопированы исходники и собранный файл программы (если это не отключено в настройках проекта). Все это можно будет найти в папке /home/<имя пользователя>/projects.
В моем случае получилось вот так:
Запустить программу в самом Linux можно из консоли:
Теперь вроде бы можно начинать работать. Я перенес исходные файлы в Visual Studio и… ничего у меня не скомпилировалось. Оказалось, что проекту не достает .h файлов из include directories.
Подключаемые файлы
Вместе с Visual C++ for Linux Development устанавливается и множество заголовочных файлов. Их можно найти тут:
C:Program Files (x86)Microsoft Visual Studio 14.0VCLinuxincludeusrНо моему проекту этого не хватило.
В блоге разработчиков по этому поводу сказано следующее:
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.В будущем эту проблему обещают решить, ну а сейчас крутитесь как хотите. Там же приведен пример с копированием директории всей /usr/include с помощью PuTTY.
Но мне такой путь не нравится. Лично я предпочитаю расшарить папку с заголовочными файлами. Список директория для поиска include файлов можно посмотреть, выполнив в консоли команды
$ touch a.c
$ gcc -v -E a.c
Мне хватило папки /usr/include.
В случае с моей версией системы, перед тем как расшарить данную папку, нужно перевести ее во владение текущему пользователю. Делается это командой sudo chown -R osboxes:test '/usr/include'.
После этого можно открыть доступ к папке. Как это сделать написано тут.
После этого, сетевые пути можно прописать в Visual Studio как Include Directories.
Такой подход имеет преимущество в виде того, что вы будете работать всегда с оригинальными заголовочными файлами и вам не нужно будет ничего синхронизировать. С другой стороны, будут проблемы при переносе разработки на другой компьютер. Так же, как я уже писал, я работаю с Ubuntu, установленной на виртуальной машине на моем компьютере. При такой конфигурации, проблемы с безопасностью уходят на второй план.
Но в других конфигурациях, действия, описанные мной выше, могут быть запрещены.
Таком образом, проблему синхронизации заголовочных файлов нужно решать исходя из условий работы. Тут выбор остается за вами.
Дополнительные команды компилятора и линкера
Заголовочные файлы стали видны и компиляция прошла успешно. Но вот слинковаться проекту не удалось. Дело в том, что я использую потоки и заголовочный файл "pthread.h". Для того, чтобы линкер увидел библиотеку pthread, нужно использовать опцию -pthread или -lpthread.
Для этих целей в Visual C++ for Linux Development есть специальная настройка:
Но у меня почему то она не работает. Проблема эта временная (разработчики уже знают об этом), но решать ее нужно здесь и сейчас. Обойти это ошибку можно используя другую опцию:
Если в место g++ написать g++ -pthread, то получится правильная строка линкера:
Тот же трюк срабатывает и для компилятора.
Запуск отладки с правами администратора
Теперь все скомпилировалось и слинковалось. Однако для работы программы нужны повышенные права, так как она открывает файл устройства ввода. Соответственно, отладку так же нужно запускать с правами администратора. Сейчас в Visual C++ for Linux Development эта опция не реализована, но есть одно решение.
Можно повысить в правах gdb и gdbserver командами
$ sudo chmod ugo+s /usr/bin/gdb
$ sudo chmod ugo+s /usr/bin/gdbserverТакой совет можно найти в комментариях в посту в блоге разработчиков.
Этот трюк работает, но он не безопасен. По сути, вы отдаете свою систему любому, кто подключается к gdbservr. В моей конфигурации это не страшно, так как все запущено на одном моем компьютере, но в других условиях нужно быть очень аккуратными с такими действиями.
Копирование дополнительных файлов
И остался последний момент. Моя программа читает настройки из текстового файла. Он является частью проекта Visual Studio и при компиляции должен копироваться в папку с исполняемым файлом.
Это можно так же сделать в настройках проекта:
Чтобы просто скопировать файл, как остальные исходники, его можно добавить в поле Sources To Copy: @(SourcesToCopyRemotely);config.txt
А скопировать его в другую директорию можно с помощью Additional Sources To Copy.
Формат этой настройки
fulllocationpath1:=fullremotepath1;fulllocationpath2:=fullremotepath2
и т.д.
В моем случае такая строка выглядит так:
$(ProjectDir)config.txt:=$(RemoteOutDir)config.txt;Все бы хорошо, но и тут у меня возникли проблемы.
Дело в том, что макрос $(RemoteOutDir) раскрывается в путь, начинающийся с символа "~".
Судя по всему, этот путь завязан с этой настройкой:
Так вот, при компиляции все работает хорошо. Но вот при копировании файлов почему то ~ воспринимается не как root директория, а просто как имя папки. То есть создается папка с именем "~":
Справиться с этим мне так и не удалось, поэтому я просто копировал файл config.txt вручную. Правда, для этого пришлось опять использовать изменение прав на папку:
sudo chown -R osboxes:test '/home/test'
Что в итоге
Лично я могу сказать, что Visual C++ for Linux Development extension мне помог. Не смотря на все проблемы и пару багов, он позволил мне быстрее и эффективнее решить задачу, связанную с разработкой под Linux.
Наверное, можно на это возразить, что есть более удобные пути, но я исходил только из своего опыта и знаний, а все это в основном связано с Windows.
p.s. Недавно в сети появилось видео от MSP Александра Поповкина (@Catharsis96), где он так же делает обзор данного дополнения.
Автор: AlexandrSurkov
