Mahlzeit!
Als ich gestern (11.8.05) um 8.00 Uhr das CVS ausgechecked habe lief alles noch durch. Seit gesterm mittag bis heute morgen 8.00 Uhr tritt folgender Fehler auf:
checking dependency style of powerpc-tuxbox-linux-gnu-gcc... (cached) gcc3
checking for powerpc-tuxbox-linux-gnu-g++... powerpc-tuxbox-linux-gnu-g++
checking whether we are using the GNU C++ compiler... yes
checking whether powerpc-tuxbox-linux-gnu-g++ accepts -g... yes
checking dependency style of powerpc-tuxbox-linux-gnu-g++... gcc3
checking for powerpc-tuxbox-linux-gnu-ranlib... powerpc-tuxbox-linux-gnu-ranlib
checking how to run the C preprocessor... powerpc-tuxbox-linux-gnu-gcc -E
checking for egrep... grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking ost/dmx.h usability... yes
checking ost/dmx.h presence... yes
checking for ost/dmx.h... yes
configure: found dvb version 1
checking for freetype-config... /home/djin/dream/root/cdk/bin/freetype-config
checking for pkg-config... /usr/bin/pkg-config
checking for package id3tag... yes
checking for package mad... yes
checking for package tuxbox-md5sum... yes
checking for package tuxbox-plugins... yes
checking for package libpng... yes
checking for package sigc++-1.2... yes
checking for package tuxbox-xmltree... yes
checking for package tuxbox-tuxtxt... yes
./configure: line 6456: syntax error near unexpected token `MSGFMT,'
./configure: line 6456: `AM_PATH_PROG_WITH_TEST(MSGFMT, msgfmt,'
make: *** [/home/djin/dream/apps/tuxbox/enigma/Makefile] Fout 2
[djin@localhost cdk]$
[root@localhost libtool-1.5.18]# make --version
GNU Make 3.80
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
[root@localhost libtool-1.5.18]# gettext --version
gettext (GNU gettext-runtime) 0.14.5
Copyright (C) 1995-1997, 2000-2005 Free Software Foundation, Inc.
Dit is vrije software; zie de broncode voor kopieervoorwaarden. Er is GEEN
garantie; zelfs niet voor VERKOOPBAARHEID of GESCHIKTHEID VOOR EEN BEPAALD DOEL.
Geschreven door Ulrich Drepper.
[root@localhost libtool-1.5.18]#
Bei Installaton von SuSE 10.0 bin ich in diesem Problem aufmerksam. SuSE 10.0 enthält nicht ein gettext-devel oder sowas.
Es handelt sich hier um ein autoconf-Makro AM_PATH_PROG_WITH_TEST (in der Datei progtest.m4). Diese Datei war niemals "Standard".
Das automake Handbuch sagt zu diesem Thema (5.8 Handling local macros)
However there is no consensus on the distribution of third-party
macros that your package may use. Many libraries install their own
macro in the system-wide `aclocal' directory (*note Extending
aclocal::). For instance, Guile ships with a file called `guile.m4'
that contains the macro `GUILE_FLAGS' that can be used to define setup
compiler and linker flags appropriate for using Guile. Using
`GUILE_FLAGS' in `configure.ac' will cause `aclocal' to copy `guile.m4'
into `aclocal.m4', but as `guile.m4' is not part of the project, it
will not be distributed. Technically, that means a user who needs to
rebuild `aclocal.m4' will have to install Guile first. This is
probably OK, if Guile already is a requirement to build the package.
However, if Guile is only an optional feature, or if your package might
run on architectures where Guile cannot be installed, this requirement
will hinder development. An easy solution is to copy such third-party
macros in your local `m4/' directory so they get distributed.
Sofern ich verstehe wäre das einzig Saubere, progtest.m4 in der Enigmaverzeichniss reinzupacken, und einzubinden. Spricht etwas dagegen?