Путь к KDE4: CMake — новая make-система для KDE4

Да, ссылки на то, что-де злобные альтовцы на этот раз захачили autotools так, что они начали все правильно собирать, не проканывают: после копирования на целевой машине файлики пересоздавались при помощи libtoolize --copy --force; aclocal; autoconf; automake. Ну, так, на всякий случай...

2all: кстати, у кого mingw под руками есть: проверьте, пожалуйста, работосбособность всей конструкции, я не уверен, что я до конца правильно результаты этого ACX_PTHREAD использовал.

> Какой вы нудный, право слово.

Меня интересует только строка линковки, т.е.

gcc -pthread -g -O2 -o cxxtest main.o -lstlport ./.libs/libtest.a

При неправленном копиляторе, там в зависимостях обязательно (!!!) (при такой строке как выше) появится зависимость от libstdc++.so.V;

(gcc-4.1.1/gcc/cp/g++spec.c) [pre] ... #ifndef LIBSTDCXX #define LIBSTDCXX "-lstdc++" #endif ... /* Add `-lstdc++' if we haven't already done so. */ if (library > 0) { arglist[j] = saw_profile_flag ? LIBSTDCXX_PROFILE : LIBSTDCXX; if (arglist[j][0] != '-' || arglist[j][1] == 'l') added_libraries++; j++; } [/pre]

(Это так с gcc 2.93.x до 4.1.1; сомневаюсь, что это поменялось в 4.1.2; другое LIBSTDCXX определяется только в S390 и DejaGNU); Флаг library выключается только при -nostdlib или -nodefaultlibs, и тогда необходимо самому позаботится о старт/стоп объектниках.

Т.е. либо это правленный компилятор, либо autotools передает компилятору не то, что показывает. (это еще одна вещь, за которую я не уважаю autotools --- увидеть, что было передано компилятору очень трудно).

> Да, ссылки на то, что-де злобные альтовцы на этот раз захачили autotools так,

Это тянет на компилятор, даже не на specs. Autotools --- только если они чего-то спрятали (т.е. показали не то что передали gcc).

> > Да, ссылки на то, что-де злобные альтовцы на этот раз захачили autotools так, Это тянет на компилятор, даже не на specs. Autotools --- только если они чего-то спрятали (т.е. показали не то что передали gcc).

Проверить можно:

strings `which c++` | grep stlport

>> Какой вы нудный, право слово.

> Меня интересует только строка линковки, т.е. > gcc -pthread -g -O2 -o cxxtest main.o -lstlport ./.libs/libtest.a

Таки с какой радости _gcc_ (не g++!) будет прилинковывать libstdc++ по умолчанию? Впрочем, я <b>еще раз повторяю</b>: если вы укажете кошерную с вашей точки зрения строчку линковки, её можно будет пропихнуть либтулу.

> Т.е. либо это правленный компилятор, либо autotools передает компилятору не то, что показывает. (это еще одна вещь, за которую я не уважаю autotools --- увидеть, что было передано компилятору очень трудно).

Везде заговор. И на убунте, и на альте... На дебиане-3.1 тест этот не проходит, но там libstdc++ прилинкован прямо к libstlport.so в пакете libstlport4.6-dev-4.6.2-2:

builder@bdeb31:~/autot++$ ldd /usr/lib/libstlport.so libpthread.so.0 => /lib/tls/libpthread.so.0 (0x400cf000) libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x400de000) libm.so.6 => /lib/tls/libm.so.6 (0x40199000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x401bb000) libc.so.6 => /lib/tls/libc.so.6 (0x401c4000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) builder@bdeb31:~/autot++$ _

Так что, или вы приводите пример системы (желательно, линукса, фряхи или macosx, чтобы под руками были), где добиться желаемого эффекта невозможно (прилинковать только [нормально собранный] stlport, не прилинковывая stdc++), или я завершаю дискуссию, как беспредметную. Впрочем, можете выдумать ещё какой-нибудь пример, почему вас не устраивают autotools; вышеприведённые, извините, меня не впечатлили.

> Таки с какой радости _gcc_

Ну вот и ответ. Просто использование комилятора C для сборки C++-программы проходит для gcc, но не часто при других компиляторах (из-за вопросов с point of instantiation, EH, static ctors/dtors).

