master branch --- build problems

[Simon Josefsson]

lfinsto at gwdg.de writes:

> Hello,
>
> After installing the most recent stable releases of autoconf, automake and
> libtool:
>
> autoconf (GNU Autoconf) 2.66
> automake (GNU automake) 1.11.1
> libtool (GNU libtool) 2.2.10
>
> I had considerable difficulty getting the master branch to build, but I
> finally succeeded, though I had to comment some things out, which isn't so
> good.

This is strange, I have bootstrapped GnuTLS on completely freshly
installed Debian and Ubuntu systems without problems.  Instead of
looking at patches to solve some intermediate problem, can you quote the
complete output you get by doing the steps describe by README-alpha on
your machine?  I.e:

$ # install all dependencies according to README-alpha
$ git clone git://git.savannah.gnu.org/gnutls.git
$ cd gnutls
$ make
$ make

> In /lib/Makefile.am, I had to remove `po' from SUBDIRS.  The error that I
> got when it was included was this:
>
> config.status: error: cannot find input file: `po/Makefile.in.in'
> configure: error: ./configure failed for lib

It's generated by the bootstrap process.  There must have been an
earlier problem.  Most of your problems also seems to be a consequence
of broken bootstrapping.

> There a quite a few warnings like this:
>
> gaa.skel:593: warning: call to 'fseek' declared with attribute warning:
> fseek cannot handle files larger than 4 GB on 32-bit platforms - use
> fseeko function for handling of large files
>
> I suspect that they're not important, unless the files can be huge for
> some reason.

Yep, it is just a warning.  Would be nice to fix, but isn't critical,
and isn't related to your build problems.

> Lots of warnings like this one:
>
> serv.c:1163: warning: cast to pointer from integer of different size
>
> It would probably be worthwhile going through and trying to get rid of
> them.

Yep.  Before working on fixing warnings, I suggest using the most recent
GCC version to make sure you aren't fixing broken compiler warnings.

> Would you possibly consider checking `configure', the `Makefile.in' files,
> the contents of the `build-aux' directories and other generated files into
> the repository?  That way one (with a bit of luck) could at least get the
> version in the master branch to build without having to jump through too
> many hoops.

No, I don't want any generated files in git.  It causes a lot of
problems for people with different auto* tool versions.  More severe
problems than what you are seeing now, actually.

> I would also be interested to know what versions of autoconf, automake and
> libtool you have installed on the systems you're using.  I assume
> everything works together smoothly  on your systems.

I have autoconf 2.65, automake 1.11.1, and libtool 2.2.6b.  Straight
from Debian testing.

> One problem I ran into was these macro invocations in the top-level
> configure.ac:
>
> AC_LIBTOOL_WIN32_DLL
> AC_PROG_LIBTOOL
>
> This is from the libtool manual (for version 2.2.10):
>
>  -- Macro: LT_INIT (OPTIONS)
>  -- Macro: AC_PROG_LIBTOOL
>  -- Macro: AM_PROG_LIBTOOL
>      Add support for the `--enable-shared' and `--disable-shared'
>      `configure' flags.(1)  `AC_PROG_LIBTOOL' and `AM_PROG_LIBTOOL' are
>      deprecated names for older versions of this macro; `autoupdate'
>      will upgrade your `configure.ac' files.

Yeah, but it should still work, and we use the old names for
compatibility with older Libtool versions.  But maybe we should drop
that...

> Before I installed libtool 2.2.10, I got an error because of
> AC_LIBTOOL_WIN32_DLL and AC_PROG_LIBTOOL.  I didn't get an error when I
> called LT_INIT, but the variable LIBTOOL wasn't defined and `configure'
> failed, unless it was `make' --- unfortunately, I didn't save this error.
>
> This, on the other hand, is from the Automake manual  (version 1.11.1, 8
> December 2009):
>
> `AC_PROG_LIBTOOL'
>      Automake will turn on processing for `libtool' (*note
>      Introduction: (libtool)Top.).
>
> LT_INIT isn't documented in this manual.  So, it would seem that Autoconf,
> Automake, and Libtool, or at least their most recent stable versions, are
> not perfectly synchronized with respect to these macros and it was rather
> frustrating trying to get `configure' and `make' to run, until it finally
> occurred to me to install a newer version of libtool.  However, since
> AC_LIBTOOL_WIN32_DLL and AC_PROG_LIBTOOL are deprecated, I think it would
> be better to use LT_INIT instead.  I've made a note to myself to try this,
> now that I've got the package to build.

Changing that doesn't result in any code difference with modern tools,
it just means older Libtool won't work with GnuTLS.  In Libidn I have
this comment:

# We can't replace this with LT_INIT([win32-dll]) yet.  For example,
# the Ubuntu 8.04 LTS is still shipping a libtool version that doesn't
# have it.
AC_LIBTOOL_WIN32_DLL
AC_PROG_LIBTOOL

I'm not sure GnuTLS trunk really bootstraps on Ubuntu 8.04 LTS any more
though...

/Simon