>>А так, зачем мне может понадобится список всех возможных функций?
>
>Для проверки на совместимость, правда я тут уже задумался, может automake умеет
>проверять сам... ? Ну, сам automake/autoconf (точнее, этим занимается имменно autoconf) не очень много умеет - autoconf дает возможность (относительно :) ) легко написать макрос который проверит есть ли данная библиотека в системе на которой вы компилируете программу, есть ли в этой библиотеке данная функция - короче, при конфигурировании компиляции (это когда запускается скрипт ./configure перед запуском make) будет сделана попытка скомпилировать маленькую программу которая пытается слинковать указанную библиотеку и вызвать указанную функцию, если при компиляции/линковке произошли ошибки, значит библиотеки или функции нет в системе.
Кроме того, autoconf дает возможность построить хеадер файл config.h с #define'ами для каждой таким образом проверенной библиотеки/функции (типа, если ./configure определил что в системе есть накая feature, то там присутствует #define HAVE_<feature_name>, если нет - то нет #define'а).
Более того, вся эта бодягя с autoconf изначально была придумана, как я понимаю, именно для конфигурирования компиляции программ из одного исходного текста (source tree) на разных системах где похожие библиотеки, дающие похожую функциональность, немного по разному линкуются, лежат в разных каталогах, требуют разных опций компилятора, и т.д. - типа поставка исходников содержит скрипт ./configure которий обследует систему и строит Makefile (или дерево Makefile'ов) конкретно для этой системы, с командами вызова компилятора с подключением библиотек которые есть в этой системе, с правильными опциями компилятора/линкера. Или ./configure говорит что какой-то библиотеки не может найти и программа на этой системе не может быть построена без указания где эта библиотека лежит.
Ну, в общем, с точки зрения портабельных программ которые должны компилироваться на разных Unix'ах, не имеет смысла проверять наличие библиотеки/функции путем поиска установленной документации к этой функции на системе где эта программа разрабатывается. 'The Right Way' тут иметь ./configure скрипт который это сделает автоматически (и скорректирует Makefile'ы , если надо) прямо на системе где программа будет строится. А automake/autoconf - это тулзы которые облегчают построение такого ./config скрипта и, в случае automake, заготовок для Makefile'ов (файлы Mаkefile.am) с построенными зависимостями .c/.cpp файлов от нужных .h/.hpp файлов.
Да, процесс написания configure.in (или configure.ac) - исходного файла для autoconf - может казаться устаршающе сложным. Но по интернету можно найти много уже готовых макросов для autoconf для проверки разных features - например, когда мне надо было компилировать программу с pthreads на Линуксе, ФриБСД и Солярисе, я нашел макрос для autoconf который делает все необходимые преверки и подключает нужные библиотеки с нужными опциями компилятора на всех этих системах (и еще на нескольких других заодно).
