Назначение __USE_XOPEN2K8 и как его установить?

Я пытаюсь скомпилировать стек gtk (последняя версия gtk2, 2.24), и я получаю кучу ошибок, которые кажутся связанными. А именно, __locale_t не может быть найдено из string.h и time.h, и LC_ALL_MASK тоже не может быть найдено (должно быть в locale.h).

Я обнаружил, что все эти проблемы связаны с тем, что __USE_XOPEN2K8 не определен #. Для чего нужен __USE_XOPEN2K8 и как его правильно установить?

Например, мне нужно передать флаг в ./configure для glib, gtk, ... или мне нужно что-то изменить уже при сборке gcc или glibc̲? Я бы предпочел не просто добавлять #define __USE_XOPEN2K8 в свои источники, не зная, что он делает. Примечание. Я использую gcc-4.6.3 и glibc-2.16.0, которые установлены с нестандартным префиксом, поскольку я пытаюсь заставить библиотеки gtk работать на более старой CentOS (5.8), которая включает только более старые версии.

Также обратите внимание, что отсутствующий __locale_t упоминается в нескольких местах, например. отчет об ошибке. Я мог бы просто добавить #include <xlocale.h> в некоторые файлы, но кажется правильным решением было бы установить __USE_XOPEN2K8.

Изменить: я нашел эту тему с описанием эта проблема. Судя по всему, заголовки хост-системы "включаются" в заголовки нового компилятора. Связанный пост предлагает отредактировать functions.h. Кто-нибудь знает, нужно ли мне после этого перекомпилировать gcc/glibc (и как заставить его подбирать новые feature.h, а не перезаписывать его)?


gcc glibc
person jdm    schedule 14.12.2012    source источник
comment
По ссылке, которую вы включили, проблема заключается в том, что при сборке gcc он создавал копии файлов заголовков системной библиотеки C вместо заголовков из вашего пользовательского glibc. Ключ будет заключаться в том, чтобы указать сборку gcc на вашу сборку glibc. К сожалению, я не совсем уверен, как это сделать, иначе я бы отправил ответ. Глядя на параметры настройки gcc, --oldincludedir или --with-build-sysroot могут быть в правильном направлении, но я в основном предполагаю.   -  person rra    schedule 18.03.2013
comment
@rra - я все еще компилирую последнюю версию GCC на RHEL5 и запускаю ее в более поздних ОС. Это требует ручного удаления нескольких заголовков в include-fixed; а именно features.h, pthread.h, wchar.h, sys/stat.h и bits/string2.h. Насколько я могу судить, fixincludes на самом деле были breakincludes уже как минимум десять лет.   -  person Nemo    schedule 05.05.2020

Ответы (4)


arrow_upward
6
arrow_downward

Когда определено __USE_GNU, всегда также определяется __USE_XOPEN2K8, если вы явно не определяете или не отменяете определение этих макросов, чего вы не должны делать. Используйте макросы _GNU_SOURCE, _XOPEN_SOURCE {500,600,700,...} и т. д. перед включением первого заголовка. Это рекомендуемый способ выбора набора функций GNU в заголовках glibc вместе с его определением в командной строке (-D_GNU_SOURCE).

В качестве альтернативы вы можете попробовать указать использование расширения GNU для gcc с помощью переключателя командной строки -std (gnu89, gnu99 и т. д.).

person Michael Foukarakis    schedule 24.09.2013

arrow_upward
3
arrow_downward

В CentOS7 с gcc 4.6 нам пришлось использовать -D_XOPEN_SOURCE=700 -D__USE_XOPEN2K8

person jluu    schedule 20.06.2016

arrow_upward
2
arrow_downward

Макросы glibc __USE_* — это внутренние макросы, используемые для реализации выбора функций. Поддерживаемый способ их установки — определить макросы тестирования функций, такие как -D_GNU_SOURCE:

Эти макросы необходимы, потому что glibc поддерживает множество стандартов и расширений GNU, и эти функции конфликтуют друг с другом, в основном из-за отсутствия пространств имен в C. Например, C и POSIX позволяют вам определить глобальную переменную с именем secure_getenv (потому что идентификатор не зарезервирован и не используется иным образом в соответствии с этими стандартами), но такая программа не будет работать, если вы скомпилируете с _GNUS_SOURCE и включите <stdlib.h>, потому что glibc предоставляет функцию с именем secure_getenv.

<xlocale.h> — это внутренний заголовок glibc (об этом говорится в комментарии в заголовочном файле), и он больше не будет доступен в glibc 2.26.

person Florian Weimer    schedule 24.07.2017

arrow_upward
0
arrow_downward

Насколько я знаю, когда мы используем компилятор, его поведение зависит от некоторых макросов ENV, которые сохранены в feature.h. Таким образом, вы можете настроить свой компилятор, изменив его. Во-первых, вам нужно использовать g++ -E youfile > log, чтобы увидеть, какой файл feature.h использует ваш компилятор, а затем использовать g++ -E -dM /path/to/feature.h>log, чтобы найти __USE_XOPEN2K8, если вы не можете его найти. Добавьте #define __USE_XOPEN2K8 1 в конец файла. Возможно, вы неправильно настроили некоторые настройки при установке компилятора.

person williamchen    schedule 27.02.2016