AG>Вопрос: как можно приспособить Linux для задач компиляции и линковки кодов C++17? AG>Примечание: меня интересует прежде всего применение этого добра в среде UBUNTU 14.04 (и в некоторой степени Debian 8).
ПОЛНЫЙ С++17 реализует gcc 8
Шахтер тут недавно постил про него.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, AlexGin, Вы писали:
V>>для 3.9 надо "-std=c++1z"
AG>Пробовал я эту опцию — бесполезно AG>Всё равно — была ругань на новые синтаксические выражения.
Здравствуйте, AlexGin, Вы писали:
AG>Доброе время суток, уважаемые коллеги!
AG>Я осваиваю новый для меня C++17, используя MSVC-2017 CE. С опцией для студии, требуемой для компилятора, успешно разобрался.
AG>Задумался на тему: для Linux (UBUNTU 14.04; Debian) — есть GCC и Clang.
Нафталином обмазываешься перед тем ка кза ПеКа садиться? Давно уже 18 убунта есть с новейшим gcc и clang где есть даже частично 21 стандарт. AG>Я так понимаю, что они также как и студия, поддерживают C++17? AG>Заранее спасибо, за любые подсказки!
Проапгрейди релиз убунты до 18.
Также работает Debian 8 (а вот Debian 9: не хочет устанавливаться — нет драйверов wi-fi, старые от Debian 8 не подходят).
В общем в мирке ОС Linux — всё очень удивительно
Пробовал — падают сразу после инсталляции: UBUNTU 16.04; UBUNTU 17.10; UBUNTU 18.04 — далее даже не стартуют
P.S. Апгрейд системы UBUNTU 14.04 — до более свежей — заканчивается аналогично: после него даже не стартует!
Здравствуйте, LaptevVV, Вы писали:
AG>>Вопрос: как можно приспособить Linux для задач компиляции и линковки кодов C++17? AG>>Примечание: меня интересует прежде всего применение этого добра в среде UBUNTU 14.04 (и в некоторой степени Debian 8). LVV>ПОЛНЫЙ С++17 реализует gcc 8 LVV>Шахтер тут недавно постил про него.
Да — gcc 8 успешно работает с C++17
ОГРОМНОЕ СПАСИБО!
Здравствуйте, AlexGin, Вы писали:
AG>Работает только UBUNTU 14.04!
Понятно, тогда это реально проблема. AG>Также работает Debian 8 (а вот Debian 9: не хочет устанавливаться — нет драйверов wi-fi, старые от Debian 8 не подходят). AG>В общем в мирке ОС Linux — всё очень удивительно
Может где-то пропиетаные либы есть из которых можно собрать модуль ядра? AG>Пробовал — падают сразу после инсталляции: UBUNTU 16.04; UBUNTU 17.10; UBUNTU 18.04 — далее даже не стартуют
У меня есть подозрение что это может быть связано с UEFI, тут нужно разобрваться, попробуй на SO поискать ответ. AG>P.S. Апгрейд системы UBUNTU 14.04 — до более свежей — заканчивается аналогично: после него даже не стартует!
Как вариант, можно попробовать поставить msys2/mingw и через него подцепить новый gcc в VS Code под винду, но решение так себе.
Здравствуйте, Kernan, Вы писали:
K>Может где-то пропиетаные либы есть из которых можно собрать модуль ядра?
Боюсь, что это самый долгий и трудный (тернистый) путь...
AG>>Пробовал — падают сразу после инсталляции: UBUNTU 16.04; UBUNTU 17.10; UBUNTU 18.04 — далее даже не стартуют K>У меня есть подозрение что это может быть связано с UEFI, тут нужно разобрваться, попробуй на SO поискать ответ.
Я в курсе, что любой Linux — ставим в обычном режиме (не на UEFI mode режиме, а на Legasy CSM BIOS режиме). Тем не менее — проблемы есть.
Более того, установщик UBUNTU имеет пробный режим запуска — try UBUNTU. Так этот режим у меня также корректно работает только для UBUNTU 14.04.
Для всех остальных (указанных выше в данной ветке) версий UBUNTU — пробный режим благополучно крашится
AG>>P.S. Апгрейд системы UBUNTU 14.04 — до более свежей — заканчивается аналогично: после него даже не стартует! K>Как вариант, можно попробовать поставить msys2/mingw и через него подцепить новый gcc в VS Code под винду, но решение так себе.
Для винды — у меня нет никаких проблем: MSVC-2017 CE — в настройках C/C++ -> CommandLine -> AdditionalOptions запишем: /std:c++17
и всё отлично работает
P.S. Так как все остальные разновидности C++ (11 & 14) я опробовал под UBUNTU/Debian, то у меня "чешутся руки" проделать то же для C++17.
Попутно замечу, что для других стандартов всё ставится "из коробки" c Qt v5.10.1:
здесь: https://download.qt.io/official_releases/qt/5.10/5.10.1
берём: qt-opensource-linux-x64-5.10.1.run
и просто ставим (без apt-get install, просто в стиле винды)!
При этом, перед установкой пакета qt-opensource-linux-x64-5.10.1.run я конечно же выполнял следующие установки:
я так понимаю на этом ноутбуке стоят Linux и Windows 10, тогда почему бы не поставить VMWare Player в десятку и оттуда уже запускать любые дистрибутивы любых линуксов.
Огромное Спасибо!
Удалось установить GCC v8, а также и clang-5.0 и clang-6.0 — благодаря подсказкам, приведенным по данным ссылкам!
И всё это на UBUNTU 14.04!
Здравствуйте, Masterspline, Вы писали:
M>https://apt.llvm.org/ и будет тебе самый clang 6.0 (с поддержкой c++17) для твоего Ubuntu Trusty (14.04). Как подключить gcc можно тоже поискать.
+100500
Спасибо — этот вариант уже подсказали ранее.
M>Еще вариант — использовать docker (там и gcc последний будет и clang).
Здравствуйте, AlexGin, Вы писали:
AG>Это — оно: AG>https://docs.docker.com/glossary/?term=Docker AG>как я понял — некий "адаптер" для выполнения компиляции где-то на сервере? Так?
Нет. Легкая и удобная виртуальная среда. Для поганять разные компиляторы в "чистой среде" — самое то. https://hub.docker.com/_/gcc/
Здравствуйте, AlexGin, Вы писали:
AG>На НОВОМ компьютере (на ноуте) — за ноябрь 2017 выпуска AG>Работает только UBUNTU 14.04!
1. Зачем ставить Linux на голое железо ноутбука, если основная цель — поиграться с С++17? Есть же WSL (в случае Win10) или виртуалки, в конце концов
2. Зачем ставить Linux, если основная цель — поиграться с С++17? Есть же GCC (mingw-64, к примеру), Clang
Здравствуйте, flаt, Вы писали:
F>1. Зачем ставить Linux на голое железо ноутбука, если основная цель — поиграться с С++17? Есть же WSL (в случае Win10) или виртуалки, в конце концов
Насчёт Win10 и WSL:
Всё это (Win10 и WSL) видится мне несколько искусственным.
Насчёт виртуалки — подумаю, может и неплохая идея, спасибо.
Пока работаю на dual-boot.
F>2. Зачем ставить Linux, если основная цель — поиграться с С++17? Есть же GCC (mingw-64, к примеру), Clang
Я в курсе насчёт MinGW — ранее занимался с ним.
Для среды MS Windows — это также искусственная штука, когда есть MSVC-2017.
Для студии — я уже давно разобрался, как компилоровать в ней коды на C++17.
Основные цели и направления — как освоение C++17, так и расширение профессионального кругозора.
Так, если сегодня мне требуется разработка ПО (C++; Qt) для Windows, то завтра — возможно потребуется кроссплатформа и Linux
P.S. Я в курсе, что это всё есть, но я добился — и уже осуществил свою идею — компиляция примеров из книжки: http://rsdn.org/forum/cpp/7122404
Кстати, автор вышеуказанной книги настаивает рекомендует, чтобы читатель применял именно Linux.
К M$ (в плане работы с C++) автор относится достаточно сдержанно.
Здравствуйте, AlexGin, Вы писали:
AG>Всё это (Win10 и WSL) видится мне несколько искусственным.
А что не так? Мне понравилось. Единственное, нельзя в FS напрямую лазать (вернее можно, но чревато), чтобы конфиги, например, поправить, надо какой-нибудь SSH поднимать. А так — они даже фоновые процессы сейчас запилили, в рамках пользовательской сессии.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, AlexGin, Вы писали:
AG>>Всё это (Win10 и WSL) видится мне несколько искусственным. Ops>А что не так? Мне понравилось. Единственное, нельзя в FS напрямую лазать (вернее можно, но чревато), чтобы конфиги, например, поправить, надо какой-нибудь SSH поднимать. А так — они даже фоновые процессы сейчас запилили, в рамках пользовательской сессии.
То есть (я выделил "самый смак") — работаем с Linux, а работь с файлами не можем.
Я верно понял?
Это не просто искусственно, это супер-противоестественно...
Здравствуйте, Ops, Вы писали:
...
Кстати, на том же самом ноуте — я вчера успешно запустил из под WMVare (точнее: WMVare Workstation 12.5.7)
ту версию убунты (16.04), котрая НЕ РАБОТАЕТ на голом железе
В принцыпе, можно было и 18.04-ю запустить таким же образом, но она ИМХО пока весьма сырая
Здравствуйте, AlexGin, Вы писали:
AG> AG>То есть (я выделил "самый смак") — работаем с Linux, а работь с файлами не можем. AG>Я верно понял?
Неверно. Там есть FS "системы", а есть смонтированные виндовые диски. С виндовыми работай как хочешь, а с лялиховой FS только изнутри лялиха, но не виндовыми средствами.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Мне удалось поднять, на WMVare 12.5, UBUNTU 16.04 — на том же самом компе, где эта же 16.04 не работала при установке на голое железо
Конечно, здесь есть и свои недостатки:
1) Проседание производительности, так как одеовременно с нашей ОС, работает одновременно на том же CPU и host ОС.
2) Я не могу даже видеть диски host ОС в нашей убунте.
Но — есть и приятные моменты:
a) Не надо перезагружаться, чтобы перейти в другую ОС.
b) Работает drag & drop с головной host ОС.
Здравствуйте, Ops, Вы писали:
Ops>Неверно. Там есть FS "системы", а есть смонтированные виндовые диски. С виндовыми работай как хочешь, а с лялиховой FS только изнутри лялиха, но не виндовыми средствами.
OK!
Такой вот вопрос:
Если (в моих приложениях для Linux) я буду работать с файлами — в стиле старого-доброго ANSI-C: fopen(); fwrite(); etc...
При этом, буду обращвться только к "своим" ext4 дискам, а НЕ к NTFS дискам.
То в этом случае, теоретически, всё должно везде отлично работать.
Практически, как я понимаю, здесь водятся Драконы...
Здравствуйте, AlexGin, Вы писали:
AG>При этом, буду обращвться только к "своим" ext4 дискам, а НЕ к NTFS дискам.
Это если ты смонтируешь отдельный ext4. "Свой" раздел там на базе NTFS, это обычная папка, но с дополнительными метаданными, из-за которых и не стоит туда лезть напрямую виндовыми программами.
AG>То в этом случае, теоретически, всё должно везде отлично работать. AG>Практически, как я понимаю, здесь водятся Драконы...
Не слышал о таком. Вроде изнутри все работает как надо, проблемы только при записи в корневой раздел минуя подсистему лялиха.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
AG>Мне удалось поднять, на WMVare 12.5, UBUNTU 16.04 — на том же самом компе, где эта же 16.04 не работала при установке на голое железо
Странно что, 16.04 не становится на железо, на которое становится 14.04.
AG>P.S. Также насчёт C++17 — удалось разрешить все проблемы: AG>http://rsdn.org/forum/cpp.applied/7154509.1
Здравствуйте, kdw, Вы писали:
kdw>Странно что, 16.04 не становится на железо, на которое становится 14.04.
Похоже, что авторы убунты попытались обработать какие-либо кейсы современного железа, вроде как где-то работает.
Но здесь получился облом.
Ранее не обрабатывали — и всё проходило.
Вот в таких случаях и понимаешь что в девизе "мелкомягких": "One Microsoft way" есть большая сила...
AG>>P.S. Также насчёт C++17 — удалось разрешить все проблемы: AG>>http://rsdn.org/forum/cpp.applied/7154509.1
Это совсем НЕ геморно, а вполне даже просто — если проделать это неоднократно (на рабочем компе, на домашнем, на ноуте).
Ну и никто же не настаивает ставить всегда все пакеты: ограничиться, например, свежими GCC 8 и clang 6.
Или та же утилита CMake — первый раз собрал из исходников и сформировал *.deb пакет. А дальше — ставь его через dpkg -i ...