[Dune] Verwendung von DUNE und der aktuellen UG-Version

[lenzen at scai.fraunhofer.de]

------------------------ Ursprüngliche Nachricht -------------------------
Betreff: Re: [Dune] Verwendung von DUNE und der aktuellen UG-Version
Von:     lenzen at scai.fraunhofer.de
Datum:   Fr, Mai 25, 2007 10:26
An:      "Christian Engwer" <christi at uni-hd.de>
         dune at scai.fraunhofer.de
         lenzen at scai.fraunhofer.de
--------------------------------------------------------------------------

Hello Christian,

> I must admit, I don't know what Oliver changed. I just tried it myself
> and everything works like a charm, except, that the documentation
> Oliver put on the webpage is plain wrong. configure is still called
> from autogen.sh.
> * Are you using vanilla UG or the patched version?

I checked out ug (the patched version from the DUNE repository) again to
ensure we've got the same version. The last line of autogen.sh,
eval ./configure <options>,
is commented out. I've tried vanilla UG, but I get into the same problems.

> * Which version of autoconf are you using?

My version of autoconf is 2.59
For completeness:
gcc/g++: 3.4.6
automake: 1.9.6
libtool: 1.5.6
pkg-config: 0.15.0

> * could you please run the commands in autogen.sh manually and supply
>   the --verbose option? Please send the output to te list.

I executed the commands from autogen.sh in the given order with the same
options and an additional option for verbose output, piping stderr and
stdout into the appended files. I was really confused when I found a
configure script as output. Renaming the script and running autogen.sh
again didn't result in a configure script. Are there any variables defined
in autogen.sh which should be set when running any of the commands? It
seems to me as if the defined variables are collected for the configure
call exclusively, but there must be a reason for the different behaviour.

I appended the output, named after the called command. Except perhaps the
hint from libtoolize to update aclocal (which is called afterwards)
everything looks okay until automake. It doesn't create several
Makefile.in's and misses install-sh, missing, depcomp and compile. These
are all availible, so is $LIBTOOL, which automake claims not to be set,
the place where automake looks for them? The following call of autoconf
has errors too, but they may come from the previous problems with
automake.

For testing reasons I called the corrupt configure script that was
created. The first errors correspond to the missing Macros (see
autoconf.txt) and it aborts because a Makefile.in misses (automake.txt).

I tried "set LIBTOOL=$UGROOT" and called automake, but that idea is to
simple - it still states that LIBTOOL is undefined.

Christoph
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: libtoolize.txt
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20070525/3c961091/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: aclocal.txt
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20070525/3c961091/attachment-0001.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: autoheader.txt
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20070525/3c961091/attachment-0002.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: automake.txt
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20070525/3c961091/attachment-0003.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: autoconf.txt
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20070525/3c961091/attachment-0004.txt>