gnutls_ext_register causing memory corruption

[Simon Josefsson]

Martin von Gagern <Martin.vGagern at gmx.net> writes:

> Martin von Gagern wrote:
>> In the meantime, I'm trying to get a proper git bisect running.
>
> And failing miserably at it, because I'm still not comfortable with
> autotools.
>
> At first I tried varous sequences of autoheader, automake, autoconf and
> libtoolize, but configure failed every time for the lib subdir. At some
> point I got annoyed enough, and simply copied over the files from a
> 2.8.0 tarball which weren't present in the git already. 2.8.0 built
> successfully with that, but moving to 2.6.6 still causes me trouble:
>
> $ make
> CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh
> /home/mvg/src/up/gnutls/gnutls/build-aux/missing --run aclocal-1.11 -I
> m4 -I gl/m4 -I lib/gl/m4 -I libextra/gl/m4 -I lib/m4 -I libextra/m4
> aclocal-1.11: couldn't open directory `lib/gl/m4': No such file or directory
>
> So I assume that you added some gnulib macro files somewhere along the
> way. But while I could simply copy build files from 2.6.6 as well, this
> is no option for the intermediate revisions.
>
> Is there a simple command to turn a git working tree into something
> where I can do "./configure && make"?

Try 'make autoreconf'.  During the v2.7.x branch the build system was
modified heavily, so it might not always work for these experimental
releases.

The released v2.7.x tar archives should work fine though, so it may be
easier to start with those and then switch over to git when you have
pinpointed the release that breaks things.

> Preferrably without having to recompile more than absolutely
> necessary, and without having to actually run configure if its input
> wasn't modified?

Between releases that is not likely to be the case, M4 files change in
practically every release.

/Simon