QProcess и gcc -v

Вангую, что gcc -v выводит в stderr?

Правильно вангуешь.

readAllStandardError()

понял, спасибо. А с чем это связано, что они выводят в stderr вместо stdout?

stderr небуферизирован

тогда может кто знает, как сделать так, чтобы я через QProcess смогу clang -v посмотреть? А то всё равно не работает.

Покажи

$ clang -v 2> output
$ cat output

Пробовал : proc.start(«clang -v»), proc.start(«/bin/sh», QStringList() << "-c" << «clang -v»). Читать пробовал такими способами : readAll(), readAllStandardOutput(), readAllStandardError().

про способ с /bin/sh - он не видит clang, хотя моя консоль его прекрасно видит. С чем это связано и как починить это?

Может быть Qt что-то не то делает с PATH?

Для диагностики попробуйте

proc.start(«/bin/sh», QStringList() << "-c" << «echo $PATH»)

proc.start(«/bin/sh», QStringList() << "-c" << «whereis clang»)

proc.start(«/bin/sh», QStringList() << "-c" << «echo $PATH»)

/opt/Qt/5.5/gcc_64/bin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games\n

proc.start(«/bin/sh», QStringList() << "-c" << «whereis clang»);

clang: /usr/lib/clang /usr/include/clang /usr/share/clang /opt/cheerp/bin/clang\

Очень инетресный результат. whereis находит бинарник clang в /opt/cheerp/bin/ А при этом в PATH этого пути нет.

Ума не приложу как whereis его при этом находит...

По идее поможет добавление /opt/cheerp/bin/ в PATH в том месте откуда запускается Qt-приложение.

А откуда планируется использовать clang? Действительно из /opt/cheerp/bin/ или должен быть стандартный-системный в /usr/bin?

вообще планируется из /usr/bin . /opt/cheerp/bin - это папка транслятора с крестов на JavaScript

а почему тогда whereis clang не показывает /usr/bin, если clang-3.6 там лежит?

Явно не потому, т.к. буфферизацией можно управлять.

Ник знакомый... я тебя видел где-то %)

Тогда по какой причине, не подскажете?

Как именно работает whereis я честно говоря не знаю. Но то что он не находит clang в /usr/bin - это очень странно.

покажите как что етсь на эту тему в /usr/bin

ls -l /usr/bin/clang*

На дебиане результат вот такой:

lrwxrwxrwx 1 root root 25 мар 31  2015 /usr/bin/clang -> ../lib/llvm-3.6/bin/clang
lrwxrwxrwx 1 root root 27 мар 31  2015 /usr/bin/clang++ -> ../lib/llvm-3.6/bin/clang++
lrwxrwxrwx 1 root root 25 авг 18  2015 /usr/bin/clang-3.6 -> ../lib/llvm-3.6/bin/clang
lrwxrwxrwx 1 root root 27 авг 18  2015 /usr/bin/clang++-3.6 -> ../lib/llvm-3.6/bin/clang++
lrwxrwxrwx 1 root root 44 мар 31  2015 /usr/bin/clang-apply-replacements -> ../lib/llvm-3.6/bin/clang-apply-replacements
lrwxrwxrwx 1 root root 44 авг 18  2015 /usr/bin/clang-apply-replacements-3.6 -> ../lib/llvm-3.6/bin/clang-apply-replacements
lrwxrwxrwx 1 root root 31 мар 31  2015 /usr/bin/clang-check -> ../lib/llvm-3.6/bin/clang-check
lrwxrwxrwx 1 root root 31 авг 18  2015 /usr/bin/clang-check-3.6 -> ../lib/llvm-3.6/bin/clang-check
lrwxrwxrwx 1 root root 31 мар 31  2015 /usr/bin/clang-query -> ../lib/llvm-3.6/bin/clang-query
lrwxrwxrwx 1 root root 31 авг 18  2015 /usr/bin/clang-query-3.6 -> ../lib/llvm-3.6/bin/clang-query
lrwxrwxrwx 1 root root 32 авг 18  2015 /usr/bin/clang-rename-3.6 -> ../lib/llvm-3.6/bin/clang-rename
lrwxrwxrwx 1 root root 32 мар 31  2015 /usr/bin/clang-tblgen -> ../lib/llvm-3.6/bin/clang-tblgen
lrwxrwxrwx 1 root root 32 авг 18  2015 /usr/bin/clang-tblgen-3.6 -> ../lib/llvm-3.6/bin/clang-tblgen
lrwxrwxrwx 1 root root 30 мар 31  2015 /usr/bin/clang-tidy -> ../lib/llvm-3.6/bin/clang-tidy
lrwxrwxrwx 1 root root 30 авг 18  2015 /usr/bin/clang-tidy-3.6 -> ../lib/llvm-3.6/bin/clang-tidy

