[Dune] Verwendung von DUNE und der aktuellen UG-Version
Oliver Sander
sander at mi.fu-berlin.de
Tue May 22 15:49:51 CEST 2007
Dear Christoph!
I've seen such errors before only when using inappropriate
(==old) versions of automake and autoconf. However the
ones you say you're using (autoconf 2.59; automake 1.9.6)
should be okay. So I'm a bit short of good ideas here.
Maybe some AutoTools expert on the list can help?
--
Oliver
lenzen at scai.fraunhofer.de wrote:
>Hallo Oliver,
>
>tut mir leid, das war mir unklar. Anbei die Ausgabe von autogen.sh.
>
>Gruß
>Christoph
>
>Oliver Sander wrote:
>
>
>>Du benutzt fälschlicherweise das alte Buildsystem. Wir haben
>>es irgendwann durch ein AutoTools-basiertes Buildsystem
>>ersetzt, aber das alte aus Kompatibilitätsgründen noch drinnen
>>gelassen. Eigentlich sollten alle mitgelieferten Dateien mit
>>dem Namen 'Makefile' überschrieben werden, es sei denn
>>autogen.sh / configure bricht mit einem Fehler ab.
>>
>>Deshalb:
>>- frisch auschecken
>>- in autogen.sh die letzte Zeile (der Aufruf von configure)
>> auskommentieren
>>- autogen.sh aufrufen
>>- configure mit den bekannten Optionen aufrufen
>>
>>Wenn jetzt Fehler aufgetaucht sind _nicht_ einfach weitermachen
>>sondern mir die Bildschirmausgabe und config.log schicken.
>>
>>--
>>Oliver
>>
>>lenzen at scai.fraunhofer.de wrote:
>>
>>
>>
>>>Hallo Oliver,
>>>
>>>das ist das erste, was ich versucht hatte...
>>>Zwischendurch kam mir der Gedanke ebenfalls, ich habe zwei oder drei mal
>>>neu mit ug angefangen. Naja, ich habe sowohl ug neu ausgecheckt als auch
>>>dune noch mal neu ins Spiel gebracht. Ich hatte allerdings noch nicht das
>>>Prozedere mit den Entwicklerversionen durchexerziert, deswegen ergibt
>>>sich
>>>was Neues.
>>>
>>>Es ist immer noch so, dass die Option CC=g++ ignoriert wird, da make die
>>>Variable ARCH_CC, die aus arch/PC/mk.arch importiert wird verwendet.
>>>Wieder tritt beim Kompilieren der Syntaxfehler durch Übergabe eines
>>>Defaultwertes in refine.h:261 auf. Also habe ich make clean, rm lib/lib*
>>>und anschließend make ARCH_CC=g++ aufgerufen. Dies führt unmittelbar zur
>>>Fehlermeldung
>>>
>>>In file included from ugdevices.c:40:
>>>/home/clenzen/dip_ware/ug/include/debug.h:176: Fehler: >>INT<< bezeichnet
>>>keinen Typ
>>>
>>>Eine Überprüfung ergab, dass der Debugmode von UG wieder an war. Nach
>>>erneutem Aufräumen und make ARCH_CC=g++ kompiliert er durch. Nach Setzen
>>>von DIM=2, make clean, autogen.sh --prefix=./ --enable-dune und make
>>>ARCH_CC=g++ kompiliert er wieder durch.
>>>
>>>Bisher ignoriert habe ich die Ausgaben von autogen.sh im Stil von:
>>>
>>>ui/Makefile.am:19: Libtool library used but `LIBTOOL' is undefined
>>>ui/Makefile.am:19:
>>>ui/Makefile.am:19: The usual way to define `LIBTOOL' is to add
>>>`AC_PROG_LIBTOOL'
>>>ui/Makefile.am:19: to `configure.ac' and run `aclocal' and `autoconf'
>>>again.
>>>
>>>Die gibts für jeden Makefile, allerdings kann ich das in keine Beziehung
>>>zu den auftretenden Fehlern setzen (das Standard-UG zusammen mit den
>>>beta5-Versionen von DUNE funktionierte ja bereits soweit, das die
>>>Bibliotheken gefunden wurden, einige Funktionen den Test bestanden und
>>>dann GrapeCommand fehlte). Bevor die Frage kommt: Ich habe autoconf 2.59
>>>und automake 1.9.6.
>>>
>>>Allerdings kriege ich jetzt auch ähnliche Fehler mit einer neu
>>>ausgechecktne Version von DUNE.
>>>
>>>Wechseln in das Verzeichnis, wo dune liegt und
>>>./dune-common/bin/dunecontrol --opts=lenzen.opts all, wobei lenzen.opts
>>>CONFIGURE_FLAGS="--prefix=<aktuelles Verzeichnis> --disable-parallel"
>>>enthält, führt ebenfalls zur Beschwerde über fehlendes AC_PROG_LIBTOOL
>>>bei
>>>libtoolize. Ich vermute jedoch, dass die eigentlichen Probleme später
>>>auftreten:
>>>configure.ac:10 AC_DISABLE_SHARED is required by...
>>>m4/dune_all.m4:203: DUNE_CHECK_ALL_ is expanded from...
>>>configure.ac:10: the top level
>>>configure.ac:10: warning: AC_PROG_LIBTOOL is m4_require'd but is not
>>>m4_defun'd
>>>configure.ac:10: AC_PROG_LIBTOOL is required by ...
>>>configure.ac:10 CHECK_ALL is required by...
>>>
>>>Das wiederholt sich noch zwei mal, es tauchen drei Meldungen
>>>configure.ac: installing xyz
>>>auf, zwei Makefiles beschweren sich über AC_PROG_LIBTOOL genauso wie ug
>>>und die Ausführung bricht wegen Fehlern ab.
>>>
>>>Was für eine Variable ist das, und worauf soll sie gesetzt werden?
>>>Brauche
>>>ich noch neuere Versionen von autoconf oder automake? Jedenfalls wäre es
>>>vermutlich gut, diesen Fehler zu entfernen, auch wenn er beim
>>>Installieren
>>>von der beta5-Version nicht auftrat (die andere Version hatte ich wegen
>>>den Schwierigkeiten beim bauen von ug vorher nicht ausprobiert).
>>>
>>>Viele Grüße
>>>Christoph
>>>
>>>Oliver Sander wrote:
>>>
>>>
>>>
>>>
>>>>Hallo Christoph!
>>>>Ich habe den Eindruck Du könntest das Buildsystem
>>>>kaputtprobiert haben. Könntest Du das UG nochmal ganz
>>>>neu auschecken, und die Installation genau so vornehmen,
>>>>wie sie auf der Dune-Seite beschrieben sind? (okay, wenn
>>>>Du es heute machst, bekommt autogen.sh die ganzen Optionen
>>>>von configure. Das habe ich eben geändert, aber die Änderungen
>>>>kommen glaube ich erst morgen auf dem Server für das
>>>>anonyme CVS an.) Wenn es dann immer noch nicht geht
>>>>schicke mir die genaue Fehlermeldung.
>>>>
>>>>Grüße,
>>>>Oliver
>>>>
>>>>lenzen at scai.fraunhofer.de wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>The missing function is "UG::D2::CallGrape(UG::D2::multigrid*)".
>>>>>
>>>>>Oliver Sander wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>No. What makes you think it needs grape?
>>>>>>
>>>>>>--
>>>>>>Oliver
>>>>>>
>>>>>>lenzen at scai.fraunhofer.de wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>I don't know. We disabled it already, what made the standard ug
>>>>>>>compile
>>>>>>>without errors. Does DUNE require GRAPE? If so, have I to get it
>>>>>>>somewhere
>>>>>>>else?
>>>>>>>
>>>>>>>
>>>>>>>Oliver Sander wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>How did you get -DDebug as a compiler option? It is not
>>>>>>>>supposed to be set.
>>>>>>>>
>>>>>>>>--
>>>>>>>>Oliver
>>>>>>>>
>>>>>>>>lenzen at scai.fraunhofer.de wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>Dear Oliver,
>>>>>>>>>
>>>>>>>>>I guessed you would ask for that information. I tried to use
>>>>>>>>>standard
>>>>>>>>>options on a quite usual system. Several experiments led to
>>>>>>>>>different
>>>>>>>>>errors, so I'll try to repeat them and give you as much information
>>>>>>>>>as
>>>>>>>>>possible. The PC I used currently runs under windows, so I'll use a
>>>>>>>>>system
>>>>>>>>>with - as far as I know - the same specifications. In all cases I
>>>>>>>>>gave
>>>>>>>>>the
>>>>>>>>>option --enable-dune to autogen.sh, which should be passed to
>>>>>>>>>configure,
>>>>>>>>>but I'm not sure if there is any effect to this option.
>>>>>>>>>
>>>>>>>>>1. uname -a gives:
>>>>>>>>>
>>>>>>>>>Linux briggs 2.6.9-11.ELsmp #1 SMP Thu Jun 9 15:33:26 CDT 2005 i686
>>>>>>>>>i686
>>>>>>>>>i386 GNU/Linux
>>>>>>>>>
>>>>>>>>>2. gcc -v (and g++ -v) give:
>>>>>>>>>
>>>>>>>>>Lese Spezifikationen von /usr/lib/gcc/i386-redhat-linux/3.4.6/specs
>>>>>>>>>Konfiguriert mit: ../configure --prefix=/usr
>>>>>>>>>--mandir=/usr/share/man
>>>>>>>>>--infodir=/usr/share/info --enable-shared --enable-threads=posix
>>>>>>>>>--disable-checking --with-system-zlib --enable-__cxa_atexit
>>>>>>>>>--disable-libunwind-exceptions --enable-java-awt=gtk
>>>>>>>>>--host=i386-redhat-linux
>>>>>>>>>Thread-Modell: posix
>>>>>>>>>gcc-Version 3.4.6 20060404 (Red Hat 3.4.6-8)
>>>>>>>>>
>>>>>>>>>3. echo $UGROOT gives:
>>>>>>>>>/home/clenzen/dipl_ware/ug
>>>>>>>>>
>>>>>>>>>4. The "vanilla" ug version compiles with gcc when using autogen.sh
>>>>>>>>>and
>>>>>>>>>make. Of course the libraries is not accepted by the beta5-version
>>>>>>>>>of
>>>>>>>>>DUNE.
>>>>>>>>>
>>>>>>>>>5. Compiling it with g++ (or gcc -xc++, both forced by setting
>>>>>>>>>ARCH_CC
>>>>>>>>>when calling make) leads to an impressive number of warnings
>>>>>>>>>errors.
>>>>>>>>>Apart
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>from errors in debugging code an error like this occurs, though in
>>>>>>>>
>>>>>>>>
>>>>>>>>>an
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>other file:
>>>>>>>>>
>>>>>>>>>g++ -c -D_3 -D__PC__ -DDebug -pipe -s -O3 -march=i686
>>>>>>>>>-fomit-frame-pointer
>>>>>>>>>-funroll-loops -fno-strict-aliasing -I/usr/X11R6/include
>>>>>>>>>-I/home/clenzen/dipl_ware/ug/include -I/home/clenzen/dipl_ware/ug
>>>>>>>>>-I../include ugdevices.c
>>>>>>>>>In file included from ugdevices.c:40:
>>>>>>>>>/home/clenzen/dipl_ware/ug/include/debug.h:176: Fehler: »INT«
>>>>>>>>>bezeichnet
>>>>>>>>>keinen Typ
>>>>>>>>>
>>>>>>>>>6. I edited the corresponding "INT" to "int" and had to comment out
>>>>>>>>>many
>>>>>>>>>debugging lines using an undefinded variable named "me" (marked
>>>>>>>>>element?),
>>>>>>>>>then ug compiled with standard options. However, installing DUNE
>>>>>>>>>the
>>>>>>>>>ug
>>>>>>>>>libraries were still not accepted (because of a linker error
>>>>>>>>>calling
>>>>>>>>>some
>>>>>>>>>function with grape in its name; all other checks concerning ug
>>>>>>>>>were
>>>>>>>>>ok).
>>>>>>>>>I guessed Grape has to be set to ON in ug.conf and IF = S
>>>>>>>>>(concluded
>>>>>>>>>from
>>>>>>>>>the names of the libraries checked by DUNE's configure). However,
>>>>>>>>>this
>>>>>>>>>leads to many knew compilation errors for ug. They are like the one
>>>>>>>>>above,
>>>>>>>>>just with additional other types in capital letters involved. There
>>>>>>>>>I
>>>>>>>>>stopped trying, because I don't even know what's the purpose of
>>>>>>>>>this
>>>>>>>>>types
>>>>>>>>>(or more correctly, Macros substituting types?) I won't repeat the
>>>>>>>>>whole
>>>>>>>>>process, if not necessary.
>>>>>>>>>
>>>>>>>>>7. Compiling your developer version of ug with gcc gives the
>>>>>>>>>following
>>>>>>>>>error:
>>>>>>>>>
>>>>>>>>>gcc -c -D_3 -D__PC__ -DDebug -pipe -s -O3 -march=i686
>>>>>>>>>-fomit-frame-pointer
>>>>>>>>>-funroll-loops -fno-strict-aliasing -I/usr/X11R6/include
>>>>>>>>>-I/home/clenzen/dipl_ware/ug/include -I/home/clenzen/dipl_ware/ug
>>>>>>>>>algebra.c
>>>>>>>>>In file included from algebra.c:74:
>>>>>>>>>refine.h:261: Fehler: Syntaxfehler vor »=«-Zeichen
>>>>>>>>>
>>>>>>>>>I find this rather confusing, because I don't see the problem with
>>>>>>>>>this
>>>>>>>>>default value. Editing the INT type to int doesn't change anything
>>>>>>>>>(as
>>>>>>>>>expected: grep told me that INT is probably just a Makro for int,
>>>>>>>>>which
>>>>>>>>>againg is confusing - what's the sense in it?). But when "=0" is
>>>>>>>>>deleted,
>>>>>>>>>it compiles, of course a new error occurs when the function is
>>>>>>>>>called
>>>>>>>>>with
>>>>>>>>>the last argument omitted. Here I stopped again, as ug has to be
>>>>>>>>>compiled
>>>>>>>>>as c++ code in any case.
>>>>>>>>>
>>>>>>>>>8. Compiling the developer version of ug with g++ immediatly gives
>>>>>>>>>the
>>>>>>>>>following error:
>>>>>>>>>
>>>>>>>>>g++ -c -D_3 -D__PC__ -DDebug -pipe -s -O3 -march=i686
>>>>>>>>>-fomit-frame-pointer
>>>>>>>>>-funroll-loops -fno-strict-aliasing -I/usr/X11R6/include
>>>>>>>>>-I/home/clenzen/dipl_ware/ug/include -I/home/clenzen/dipl_ware/ug
>>>>>>>>>-I../include ugdevices.c
>>>>>>>>>In file included from ugdevices.c:40:
>>>>>>>>>/home/clenzen/dipl_ware/ug/include/debug.h:176: Fehler: »INT«
>>>>>>>>>bezeichnet
>>>>>>>>>keinen Typ
>>>>>>>>>
>>>>>>>>>At this point I didn't try to change anything, because I guess I
>>>>>>>>>would
>>>>>>>>>get
>>>>>>>>>the same problems as above.
>>>>>>>>>
>>>>>>>>>These errors are the same as on the other system. I hope this is
>>>>>>>>>what
>>>>>>>>>you
>>>>>>>>>requested.
>>>>>>>>>
>>>>>>>>>Thanks for the help
>>>>>>>>>Christoph
>>>>>>>>>
>>>>>>>>>Oliver Sander wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>Dear Christoph!
>>>>>>>>>>I'm sorry to hear that you are having difficulties installing UG
>>>>>>>>>>for
>>>>>>>>>>Dune. We have
>>>>>>>>>>had various successful installs by now, but there may still be
>>>>>>>>>>difficulties on less
>>>>>>>>>>common platforms.
>>>>>>>>>>
>>>>>>>>>>In order to help you, though, we need some actual information.
>>>>>>>>>>What
>>>>>>>>>>platform
>>>>>>>>>>do you use? What's your compiler? And what are the actual error
>>>>>>>>>>messages?
>>>>>>>>>>Without that kind of information it is hardly possible to pin down
>>>>>>>>>>any
>>>>>>>>>>errors.
>>>>>>>>>>
>>>>>>>>>>--
>>>>>>>>>>Oliver Sander
>>>>>>>>>>
>>>>>>>>>>Christoph Lenzen wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>Hallo,
>>>>>>>>>>>
>>>>>>>>>>>ich versuche im Augenblick, die aktuelle Version von UG
>>>>>>>>>>>(ausgecheckt
>>>>>>>>>>>mit
>>>>>>>>>>>
>>>>>>>>>>>cvs
>>>>>>>>>>>-d:pserver:anonymous at sit.iwr.uni-heidelberg.de:/Users/mirror/CVS
>>>>>>>>>>>co UG/ug
>>>>>>>>>>>) mit der beta5-Version von DUNE zu verheiraten. UG benutzt
>>>>>>>>>>>inzwischen
>>>>>>>>>>>eine Datei autogen.sh statt dem vorherigen configure, wie auf der
>>>>>>>>>>>DUNE-Seite beschrieben (siehe README.autotools im Rootverzeichnis
>>>>>>>>>>>von
>>>>>>>>>>>UG). Ich übergab die angegebenen Optionen, aber DUNE akzeptierte
>>>>>>>>>>>die
>>>>>>>>>>>Bibliotheken nicht, da der Linker auf "undefined references"
>>>>>>>>>>>stieß.
>>>>>>>>>>>
>>>>>>>>>>>Zunächst stellte ich fest, dass UG trotz der übergebenen Option
>>>>>>>>>>>nicht
>>>>>>>>>>>g++ statt gcc verwendete (das mag eventuell an meinem System
>>>>>>>>>>>liegen,
>>>>>>>>>>>ich wüsste aber nicht wieso). Das habe ich schließlich durch
>>>>>>>>>>>"make
>>>>>>>>>>>ARCH_CC=g++" erzwungen, nachdem ich überprüft habe, dass ARCH_CC
>>>>>>>>>>>auf
>>>>>>>>>>>gcc gesetzt war. Nach einigen Schwierigkeiten wegen einer
>>>>>>>>>>>INT-Variable
>>>>>>>>>>>(mittels grep konnte ich ein #define INT int finden), die ich zu
>>>>>>>>>>>einer
>>>>>>>>>>>int gemacht habe, und ausdokumentieren von PRINTDEBUG-Zeilen, die
>>>>>>>>>>>auf
>>>>>>>>>>>eine undefinierte Variable me zurückgreifen, wurden die
>>>>>>>>>>>Bibliotheken
>>>>>>>>>>>erstellt.
>>>>>>>>>>>
>>>>>>>>>>>Die Fehlermeldung, die ich bezüglich der Bibliotheken vor der
>>>>>>>>>>>Anwendung von g++ in config.log (vom DUNE-configure-Aufruf) fand,
>>>>>>>>>>>bezog sich zunächst auf darauf, dass InitUg(int, int) nicht zu
>>>>>>>>>>>finden
>>>>>>>>>>>war. Hinterher erhielt ich eine andere undefinierte Referenz.
>>>>>>>>>>>Ändern
>>>>>>>>>>>der Optionen in ug.conf liefert neue Fehler beim Kompilieren,
>>>>>>>>>>>daher
>>>>>>>>>>>habe ich Abstand davon genommen, dieses blinde Experimentieren
>>>>>>>>>>>weiter
>>>>>>>>>>>zu führen.
>>>>>>>>>>>
>>>>>>>>>>>Hat jemand eine Idee, was zu tun ist? Sollte ich mich an die
>>>>>>>>>>>Programmierer von UG wenden?
>>>>>>>>>>>
>>>>>>>>>>>Viele Grüße
>>>>>>>>>>>Christoph Lenzen
>>>>>>>>>>>
>>>>>>>>>>>------------------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>>_______________________________________________
>>>>>>>>>>>Dune mailing list
>>>>>>>>>>>Dune at dune-project.org
>>>>>>>>>>>http://lists.dune-project.org/mailman/listinfo/dune
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>--
>>>>>>>>>>************************************************************************
>>>>>>>>>>* Oliver Sander ** email: sander at mi.fu-berlin.de
>>>>>>>>>>*
>>>>>>>>>>* Freie Universität Berlin ** phone: + 49 (30) 838 75217
>>>>>>>>>>*
>>>>>>>>>>* Institut für Mathematik II ** URL :
>>>>>>>>>>page.mi.fu-berlin.de/~sander
>>>>>>>>>>*
>>>>>>>>>>* Arnimallee 6 **
>>>>>>>>>>-------------------------------------*
>>>>>>>>>>* 14195 Berlin, Germany ** Member of MATHEON
>>>>>>>>>>(www.matheon.de)
>>>>>>>>>>*
>>>>>>>>>>************************************************************************
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>--
>>>>>>>>************************************************************************
>>>>>>>>* Oliver Sander ** email: sander at mi.fu-berlin.de
>>>>>>>>*
>>>>>>>>* Freie Universität Berlin ** phone: + 49 (30) 838 75217
>>>>>>>>*
>>>>>>>>* Institut für Mathematik II ** URL :
>>>>>>>>page.mi.fu-berlin.de/~sander
>>>>>>>>*
>>>>>>>>* Arnimallee 6 **
>>>>>>>>-------------------------------------*
>>>>>>>>* 14195 Berlin, Germany ** Member of MATHEON (www.matheon.de)
>>>>>>>>*
>>>>>>>>************************************************************************
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>--
>>>>>>************************************************************************
>>>>>>* Oliver Sander ** email: sander at mi.fu-berlin.de
>>>>>>*
>>>>>>* Freie Universität Berlin ** phone: + 49 (30) 838 75217
>>>>>>*
>>>>>>* Institut für Mathematik II ** URL : page.mi.fu-berlin.de/~sander
>>>>>>*
>>>>>>* Arnimallee 6 **
>>>>>>-------------------------------------*
>>>>>>* 14195 Berlin, Germany ** Member of MATHEON (www.matheon.de)
>>>>>>*
>>>>>>************************************************************************
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>--
>>>>************************************************************************
>>>>* Oliver Sander ** email: sander at mi.fu-berlin.de *
>>>>* Freie Universität Berlin ** phone: + 49 (30) 838 75217 *
>>>>* Institut für Mathematik II ** URL : page.mi.fu-berlin.de/~sander *
>>>>* Arnimallee 6 ** -------------------------------------*
>>>>* 14195 Berlin, Germany ** Member of MATHEON (www.matheon.de) *
>>>>************************************************************************
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>--
>>************************************************************************
>>* Oliver Sander ** email: sander at mi.fu-berlin.de *
>>* Freie Universität Berlin ** phone: + 49 (30) 838 75217 *
>>* Institut für Mathematik II ** URL : page.mi.fu-berlin.de/~sander *
>>* Arnimallee 6 ** -------------------------------------*
>>* 14195 Berlin, Germany ** Member of MATHEON (www.matheon.de) *
>>************************************************************************
>>
>>
>>
>>
>>------------------------------------------------------------------------
>>
>>No compiler set, using GNU compiler as default
>>--> libtoolize...
>>You should update your `aclocal.m4' by running aclocal.
>>--> aclocal...
>>--> autoheader...
>>--> automake...
>>dev/Makefile.am:16: Libtool library used but `LIBTOOL' is undefined
>>dev/Makefile.am:16:
>>dev/Makefile.am:16: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
>>dev/Makefile.am:16: to `configure.ac' and run `aclocal' and `autoconf' again.
>>dev/meta/Makefile.am:5: Libtool library used but `LIBTOOL' is undefined
>>dev/meta/Makefile.am:5:
>>dev/meta/Makefile.am:5: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
>>dev/meta/Makefile.am:5: to `configure.ac' and run `aclocal' and `autoconf' again.
>>dev/ppm/Makefile.am:5: Libtool library used but `LIBTOOL' is undefined
>>dev/ppm/Makefile.am:5:
>>dev/ppm/Makefile.am:5: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
>>dev/ppm/Makefile.am:5: to `configure.ac' and run `aclocal' and `autoconf' again.
>>dev/ps/Makefile.am:5: Libtool library used but `LIBTOOL' is undefined
>>dev/ps/Makefile.am:5:
>>dev/ps/Makefile.am:5: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
>>dev/ps/Makefile.am:5: to `configure.ac' and run `aclocal' and `autoconf' again.
>>dev/rif/Makefile.am:5: Libtool library used but `LIBTOOL' is undefined
>>dev/rif/Makefile.am:5:
>>dev/rif/Makefile.am:5: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
>>dev/rif/Makefile.am:5: to `configure.ac' and run `aclocal' and `autoconf' again.
>>dev/sif/Makefile.am:5: Libtool library used but `LIBTOOL' is undefined
>>dev/sif/Makefile.am:5:
>>dev/sif/Makefile.am:5: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
>>dev/sif/Makefile.am:5: to `configure.ac' and run `aclocal' and `autoconf' again.
>>dev/xif/Makefile.am:9: Libtool library used but `LIBTOOL' is undefined
>>dev/xif/Makefile.am:9:
>>dev/xif/Makefile.am:9: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
>>dev/xif/Makefile.am:9: to `configure.ac' and run `aclocal' and `autoconf' again.
>>dev/xif/Makefile.am:7: Libtool library used but `LIBTOOL' is undefined
>>dev/xif/Makefile.am:7:
>>dev/xif/Makefile.am:7: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
>>dev/xif/Makefile.am:7: to `configure.ac' and run `aclocal' and `autoconf' again.
>>dom/lgm/Makefile.am:25: Libtool library used but `LIBTOOL' is undefined
>>dom/lgm/Makefile.am:25:
>>dom/lgm/Makefile.am:25: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
>>dom/lgm/Makefile.am:25: to `configure.ac' and run `aclocal' and `autoconf' again.
>>dom/lgm/ngin/Makefile.am:9: Libtool library used but `LIBTOOL' is undefined
>>dom/lgm/ngin/Makefile.am:9:
>>dom/lgm/ngin/Makefile.am:9: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
>>dom/lgm/ngin/Makefile.am:9: to `configure.ac' and run `aclocal' and `autoconf' again.
>>dom/lgm/ngin2d/Makefile.am:9: Libtool library used but `LIBTOOL' is undefined
>>dom/lgm/ngin2d/Makefile.am:9:
>>dom/lgm/ngin2d/Makefile.am:9: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
>>dom/lgm/ngin2d/Makefile.am:9: to `configure.ac' and run `aclocal' and `autoconf' again.
>>dom/std/Makefile.am:24: Libtool library used but `LIBTOOL' is undefined
>>dom/std/Makefile.am:24:
>>dom/std/Makefile.am:24: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
>>dom/std/Makefile.am:24: to `configure.ac' and run `aclocal' and `autoconf' again.
>>gm/Makefile.am:35: Libtool library used but `LIBTOOL' is undefined
>>gm/Makefile.am:35:
>>gm/Makefile.am:35: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
>>gm/Makefile.am:35: to `configure.ac' and run `aclocal' and `autoconf' again.
>>gm/gg2/Makefile.am:10: Libtool library used but `LIBTOOL' is undefined
>>gm/gg2/Makefile.am:10:
>>gm/gg2/Makefile.am:10: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
>>gm/gg2/Makefile.am:10: to `configure.ac' and run `aclocal' and `autoconf' again.
>>gm/gg3/Makefile.am:10: Libtool library used but `LIBTOOL' is undefined
>>gm/gg3/Makefile.am:10:
>>gm/gg3/Makefile.am:10: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
>>gm/gg3/Makefile.am:10: to `configure.ac' and run `aclocal' and `autoconf' again.
>>graphics/Makefile.am:19: Libtool library used but `LIBTOOL' is undefined
>>graphics/Makefile.am:19:
>>graphics/Makefile.am:19: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
>>graphics/Makefile.am:19: to `configure.ac' and run `aclocal' and `autoconf' again.
>>graphics/grape/Makefile.am:15: Libtool library used but `LIBTOOL' is undefined
>>graphics/grape/Makefile.am:15:
>>graphics/grape/Makefile.am:15: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
>>graphics/grape/Makefile.am:15: to `configure.ac' and run `aclocal' and `autoconf' again.
>>graphics/uggraph/Makefile.am:15: Libtool library used but `LIBTOOL' is undefined
>>graphics/uggraph/Makefile.am:15:
>>graphics/uggraph/Makefile.am:15: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
>>graphics/uggraph/Makefile.am:15: to `configure.ac' and run `aclocal' and `autoconf' again.
>>lib/Makefile.am:31: Libtool library used but `LIBTOOL' is undefined
>>lib/Makefile.am:31:
>>lib/Makefile.am:31: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
>>lib/Makefile.am:31: to `configure.ac' and run `aclocal' and `autoconf' again.
>>low/Makefile.am:3: Libtool library used but `LIBTOOL' is undefined
>>low/Makefile.am:3:
>>low/Makefile.am:3: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
>>low/Makefile.am:3: to `configure.ac' and run `aclocal' and `autoconf' again.
>>np/Makefile.am:23: Libtool library used but `LIBTOOL' is undefined
>>np/Makefile.am:23:
>>np/Makefile.am:23: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
>>np/Makefile.am:23: to `configure.ac' and run `aclocal' and `autoconf' again.
>>np/algebra/Makefile.am:17: Libtool library used but `LIBTOOL' is undefined
>>np/algebra/Makefile.am:17:
>>np/algebra/Makefile.am:17: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
>>np/algebra/Makefile.am:17: to `configure.ac' and run `aclocal' and `autoconf' again.
>>np/amglib/Makefile.am:17: Libtool library used but `LIBTOOL' is undefined
>>np/amglib/Makefile.am:17:
>>np/amglib/Makefile.am:17: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
>>np/amglib/Makefile.am:17: to `configure.ac' and run `aclocal' and `autoconf' again.
>>np/field/Makefile.am:17: Libtool library used but `LIBTOOL' is undefined
>>np/field/Makefile.am:17:
>>np/field/Makefile.am:17: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
>>np/field/Makefile.am:17: to `configure.ac' and run `aclocal' and `autoconf' again.
>>np/procs/Makefile.am:19: Libtool library used but `LIBTOOL' is undefined
>>np/procs/Makefile.am:19:
>>np/procs/Makefile.am:19: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
>>np/procs/Makefile.am:19: to `configure.ac' and run `aclocal' and `autoconf' again.
>>np/slu/Makefile.am:19: Libtool library used but `LIBTOOL' is undefined
>>np/slu/Makefile.am:19:
>>np/slu/Makefile.am:19: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
>>np/slu/Makefile.am:19: to `configure.ac' and run `aclocal' and `autoconf' again.
>>np/slu/cblas/Makefile.am:18: Libtool library used but `LIBTOOL' is undefined
>>np/slu/cblas/Makefile.am:18:
>>np/slu/cblas/Makefile.am:18: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
>>np/slu/cblas/Makefile.am:18: to `configure.ac' and run `aclocal' and `autoconf' again.
>>np/slu/src/Makefile.am:17: Libtool library used but `LIBTOOL' is undefined
>>np/slu/src/Makefile.am:17:
>>np/slu/src/Makefile.am:17: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
>>np/slu/src/Makefile.am:17: to `configure.ac' and run `aclocal' and `autoconf' again.
>>np/udm/Makefile.am:17: Libtool library used but `LIBTOOL' is undefined
>>np/udm/Makefile.am:17:
>>np/udm/Makefile.am:17: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
>>np/udm/Makefile.am:17: to `configure.ac' and run `aclocal' and `autoconf' again.
>>parallel/Makefile.am:11: Libtool library used but `LIBTOOL' is undefined
>>parallel/Makefile.am:11:
>>parallel/Makefile.am:11: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
>>parallel/Makefile.am:11: to `configure.ac' and run `aclocal' and `autoconf' again.
>>parallel/ddd/Makefile.am:9: Libtool library used but `LIBTOOL' is undefined
>>parallel/ddd/Makefile.am:9:
>>parallel/ddd/Makefile.am:9: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
>>parallel/ddd/Makefile.am:9: to `configure.ac' and run `aclocal' and `autoconf' again.
>>parallel/dddif/Makefile.am:3: Libtool library used but `LIBTOOL' is undefined
>>parallel/dddif/Makefile.am:3:
>>parallel/dddif/Makefile.am:3: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
>>parallel/dddif/Makefile.am:3: to `configure.ac' and run `aclocal' and `autoconf' again.
>>parallel/ppif/MPI/Makefile.am:9: Libtool library used but `LIBTOOL' is undefined
>>parallel/ppif/MPI/Makefile.am:9:
>>parallel/ppif/MPI/Makefile.am:9: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
>>parallel/ppif/MPI/Makefile.am:9: to `configure.ac' and run `aclocal' and `autoconf' again.
>>parallel/util/Makefile.am:3: Libtool library used but `LIBTOOL' is undefined
>>parallel/util/Makefile.am:3:
>>parallel/util/Makefile.am:3: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
>>parallel/util/Makefile.am:3: to `configure.ac' and run `aclocal' and `autoconf' again.
>>ui/Makefile.am:19: Libtool library used but `LIBTOOL' is undefined
>>ui/Makefile.am:19:
>>ui/Makefile.am:19: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
>>ui/Makefile.am:19: to `configure.ac' and run `aclocal' and `autoconf' again.
>>
--
************************************************************************
* Oliver Sander ** email: sander at mi.fu-berlin.de *
* Freie Universität Berlin ** phone: + 49 (30) 838 75217 *
* Institut für Mathematik II ** URL : page.mi.fu-berlin.de/~sander *
* Arnimallee 6 ** -------------------------------------*
* 14195 Berlin, Germany ** Member of MATHEON (www.matheon.de) *
************************************************************************
More information about the Dune
mailing list