autoconf конфигурирует результаты в ошибках компиляции заголовка C std lib
Я пытаюсь создать проект, который поставляется с системой сборки automake/autoconf. Это хорошо используемый проект, поэтому я скептически отношусь к проблеме со скриптами конфигурирования, make-файлами или кодом, когда я их получил. Вероятно, это какая-то проблема окружения, пути, флага и т. Д. - что-то на моем конце, когда я просто запускаю правильные команды с правильными параметрами.
Шаг конфигурации, кажется, завершается удовлетворительным образом. Когда я запускаю make, мне показывают набор ошибок, в основном следующих типов:
error: ‘TRUE’ undeclared here (not in a function)
error: ‘struct work’ has no member named ‘version’
error: expected ‘)’ before ‘PRIu64’
Давайте сосредоточимся на последнем, которое я потратил на исследование - и я подозреваю, что все ошибки связаны с отсутствующими определениями. Очевидно, что доступные для печати расширенные определения из заголовочного файла стандартной библиотеки C inttypes.h не найдены. Однако на этапе настройки все утверждается, что все в порядке:
configure:4930: checking for inttypes.h
configure:4930: /usr/bin/x86_64-linux-gnu-gcc -c -g -O2 conftest.c >&5
configure:4930: $? = 0
configure:4930: result: yes
Все флаги INTTYPES установлены правильно, если я загляну в выходные переменные confdefs.h, config.h, config.log и т.д.:
HAVE_INTTYPES_H='1'
#define HAVE_INTTYPES_H 1
Проблема одна и та же, будь то встроенная сборка или кросс-компиляция (для arm-linux-gnueabihf, он же armhf).
Исходный.c файл, о котором идет речь, действительно имеет config.h, включенный, как и следовало ожидать, который, по моему пониманию через механику макросов m4, должен был добавить
#include <inttypes.h>
линия. Да, как вы можете спросить, если я сам введу эту строку в файл.c, он, кажется, будет работать, и ошибки PRIu64 исчезнут.
У меня остается вопрос, как отладить проблему такого типа - по сути, все, что я знаю, говорит мне, что я выполнил настройку правильно, но у меня остался фиктивный процесс создания. Помимо того, что я пробовал каждый./configure трюк и трюк, которые я могу найти, я начал смотреть на сам сгенерированный Makefile.in, но пока ничего. Также выясняется, как заставить препроцессор C сообщать мне, какие заголовочные файлы он на самом деле вставляет.
РЕДАКТИРОВАТЬ: я подтвердил, что механизм -DHAVE_CONFIG_H выглядит хорошо через configure, config.log, Makefile и т. Д.
2 ответа
autoconf не производит автоматически #include директивы. Вы должны сделать это самостоятельно на основе HAVE_* макросы. Так что вам придется добавить что-то вроде этого:
#ifdef HAVE_INTTYPES_H
# include <inttypes.h>
#endif
Если эти строки появляются в confdefs.h, временный заголовочный файл, используемый configure сценарии, это освобождает ваше приложение от выполнения этих #includes. Если configure пишет их confdefs.h, это исключительно в интересах других configure тесты, а не для использования приложения.
Первый забег make -n для цели, которая потерпела неудачу. Это наверное какой то .o файл; вам может понадобиться немного изменить его путь.
Теперь у вас есть команда, используемая для компиляции вашего файла. Если вы не нашли проблему, размышляя над этой командой, попробуйте запустить ее, добавив -E заставить текст препроцессора выводить текст вместо вызова компилятора.
Обратите внимание, что теперь .o файл будет текстовым, и вы должны восстановить его без -E потом.
Вы можете найти некоторые флаги препроцессора полезными для получения более подробной информации: -dM или -dD, или другие.