(устало) воспользуйтесь другим линкером. См. выше про кошерную строчку линковки. Использование или неиспользование libtool и autotools в целом никак не влияет на наличие или отсутствие проблем в этом месте.

На этом примере можно разобрать проблемы autotools.

Минимальные команды для сборки: <pre> c++ -pthread -g -c -I${HOME}/STLport.lab/STLport/stlport -o main.o main.cc gcc -pthread -g -L${HOME}/STLport.lab/STLport/lib -Wl,--rpath=${HOME}/STLport.lab/STLport/lib -o cxxtest main.o -lstlport </pre>

Забудем, что Ваше предложение по configure.ac не прошло:

<pre> configure.ac:6: error: possibly undefined macro: AM_INIT_AUTOMAKE If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:13: error: possibly undefined macro: AC_PROG_LIBTOOL </pre>

(2.53, AC_PREREQ(2.59) не дало разумного вывода; впрочем, ситуация с 2.60a та же ;-) ).

Продолжаем.

<pre> automake configure.ac: no proper invocation of AM_INIT_AUTOMAKE was found. configure.ac: You should verify that configure.ac invokes AM_INIT_AUTOMAKE, configure.ac: that aclocal.m4 is present in the top-level directory, configure.ac: and that aclocal.m4 was recently regenerated (using aclocal). configure.ac: required file `./install-sh' not found configure.ac: required file `./missing' not found Makefile.am: required file `./INSTALL' not found Makefile.am: required file `./NEWS' not found Makefile.am: required file `./README' not found Makefile.am: required file `./AUTHORS' not found Makefile.am: required file `./ChangeLog' not found Makefile.am: required file `./COPYING' not found configure.ac:8: required file `config.h.in' not found Makefile.am: required file `./depcomp' not found /usr/share/automake-1.9/am/depend2.am: am__fastdepCXX does not appear in AM_CONDITIONAL /usr/share/automake-1.9/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL </pre>

<pre> ./configure ./configure: line 1625: AM_INIT_AUTOMAKE: command not found checking for g++... g++ checking for C++ compiler default output file name... a.out checking whether the C++ compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes ./configure: line 2308: AC_PROG_LIBTOOL: command not found ./configure: line 2311: ACX_PTHREAD: command not found configure: creating ./config.status config.status: creating Makefile config.status: error: cannot find input file: config.h.in </pre>

Т.е. для начала сборки мы должны запустить четыре программы: autoconf, automake, configure, make.

Хмм. После смены automake на 1.9.6 и libtool на 1.5.22 у меня перестал генериться Makefile.in (при autoconf 2.60a). В общем я за 15 минут не справился. Видимо, кроме детальных инструкцияй, там остались еще пляски с бубном и махание кроличьей лапкой над версиями autoconf/automake.

Итого: четыре программы для старта проекта; сакральное знание о версиях этих программ; при добавлении нового файла надо будет запустить три программы и полностью пересобрать проект (очень удобно для разработчика!); все временные (генерённые) файлы расположились в рабочей директории; какую задачу решала здесь пятая программа (libtool) мне осталось неясным.

Специально хочу подчеркнуть, что я сознательно не лазил в потроха auto* чтобы понять что надо докрутить, чтобы это работало. Старательно изображал из себя endlooser'а.

Это чтобы сделать ДВЕ СТРОКИ! Для сравнения (plain GNU make; впрочем это будет работать на половине make'ов):

<pre> CXXFLAGS += -pthread -I$${HOME}/STLport.lab/STLport/stlport CFLAGS += -pthread LDFLAGS += -L$${HOME}/STLport.lab/STLport/lib -Wl,--rpath=$${HOME}/STLport.lab/STLport/lib -lstlport

cxxtest: main.o ${LINK.c} $^ </pre>

Одна программа для построения проекта. Переносимость несколько лучше, чем с autotools.

Более навороченные вещи могли бы выглядить примерно так:

<pre> $ cat Makefile SRCROOT := ../../.. COMPILER_NAME := gcc

PRGNAME = test SRC_CC = test.cc

include ${SRCROOT}/Makefiles/top.mak </pre>

Это всего лишь для иллюстрации утверждения autotools == bloatware. И refactoring тут уже не поможет.