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

> Покажите строчку линковки --- ибо применительно к autotools --- НЕ ВЕРЮ (ну, или ldd на результат).

Просто капец какой-то... Станиславский на мою голову...

Итого:

alex@lythos tmp/c++/autot++ $ cat main.cc
#include <iostream>

int main(void)
{
std::cout << "Hello, world!" << std::endl;
return 0;
}
alex@lythos tmp/c++/autot++ $ cat configure.ac
# -*- Autoconf -*-
# Process this file with autoconf to produce a configure script.

AC_PREREQ(2.59)
AC_INIT(TestCXXProject, 1.0.0)
AM_INIT_AUTOMAKE
AC_CONFIG_SRCDIR([main.cc])
AC_CONFIG_HEADER([config.h])
AC_CONFIG_FILES([Makefile])

# Checks for programs.
AC_PROG_CXX

# Checks for libraries.

# Checks for header files.

# Checks for typedefs, structures, and compiler characteristics.

# Checks for library functions.
AC_OUTPUT
alex@lythos tmp/c++/autot++ $ cat Makefile.am
bin_PROGRAMS = cxxtest

cxxtest_SOURCES = main.cc
AM_CXXFLAGS = -pthread
AM_CPPFLAGS = -I/usr/include/stlport
cxxtest_LDADD = -lstlport

alex@lythos tmp/c++/autot++ $ make clean; make
test -z "cxxtest" || rm -f cxxtest
rm -f *.o
make all-am
make[1]: Entering directory `/home/alex/tmp/c++/autot++'
if g++ -DHAVE_CONFIG_H -I. -I. -I. -I/usr/include/stlport -pthread -g -O2 -MT main.o -MD -MP -MF ".deps/main.Tpo" -c -o main.o main.cc; \
then mv -f ".deps/main.Tpo" ".deps/main.Po"; else rm -f ".deps/main.Tpo"; exit 1; fi
g++ -pthread -g -O2 -o cxxtest main.o -lstlport
make[1]: Leaving directory `/home/alex/tmp/c++/autot++'
alex@lythos tmp/c++/autot++ $ ldd cxxtest
linux-gate.so.1 => (0xffffe000)
libstlport.so.5.0 => /usr/lib/libstlport.so.5.0 (0xb7e7f000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7e74000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb7e5f000)
libc.so.6 => /lib/libc.so.6 (0xb7d3f000)
libm.so.6 => /lib/libm.so.6 (0xb7d1a000)
/lib/ld-linux.so.2 (0x80000000)
alex@lythos tmp/c++/autot++ $ _

Аналогично для библиотек, собранных libtool'ом. В крайнем случае, может понадобится -nostdlib/-nodefaultlibs с подсовыванием crt*.o и прочей потребной случаю машинерии, которая, на самом деле, будет одинакова, что пользовались вы autotools'ами, что не пользовались.

Что-то, честно говоря, после таких выкриков "НЕ ВЕРЮ" не очень хочется обсуждать с вами что-либо по данной теме. Мне кажется, вы просто не знакомы с предметом.

P.S. Да, желающим повторить подвиг разведчика: не забудьте, что наличие autoscan и autoheader сильно упрощают жизнь.

Замечание для ценителей точности и начинающих:

Некоторые флаги я захардкодил прямо в Makefile.am. Для действительно переносимой сборочной среды неплохо в configure.ac вставить проверки на расположение заголовочных файлов STLPort'а и соответствующей библиотеки, ну и про корректную проверку на флаги многопоточности не забыть. Примеры того, как это делать, есть в документации и различных архивах макросов, например, вот здесь: http://autoconf-archive.cryp.to/acx_pthread.html

Кому Вы парите мозги, Козюльский?

