automake - autoconf: Umstieg auf neue Version macht fehlerhafte Makefiles
Liebe Leute bitte helft! Ich arbeite an einem Amateurfunk-Programm, dessen configure-Skript 1996 mit automake V. 1.4 und autoconf V.2.13 gemacht wurde. Es kompiliert auch auf meinem neuen System (Kernel 2.2.13, Suse 8.1, automake 1.6.3, autoconf 2.5.3) gut --- so lange ich nichts an configure.in ändere. Ich würde dies aber gerne tun, um einige Optionen einzubauen, und auch sonst (ich weiß noch nicht genau wann) werden das neue aotoconf und automake verwendet, und es entstehen makefiles die make mit Fehlern abbrechen lassen, die Befehle erscheinen unvollständig. -- Dr. med. Günther Montag Allgemeinarzt - Psychotherapeut Bahnhofstraße 15 D-86415 Mering 08233-32356 Safari.Doktor@addcom.de
On Fri, 2003-09-05 at 13:13, Dr. med. Günther Montag wrote:
Liebe Leute bitte helft! Ich arbeite an einem Amateurfunk-Programm, dessen configure-Skript 1996 mit automake V. 1.4 und autoconf V.2.13 gemacht wurde. Es kompiliert auch auf meinem neuen System (Kernel 2.2.13, Suse 8.1, automake 1.6.3, autoconf 2.5.3) vermutl. autoconf-2.53, 2.5.3 gibt es nicht.
gut --- so lange ich nichts an configure.in ändere. Ich würde dies aber gerne tun, um einige Optionen einzubauen, und auch sonst (ich weiß noch nicht genau wann) werden das neue aotoconf und automake verwendet, und es entstehen makefiles die make mit Fehlern abbrechen lassen, die Befehle erscheinen unvollständig. Da wird es sich um eine nicht autoconf-2.53/automake-1.6.3 kompatible Konfiguration handeln. Um Dir helfen zu können, müsstest Du uns allerdings mehr Details verraten (Quellcode oder Fehlermeldungen).
Ralf
Hallo... Am Freitag, 5. September 2003 13:13 schrieb Dr. med. Günther Montag:
Liebe Leute bitte helft! Ich arbeite an einem Amateurfunk-Programm, dessen configure-Skript 1996 mit automake V. 1.4 und autoconf V.2.13 gemacht wurde. Es kompiliert auch auf meinem neuen System (Kernel 2.2.13, Suse 8.1, automake 1.6.3, autoconf 2.5.3) gut --- so lange ich nichts an configure.in ändere. Ich würde dies aber gerne tun, um einige Optionen einzubauen, und auch sonst (ich weiß noch nicht genau wann) werden das neue aotoconf und automake verwendet, und es entstehen makefiles die make mit Fehlern abbrechen lassen, die Befehle erscheinen unvollständig.
Um eine Lösung zu finden muss erst das Problem definiert werden. Welche Anweisungen in welchem Script bewirken was? Welche Fehlermeldungen? -- gruß Oliver
"Dr. med. Günther Montag"
Liebe Leute bitte helft!
Gerne.
Ich arbeite an einem Amateurfunk-Programm, dessen configure-Skript 1996 mit automake V. 1.4 und autoconf V.2.13 gemacht wurde.
Welches Programm (mit URL)? Um solche Fehler zu beheben muss man den Quellcode bzw. configure.in und Makefile.am sehen. Philipp
Danke, Philip, Ralf, Oliver, für Eure Bereitschaft zu helfen!
Also:
Mein Programm:
ist ein Amateurfunkprogramm, das Pactor (ein
Echtzeit-Datenübertragungsprotokoll für Kurzwelle, das Daten- und
Kontrollpakete im 1,25 sec Rhythmus verwendet) mit Soundkarte senden und
empfangen kann.
Es stammt von Tom Sailer, einem Soundkarten-Packetradio-"Guru", der leide=
r nun keine Zeit mehr hat, daran weiter zu arbeiten, geschrieben 1996.
(http://sourceforge.net/projects/hfterm).
Mein Erlebnis:
Im Paket im Stamverzeichnis war ist ein Script (startkern.pl), das nicht =
mehr gebraucht wird.
Ich löschte es, entfernte es aus dem makefile.am, entfernte es als Argu=
ment von AC_INIT in der ersten zeile von configure.in.
Um das Makefile zu aktualisieren, mache ich (das neue) automake und autoconf,
und dann ./configure, das geht ohne Fehlermeldung.
Und nun: make bricht beim ersten C-Programm ab mit der Meldung
make all-recursive
source 'fsk.c' object 'fsk.o' libtool no \
depfile '.deps/fsk.Po' tmpdepfile '.deps/fsk.TPo' \
depmode none /bin/sh ../../depcomp \
gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../include -I../../l1 -I../../l1=
/user -g -O2 -Wall -c `test -f 'fsk.c' || echo './'`fsk.c
make[3]: Verlassen des Verzeichnisses =BB/home/monday/hf-0.4.1/l1/user=AB
make[2]: Verlassen des Verzeichnisses =BB/home/monday/hf-0.4.1/l1=AB
make[1]: Verlassen des Verzeichnisses =BB/home/monday/hf-0.4.1=AB
Irgendwie scheint mir da ein Fragment einer Unterroutine (test -f ...) in
die Befehlszeile für den Compiler geraten zu sein...
Ich hänge einen Ausschnitt aus dem alte ("guten", erfolgreichen ) makelog
(Output von: 'make | tee makelog 2>&1'),
altes (.alt) und neues Makefile.am,
altes und neues configure.in an.
Bin gespannt was Euch dazu einfällt!
Safari.Doktor@addcom.de
###############################
"Makefile.am"
INCLUDES = -I$(top_srcdir)/include
SUBDIRS = scripts l1 proto os hfterm dcf77 doc test util
noinst_HEADERS = \
include/hfapp.h \
include/os.h
EXTRA_DIST = freqdev.m ggtest.m golay.m \
include/hfapp.h \
include/os.h
#################################
"Makefile.am.alt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="Makefile.am.alt"
INCLUDES = -I$(top_srcdir)/include
SUBDIRS = scripts l1 proto os hfterm dcf77 doc test util
noinst_HEADERS = \
include/hfapp.h \
include/os.h
EXTRA_DIST = freqdev.m ggtest.m golay.m \
include/hfapp.h \
include/os.h \
startkern.pl
#################################
"configure.in"
AC_INIT
AC_CANONICAL_SYSTEM
AM_INIT_AUTOMAKE(hf, 0.4.1)
AM_CONFIG_HEADER(config.h)
dnl AC_CHECK_TOOL()
AC_PROG_MAKE_SET
AC_ISC_POSIX
AC_PROG_CC
AM_PROG_CC_STDC
dnl AC_PROG_CXX
dnl AC_PROG_RANLIB
AC_C_CONST
AC_C_INLINE
AC_HEADER_STDC
dnl AC_FUNC_ALLOCA
AC_CHECK_PROG(RANLIB, ranlib, ranlib, :)
AC_CHECK_PROG(DLLTOOL, dlltool, dlltool, dlltool)
AC_CHECK_PROG(AS, as, as, as, as)
AC_CHECK_PROG(AR, ar, ar, ar, ar)
dnl AC_CYGWIN
dnl AC_MINGW32
dnl AC_EXEEXT
dnl AC_OBJEXT
dnl if test x$ac_cv_mingw32 != xyes; then
dnl AC_CHECK_LIB(m,cos)
dnl fi
AC_CHECK_LIB(m,cos)
AC_HEADER_TIME
AC_CHECK_HEADERS(getopt.h sys/ioctl.h syslog.h errno.h sys/io.h)
AC_CHECK_HEADERS(sys/audioio.h stropts.h sys/conf.h sys/soundcard.h)
AC_CHECK_HEADERS(forms.h pthread.h sched.h)
AC_CHECK_FUNCS(vsnprintf,AC_DEFINE(HAVE_VSNPRINTF),OSLIBS="$OSLIBS
vsnprintf.o")
AC_CHECK_LIB(socket,socket,SOCKLIBS="$SOCKLIBS -lsocket")
dnl AC_CHECK_LIB(nsl,SOCKLIBS="$SOCKLIBS -lsocket")
if test x${ac_cv_header_pthread_h} = xyes; then
AC_CHECK_LIB(pthread,pthread_create,THRLIBS="$THRLIBS -lpthread")
AC_DEFINE(_REENTRANT)
fi
AC_CHECK_LIB(posix4,sched_setscheduler,SCHEDLIBS="$SCHEDLIBS -lposix4")
dnl AC_MSG_CHECKING(for GetSystemTime)
dnl getsystemtime=no
dnl AC_TRY_COMPILE([#include
participants (4)
-
Dr. med. Günther Montag
-
Oliver Leue
-
Philipp Thomas
-
Ralf Corsepius