сложности со сборкой systrace

Похоже, будто systrace.c уже определил in_addr_t своим дефайном.

Чтобы проверить - прогони его через cpp с теми же ключами, чтобы исправить - #undef in_addr_t перед #include <netinet/in.h>

да, Вы правы.

при конфигурировании systrace создался config.h, в котором, и записано(причем, дважды): #define in_addr_t unsigned long

и сопутствующий вопрос: на 64-бит архитектуре, in_addr_t ведь должен быть 32-бит, так?

зы посмотрев лог конфигурирования, заметил: checking for in_addr_t... no

осталось разобраться, почему тест провален.

следующая ошибка:

linux-ptrace-syscalls.c: In function ‘linux_add_pidstatus’:
linux-ptrace-syscalls.c:541:20: error: ‘CLONE_DETACHED’ undeclared (first use in this function)
linux-ptrace-syscalls.c:541:20: note: each undeclared identifier is reported only once for each function it appears in
linux-ptrace-syscalls.c: In function ‘linux_rewritefork’:
linux-ptrace-syscalls.c:1152:31: error: ‘CLONE_PTRACE’ undeclared (first use in this function)
linux-ptrace-syscalls.c:1156:46: error: ‘CLONE_VFORK’ undeclared (first use in this function)
linux-ptrace-syscalls.c: In function ‘linux_child_info’:
linux-ptrace-syscalls.c:1382:21: error: ‘CLONE_THREAD’ undeclared (first use in this function)
linux-ptrace-syscalls.c:1427:20: error: ‘CLONE_DETACHED’ undeclared (first use in this function)

идеи?

в логе конфигурирования есть такое:

checking sched.h usability... yes
checking sched.h presence... yes
checking for sched.h... yes
checking linux/sched.h usability... yes
checking linux/sched.h presence... yes
checking for linux/sched.h... yes

к тому же, внутри стражей HAVE_SCHED_H я добавил «#error 33» - выводится. значит стражи не при чем.

in_addr_t ведь должен быть 32-бит, так?

Да, на любой архитектуре.

осталось разобраться, почему тест провален.

Я бы посмотрел сам тест - vim configure +/in_addr_t

А shed.h включает linux/shed.h? Кто-то из них явно не включился, можно попробовать тот же #error.

А shed.h включает linux/shed.h?

вот как подключаются sched хидеры:

#ifdef HAVE_SCHED_H
//#error 33 <-- если раскомментить - выводится
#include <sched.h>
#else
#ifdef HAVE_LINUX_SCHED_H
#include <linux/sched.h>
#endif    /* HAVE_LINUX_SCHED_H */
#endif

в '/usr/include/sched.h' декларированы только функции sched + всякие макросы CPU_*, т.е. к проблеме не имеющие отношения.

так же, в этом хидере, происходит подключение '<bits/sched.h>' в котором собственно и определены константы в виде макросов при использовании которых возникает ошибка.

в '<bits/sched.h>' декларация этих констант защищена стражем __USE_GNU. эксперимента ради, внутрь этого стража я добавил вывод ошибки «#error 55» - но ничего не выводится. после, при запуске make я добавил «CPPFLAGS=-D__USE_GNU» - но все равно ничего не выводится. при этом, стока компиляции имеет вид «gcc -DHAVE_CONFIG_H -I. -I. -I. -D__USE_GNU -w -c linux-ptrace-syscalls.c», т.е. все валидно. похоже, этот макрос где-то андефайнится...

Попробуй _GNU_SOURCE вместо __USE_GNU.

нашел где дефайнится __USE_GNU. он дефайнится только в том случае, если определен _GNU_SOURCE.

заменил «CPPFLAGS=-D__USE_GNU» на «CPPFLAGS=-D_GNU_SOURCE» и сборка прошла успешно.

кто-нибудь может подсказать, в каких случаях должен дефайнится _GNU_SOURCE, и почему этого не происходит?

кто-нибудь может подсказать, в каких случаях должен дефайнится _GNU_SOURCE, и почему этого не происходит?

/usr/include/features.h смотри

CPPFLAGS

лучше все таки CFLAGS для си использовать

CPPFLAGS

CPP тут это c preprocessor

/usr/include/features.h смотри

смотрел. ничего интересного там нет.

разумеется. поэтому я отвечать и не стал.

в каких случаях должен дефайнится _GNU_SOURCE, и почему этого не происходит?

ответы: http://stackoverflow.com/questions/5582211/what-does-define-gnu-source-imply

http://stackoverflow.com/questions/7296963/gnu-source-and-use-gnu

http://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html

всем спасибо. вопрос закрыт.