> g++ -pthread -g -O2 -o cxxtest main.o -lstlport make[1]: Leaving directory `/home/alex/tmp/c++/autot++' alex@lythos tmp/c++/autot++ $ ldd cxxtest linux-gate.so.1 => (0xffffe000) libstlport.so.5.0 => /usr/lib/libstlport.so.5.0 (0xb7e7f000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7e74000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7e5f000) libc.so.6 => /lib/libc.so.6 (0xb7d3f000) libm.so.6 => /lib/libm.so.6 (0xb7d1a000) /lib/ld-linux.so.2 (0x80000000)

Строка `g++ -pthread -g -O2 -o cxxtest main.o -lstlport` НЕ МОЖЕТ НЕ ДАТЬ зависимость libstdc++.so.6 => /usr/lib/libstdc++.so.6 И её статической тоже быть не должно --- libgcc_s.so.1 специфично для сборки с динамической libstdc++. А вот -nostdlib обяжет еще startup/finit .o's добавить. Я должен после этого верить?

> Строка `g++ -pthread -g -O2 -o cxxtest main.o -lstlport` НЕ МОЖЕТ НЕ ДАТЬ зависимость libstdc++.so.6 => /usr/lib/libstdc++.so.6 И её статической тоже быть не должно --- libgcc_s.so.1 специфично для сборки с динамической libstdc++. А вот -nostdlib обяжет еще startup/finit .o's добавить. Я должен после этого верить?

(Пожимая плечами) мы не в храме, чтобы верить.

alex@lythos tmp/c++/autot++ $ g++ -v
Using built-in specs.
Target: i586-alt-linux
Configured with: ../configure --host=i586-alt-linux --build=i586-alt-linux --target=i586-alt-linux --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var/lib --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --disable-dependency-tracking --without-included-gettext --program-suffix=-4.1 --with-slibdir=/lib --enable-shared --enable-__cxa_atexit --enable-threads=posix --enable-checking=release --with-system-zlib --without-included-gettext --disable-multilib --enable-languages=c,c++,fortran,objc,obj-c++,treelang,java,ada --enable-java-awt=gtk --disable-plugin --with-native-libdir=/usr/lib/gcj-4.1 --enable-libgcj-multifile --with-cpu=i586 --with-arch=i586 --with-tune=pentium4
Thread model: posix
gcc version 4.1.1 20061011 (ALT Linux, build 4.1.1-alt10)
alex@lythos tmp/c++/autot++ $ rpm -qf /usr/bin/ldd
glibc-utils-2.5-alt3
alex@lythos tmp/c++/autot++ $ _

Проверяйте.

Вполне допускаю, что в каких-либо других системах, особенно, со старыми компиляторами, потребуются еще какие-нибудь флаги, мне, повторю, было лень писать совершенно корректный пример. Ну и поменьше безапелляционности, натурально, разговаривать тяжело. А за "козюльского" при случае можно и в табло схлопотать.

> alex@lythos tmp/c++/autot++ $ g++ -v

> Using built-in specs.

> ...

> Проверяйте.

Это как раз подтверждение неудовлетворительности autotools; видимо, это было достигнуто следующим образом:

бойцы Alt-Linux'а прописали libstlport отдельным правилом в specs-file'е gcc (see 'gcc -dumpspecs'). Видимо, это оказалось самым разумным компромиссом в их неравной борьбе с autotools. Хотя... скорее, это правка внутри gcc/cp/g++spec.c, что еще веселее.

Какой вы нудный, право слово. Вот, слегка подкорректированный пример, с учётом сказанного выше про корректность теста на pthreads (так и так надо было причесывать проверку). Специально проверил не только у себя на альте, но и на убунте610

Итого:

builder@bubt610:~/autot++$ cat configure.ac
# -*- Autoconf -*-
# Process this file with autoconf to produce a configure script.

AC_PREREQ(2.59)
AC_INIT(TestCXXProject, 1.0.0)
AM_INIT_AUTOMAKE
AC_CONFIG_SRCDIR([main.cc])
AC_CONFIG_HEADER([config.h])
AC_CONFIG_FILES([Makefile])

# Checks for programs.
AC_PROG_CXX
AC_PROG_LIBTOOL

# Checks for libraries.
ACX_PTHREAD

# Checks for header files.

# Checks for typedefs, structures, and compiler characteristics.

# Checks for library functions.
AC_OUTPUT
builder@bubt610:~/autot++$ cat Makefile.am
bin_PROGRAMS = cxxtest

cxxtest_SOURCES = main.cc
#cxxtest_CXXFLAGS = -nostdinc++
AM_CXXFLAGS = $(PTHREAD_CFLAGS)
AM_CPPFLAGS = -I/usr/include/stlport
cxxtest_LDADD = -lstlport libtest.la $(PTHREAD_LIBS)

CXXLD = $(PTHREAD_CC)

noinst_LTLIBRARIES = libtest.la
libtest_la_SOURCES = lib.cc

builder@bubt610:~/autot++$ make clean; make
rm -f cxxtest cxxtest
rm -rf .libs _libs
test -z "libtest.la" || rm -f libtest.la
rm -f "./so_locations"
rm -f *.o
rm -f *.lo
make all-am
make[1]: Entering directory `/home/builder/autot++'
if /bin/bash ./libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I. -I/usr/include/stlport -pthread -g -O2 -MT lib.lo -MD -MP -MF ".deps/lib.Tpo" -c -o lib.lo lib.cc; \
then mv -f ".deps/lib.Tpo" ".deps/lib.Plo"; else rm -f ".deps/lib.Tpo"; exit 1; fi
mkdir .libs
g++ -DHAVE_CONFIG_H -I. -I. -I. -I/usr/include/stlport -pthread -g -O2 -MT lib.lo -MD -MP -MF .deps/lib.Tpo -c lib.cc -fPIC -DPIC -o .libs/lib.o
g++ -DHAVE_CONFIG_H -I. -I. -I. -I/usr/include/stlport -pthread -g -O2 -MT lib.lo -MD -MP -MF .deps/lib.Tpo -c lib.cc -o lib.o >/dev/null 2>&1
/bin/bash ./libtool --tag=CXX --mode=link gcc -pthread -g -O2 -o libtest.la lib.lo
ar cru .libs/libtest.a .libs/lib.o
ranlib .libs/libtest.a
creating libtest.la
(cd .libs && rm -f libtest.la && ln -s ../libtest.la libtest.la)
if g++ -DHAVE_CONFIG_H -I. -I. -I. -I/usr/include/stlport -pthread -g -O2 -MT main.o -MD -MP -MF ".deps/main.Tpo" -c -o main.o main.cc; \
then mv -f ".deps/main.Tpo" ".deps/main.Po"; else rm -f ".deps/main.Tpo"; exit 1; fi
/bin/bash ./libtool --tag=CXX --mode=link gcc -pthread -g -O2 -o cxxtest main.o -lstlport libtest.la
gcc -pthread -g -O2 -o cxxtest main.o -lstlport ./.libs/libtest.a
make[1]: Leaving directory `/home/builder/autot++'
builder@bubt610:~/autot++$ ldd cxxtest
linux-gate.so.1 => (0xffffe000)
libstlport.so.5.0 => /usr/lib/libstlport.so.5.0 (0xb7e81000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7e76000)
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7e63000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7d2f000)
/lib/ld-linux.so.2 (0xb7f15000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7d09000)
builder@bubt610:~/autot++$ ./
autom4te.cache/ config.sub depcomp .libs/
config.guess configure .deps/ libtool
config.status cxxtest install-sh missing
builder@bubt610:~/autot++$ ./cxxtest
Hello, world!
Hello from void printHello()
builder@bubt610:~/autot++$ _

По сравнению с предыдущим добавился файлик lib.cc, собираемый в convenient library libtest.la:

builder@bubt610:~/autot++$ cat lib.cc
#include <iostream>

void printHello(void)
{
std::cout << "Hello from " << __PRETTY_FUNCTION__ << std::endl;
}

builder@bubt610:~/autot++$ _

Компилятор - gcc version 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5).

Если не можется, могу этот же тест на дебиане-3.1 прогнать, на других системах - увольте, это придется под них собранный stlport искать.

Да, ссылки на то, что-де злобные альтовцы на этот раз захачили 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 тут уже не поможет.