lrwxrwxrwx 1 root root 25 апр.  28  2015 /usr/bin/clang-3.6 -> ../lib/llvm-3.6/bin/clang
lrwxrwxrwx 1 root root 27 апр.  28  2015 /usr/bin/clang++-3.6 -> ../lib/llvm-3.6/bin/clang++
lrwxrwxrwx 1 root root 44 апр.  28  2015 /usr/bin/clang-apply-replacements-3.6 -> ../lib/llvm-3.6/bin/clang-apply-replacements
lrwxrwxrwx 1 root root 31 апр.  28  2015 /usr/bin/clang-check-3.6 -> ../lib/llvm-3.6/bin/clang-check
lrwxrwxrwx 1 root root 31 апр.  28  2015 /usr/bin/clang-query-3.6 -> ../lib/llvm-3.6/bin/clang-query
lrwxrwxrwx 1 root root 32 апр.  28  2015 /usr/bin/clang-rename-3.6 -> ../lib/llvm-3.6/bin/clang-rename
lrwxrwxrwx 1 root root 32 апр.  28  2015 /usr/bin/clang-tblgen-3.6 -> ../lib/llvm-3.6/bin/clang-tblgen
lrwxrwxrwx 1 root root 30 апр.  28  2015 /usr/bin/clang-tidy-3.6 -> ../lib/llvm-3.6/bin/clang-tidy

Linux Mint 17.3

Странно, что именно самого clang то и нет... Есть только clang-3.6. Но разве sh не найдёт его по имени clang?

По общепринятому соглашению в stdout выводится только то что является основным результатом работы программы, если он текстовый.

Так например поступает компилятор в режиме препроцессора clang -E.

Если stdout перенаправлен - то может выводиться и бинарный результат.

Однако метаинформация (прогресс, предупреждения, информация о версии и прочее) выводится в stderr, чтоб можно было отделить результат от метаинформации, перенаправаи результат в одно место, а метаинформацию в другое.

Не найдёт, он просматривает встроенные команды, определённые в shell функции и пути в path. Никакого додумывания.

Вам скорее всего надо установить не только пакет clang-3.6 с конкретной версией но и общий пакет clang.

/tmp$ dpkg -S /usr/bin/clang
clang: /usr/bin/clang
/tmp$ dpkg -S /usr/bin/clang-3.6
clang-3.6: /usr/bin/clang-3.6

Если у программы явным образом запрашивают версию, то вывод версии будет основным результатом работы программы или метаинформацией?

Это должен быть основной результат. (Например, так делают ls, bash, less и многие другие)

Попробовал - clang делает также.

Только запрос версии у него это --version, а не -v

-v - это включение verbose-режима (что по сути выдача метаинформации) и оно вполне сочетается с другими ключами, например -E.

И видимо в качестве исключения (или в качестве мелкого бага) если указан только ключ -v то после выдачи начальной метаинформации он не пишет

clang: error: no input files

короче, в репах лежит пакет clang-3.6, который у меня и был установлен. Но вот пакет clang есть только в clang-3.4. И по запросу clang запускается clang-3.4.

Мне что, линк делать /usr/bin/clang -> /usr/bin/clang-3.6? Ранее у меня алиас стоял в консоли.

Наверное стоит пояснить, почему меня алиас не устраивает. Утилита на Qt, делает запросы в систему и получает версии разных утилит : компиляторов, валгриндов всяких и так далее.

Так вот, ввиду того, что пакет clang есть далеко не для всех версий пакета clang, то что делать? Самому писать вручную парсер по типичным папкам? Мейнтейнерам стучать, чтобы добавили пакет clang к clang-3.6?

И ещё вопрос : можно ли как-то перенаправить пакет clang, чтобы вызывал clang-3.6 вместо clang-3.4?

Сам пакет clang и делает этот link. Если сделать линк вручную - будет 2 проблемы: во-первых в будущем пакетный менеджер сможет испытывать затруднения при установке пакета clang другой версии, а во-вторых видя наличие clang - утилиты будут ожидать что есть и clang++ и возможно куча каких-то ещё ссылок полный список которых знают только разработчики да мантейнер пакета.

Пакеты clang-3.? могут быть установлены одновременно. А вот пакет clang может быть установлен только один и это определяет на какую версию он ссылается.

Если подключено несколько репозиториев - может быть выбор:

/tmp$ apt list -a clang
Вывод списка… Готово
clang/experimental 1:3.7-34~exp1 i386
clang/testing,unstable 1:3.6-33 i386 [может быть обновлён до: 1:3.6-27~exp2]
clang/now 1:3.6-27~exp2 i386 [установлен, может быть обновлён до: 1:3.6-33]
clang/stable 1:3.5-25 i386

Если нужной версии в списке нет - я обычно ищу вначале здесь https://packages.debian.org/clang

потом на packages.ubuntu.com (во всех выпусках), а потом гуглом или через ubuntuupdates.org ищу типа clang ppa.

Пакеты близкой версии от другого дистрибутива в 70% случаев просто работают, ещё в 25 просто не ставятся или ставятся с ошибкой (в обоих случаях достаточно просто удалить), и совсем редко ставятся но не работают, так что риск невелик.

Например, чтобы разделять то что выводится. Как бы назначения stdout и stderr говорят за себя. Релевантный вывод, который можно скормить другой программе - в stdout, информацию об ошибках, чтобы другая программа не получила чего-то не того, в stderr.

Только запрос версии у него это --version, а не -v

Блин, точно. И у gcc так же, и по --version пишет в stdout. А -v это:

`-v'
     Print (on standard error output) the commands executed to run the
     stages of compilation.  Also print the version number of the
     compiler driver program and of the preprocessor and the compiler
     proper.

Вывод: надо читать маны прежде чем писать на форум. И мне, и топикстартеру. :DD

Да я просто даже не предполагал, что версия может выводиться в stderr