Проблема была предотвращена установкой переключателя компиляции --with-local-prefix=/usr
сценария оболочки configure
. По умолчанию используется /usr/local
, в то время как Ubuntu хранит искомые файлы в /usr
. Это позволило исправить фатальные ошибки в другой компиляции из исходников HDF5 (см. https://unix.stackexchange.com/a/346171/132913)
Однако эта настройка не рекомендуется. См. GCC on-line configure help:
--with-local-prefix=dirname
Укажите каталог установки для локальных включаемых файлов. По умолчанию это /usr/local. Укажите эту опцию, если вы хотите, чтобы компилятор искал каталог dirname/include для локально установленных заголовочных файлов вместо /usr/local/include.
Вы должны указать --with-local-prefix только в том случае, если ваш сайт имеет другое соглашение (не /usr/local) о том, куда помещать файлы, специфичные для сайта.
Значением по умолчанию для --with-local-prefix является /usr/local, независимо от значения параметра --prefix. Указание --prefix не влияет на то, в каком каталоге GCC ищет локальные заголовочные файлы. Это может показаться контринтуитивным, но на самом деле это логично.
Цель параметра --prefix - указать, куда устанавливать GCC. Локальные заголовочные файлы в каталоге /usr/local/include - если вы поместите их в этот каталог - не являются частью GCC. Они являются частью других программ - возможно, многих других. (GCC устанавливает свои собственные заголовочные файлы в другой каталог, который основан на значении --prefix.)
И каталог include с локальным префиксом, и каталог include с префиксом GCC являются частью каталогов "system include" GCC. Хотя эти два каталога не являются фиксированными, их необходимо искать в правильном порядке для корректной обработки директивы include_next. Каталог include с локальным префиксом ищется перед каталогом include с префиксом GCC. Другой особенностью системных каталогов include является то, что для заголовков в этих каталогах отключены педантичные предупреждения.
Некоторые макросы autoconf добавляют опцию -I directory в командную строку компилятора, чтобы обеспечить поиск каталогов, содержащих заголовки установленных пакетов. Если каталог является одним из системных включаемых каталогов GCC, GCC будет игнорировать опцию, чтобы системные каталоги продолжали обрабатываться в правильном порядке. Это может привести к порядку поиска, отличному от указанного, но поиск в каталоге все равно будет выполнен.
GCC автоматически ищет обычные библиотеки, используя GCC_EXEC_PREFIX. Таким образом, когда один и тот же префикс установки используется и для GCC, и для пакетов, GCC будет автоматически искать и заголовки, и библиотеки. Это обеспечивает простую в использовании конфигурацию. GCC ведет себя аналогично тому, как если бы он был установлен как системный компилятор в /usr.
Сайты, которым необходимо установить несколько версий GCC, могут не захотеть использовать описанную выше простую конфигурацию. Можно использовать опции --program-prefix, --program-suffix и --program-transform-name для установки нескольких версий в один каталог, но может быть проще использовать разные префиксы и опцию --with-local-prefix, чтобы указать расположение файлов, специфичных для сайта, для каждой версии. Тогда пользователям придется явно указывать расположение локальных библиотек сайта (например, с помощью LIBRARY_PATH).
Одно и то же значение можно использовать и для --with-local-prefix, и для --prefix, если оно не является /usr. Это можно использовать, чтобы избежать поиска по умолчанию в /usr/local/include.
Не указывайте /usr в качестве --with-local-prefix! Каталог, который вы используете для --with-local-prefix, не должен содержать стандартных заголовочных файлов системы. Если он будет содержать их, некоторые программы будут неправильно скомпилированы (включая GNU Emacs на некоторых объектах), поскольку это отменит и аннулирует исправления заголовочных файлов, сделанные сценарием fixincludes.
Есть основания полагать, что люди, использующие эту опцию, используют ее на основе ошибочных представлений о том, для чего она нужна. Люди используют его так, как будто он указывает, куда устанавливать часть GCC. Возможно, они делают такое предположение, потому что при установке GCC создается каталог.
Я рассмотрю эти несоответствия в другом сообщении при первой же возможности.
Покопавшись вzshall(1)
(для zsh 5.4.2
, я не знаю, когда эта функция была добавлена ), можно найти
file-list
This style controls whether files completed using the standard
builtin mechanism are to be listed with a long list similar to
ls -l. Note that this feature uses the shell module zsh/stat
for file information; this loads the builtin stat which will
replace any external stat executable. To avoid this the follow-
ing code can be included in an initialization file:
zmodload -i zsh/stat
disable stat
The style may either be set to a `true' value (or `all'), or one
of the values `insert' or `list', indicating that files are to
be listed in long format in all circumstances, or when attempt-
ing to insert a file name, or when listing file names without
attempting to insert one.
Итак, используя это, где в последней командеls blah/
была введена вкладка :
$ PS1='%% ' zsh -f
% autoload -U compinit && compinit
% zstyle ':completion:*' file-list all
% mkdir blah
% touch blah/{a,b,c}
% ls blah/
-rw-r--r-- 1 jhqdoe grp 0 Sep 10 08:36 a
-rw-r--r-- 1 jhqdoe grp 0 Sep 10 08:36 b
-rw-r--r-- 1 jhqdoe grp 0 Sep 10 08:36 c