но make выдает кучу ошибок:

Искать ошибки в Makefile'е, естественно.

makefile генерируется cmake'ом.

Допустим, чужой файл зовётся foreign.c и в нём объявлена int main(int argc, char *argv[]); Тогда ты делаешь обёртку foreign-wrapper.c:

static int main(int argc, char *argv[]);
#include "foreign.c"

M_PI, unused и static м.б. во внешнем файле

extern int M_PI();
static int abc(void) __attribute((unused));

int abc()
{
        return M_PI();
}

Компилируем с -O1 и выше: gcc -S -O1 unused.c -Wall

	.file	"unused.c"
	.ident	"GCC: (GNU) 4.4.5 20101112 (Red Hat 4.4.5-2)"
	.section	.note.GNU-stack,"",@progbits

Функция исчезла вместе с зависимостями. Сообщений и ошибок нет.

M_PI();

M_PI — макрос, определенный в math.h. И почему его gcc не видит — парадокс.

Хрень какая-то непонятная. Вот так компилится без проблем:

#define M_PI 3.14159265358979323846
static int main(int argc, char *argv[]) __attribute((unused));
static void usage(void) __attribute((unused));
#define inline
#include "airmass.c"
#undef inline

а ты допиши до #include <math.h> строчку #define _USE_MATH_DEFINES

Какие-то проблемы с define-ами влияющими на доступность имен из math.h Тривиальный пример:

#include <features.h>
#undef __USE_BSD
#include <math.h>

static int abc(void) __attribute((unused));

int abc()
{
	return M_PI;
}

Имеем:

gcc -S unused.c 
unused.c: In function ‘abc’:
unused.c:9: error: ‘M_PI’ undeclared (first use in this function)
unused.c:9: error: (Each undeclared identifier is reported only once
unused.c:9: error: for each function it appears in.)

В math.h проверочка есть, которая и мешает (#if defined __USE_BSD || defined __USE_XOPEN). Можно попробовать во внешнем файле тоже поставить #include <math.h> (внутренний include мешать уже не будет).

Эта хрень — для M$ и c++

У меня и так обертка начинается с

#define __USE_XOPEN
#include <math.h>

Однако у меня такой вариант пролетает нормально:

#include <math.h>
#include <features.h>
#undef __USE_BSD
#include <math.h>

static int abc(void) __attribute((unused));

int abc()
{
        return M_PI;
}

Что еще стоит перед include <math.h> ?

Рекомендую попробовать добавить ключи -E -dD и посмотреть какой файл будет сгенерирован.

С этими ключами вот такие матюги:

make
Linking C executable apogee_control
CMakeFiles/apogee_control.dir/takepic.c.o: file not recognized: File format not recognized

Да хрен с ним, M_PI: и так работает.

Вообще-то не ожидалось, что команда будет запущена под make-ом, т.к. должен был сгенерироваться текстовый файл. Лучше было выдать одну команду и без -o file. Т.ч. диагностика про CMakeFiles/apogee_control.dir/takepic.c.o корректная. Получился не объектный, а текстовый файл который можно было проанализировать.

Сделал. Получаю (с принудиловкой):

<skipped>
# 349 "/usr/include/math.h" 3 4
<skipped>
#define M_PI 3.14159265358979323846
<skipped>
#define M_PI 3.14159265358979323846
<skipped>
# 795 "airmass.c" 2
# 804 "airmass.c"
#define DEG2RAD (M_PI/180.)
<skipped>
sinz=sin(z*(3.14159265358979323846/180.));

Без принудительного #define все тоже в порядке:

 sinz=sin(z*(3.14159265358979323846/180.));

Это файл .o который получен под make-ом или сгенерированный отдельно? Если отдельно, значит make либо запускает другую команду, либо устанавливает дикий environment. Забавный случай.

make матерится

make VERBOSE=1

Вот:

[ 14%] Building C object CMakeFiles/apogee_control.dir/am.c.o
/usr/bin/gcc  -DUSE_BTA -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE_VERSION=\"0.2.0\" -DGETTEXT_PACKAGE=\"apogee_control\" -I/usr/local/include/libapogee    -O3 -Wall -Werror -W -std=c99 -o CMakeFiles/apogee_control.dir/am.c.o   -c /home/eddy/Docs/SAO/Google_code/apogee-control/am.c
In file included from /home/eddy/Docs/SAO/Google_code/apogee-control/am.c:7:0:
/home/eddy/Docs/SAO/Google_code/apogee-control/airmass.c: В функции <<main>>:
/home/eddy/Docs/SAO/Google_code/apogee-control/airmass.c:1083:15: ошибка: <<M_PI>> undeclared (first use in this function)

Т.е. это M_PI именно в выводе отдельной команды запущенной в правильной директории? Или директория м.б. другой? Нет ли «лишних» math.h, feature.h и т.п. в /usr/local/include и т.п.? Можно добавить ключик -v (файлов в отличие от -E не сломает) и сравнить выдачу make с выдачей при запуске отдельной командой.

Я даже не представляю себе, как при помощи cmake заставить make генерировать вспомогательные (обработанные лишь препроцессором) файлы.

P.S. Если кому интересно, проект можно найти здесь (это — последний коммит, без сегодняшних правок).

-v просто увеличивает log сборки и не меняет что-либо иное, airmass.c что-то не видно

Все, сделал hg push

Проблема возникает из-за ключа -std=c99 который автоматически определяет __STRICT_ANSI__ и поехало. Такой код работает:

#define _BSD_SOURCE
#include <math.h>
//#define M_PI 3.14159265358979323846
static int main(int argc, char *argv[]) __attribute((unused));
static void usage(void) __attribute((unused));
#define inline
...

Можно также использовать #undef __STRICT_ANSI__ до math.h или убрать -std=c99

Я не могу компилять без -std=c99, т.к. иначе фигвамушки…

You are permitted to copy and distribute this program as much as you want, as long as you leave the source code, including this comments section, intact and unmodified.

Эмм, как бы это можно по-разному понять. Очень вероятно, что имелось в виду «this comment section intact and unmodified», а не весь сорс. Я бы советовал обратиться к автору.

-std=gnu99

Спасибо!

Оно самое.