Hi Bob,
On Oct 23, 2012, at 8:36 PM, Bob Friesenhahn <bfrie...@simple.dallas.tx.us>
wrote:
> There are still some continuing minor issues related to 'git', 'bootstrap',
> and 'make'. What I am seeing here is that after a successful 'make check'
> with a particular vintage of git-sourced code, an existing build directory
> will fail to 'make' after obtaining additional updates via git. The build
> does not seem to be sufficiently self-maintaining to serve the whole function
> provided by 'bootstrap'. If I re-do the bootstrap procedure, then it works.
> The following is the trailing end of a 'gmake' in an existing build tree:
>
> /bin/bash ./config.status
> config.status: creating Makefile
> config.status: creating config.h
> config.status: linking /home/bfriesen/src/gnu/libtool-head/GNUmakefile to
> GNUmakefile
> config.status: executing tests/atconfig commands
> config.status: executing depfiles commands
> config.status: executing libtool commands
> GEN libtoolize
> (CDPATH="${ZSH_VERSION+.}:" && cd /home/bfriesen/src/gnu/libtool-head &&
> /bin/bash /home/bfriesen/src/gnu/libtool-head/build-aux/missing --run
> autoheader)
> rm -f stamp-h1
> touch /home/bfriesen/src/gnu/libtool-head/config-h.in
> cd . && /bin/bash ./config.status config.h
> config.status: creating config.h
> config.status: config.h is unchanged
> gmake all-recursive
> gmake[1]: Entering directory `/scratch/bfriesen/build/libtool-head'
> Making all in .
> gmake[2]: Entering directory `/scratch/bfriesen/build/libtool-head'
> test -f doc/.dirstamp || gmake doc/.dirstamp
> gmake[3]: Entering directory `/scratch/bfriesen/build/libtool-head'
> gmake[3]: Leaving directory `/scratch/bfriesen/build/libtool-head'
> Updating /home/bfriesen/src/gnu/libtool-head/doc/version.texi
> CC libltdl/loaders/libltdl_libltdl_la-preopen.lo
> libtool: Version mismatch error. This is libtool 2.4.2.319-d98a, revision
> 2.4.2.319,
> libtool: but the definition of this LT_INIT comes from revision 2.4.2.321.
> libtool: You should recreate aclocal.m4 with macros from revision 2.4.2.319
> libtool: of libtool 2.4.2.319-d98a and run autoconf again.
> gmake[2]: *** [libltdl/loaders/libltdl_libltdl_la-preopen.lo] Error 63
> gmake[2]: Leaving directory `/scratch/bfriesen/build/libtool-head'
> gmake[1]: *** [all-recursive] Error 1
> gmake[1]: Leaving directory `/scratch/bfriesen/build/libtool-head'
> gmake: *** [all] Error 2
We're caught between a rock and a hard-place here, and unless I'm mistaken
this is not a recent development -- it's something we've been dealing with since
we moved from counting date-headers in ChangeLog to using git-version-gen
output in ltversion.m4 and ltmain.sh.
See the notes in Makefile.am for why we need to build certain files with
bootstrap
rather than with configure, one of those being ltmain.sh, which is then used
by libtool to make sure that the version numbers between ltmain.sh and
ltversion.m4 match, to save us from all the Xsed is not defined errors and
other problems caused by using mismatched libtool.m4 and ltmain.sh.
We're using git-version-gen to get the 319-d98a part of the version number in
the error message you see above, which immediately goes out of date if you
git push, pull, commit, or change branches, causing the Automake
regeneration rules to trigger, updating ltversion.m4, but not ltmain.sh.
So, there's no need to run a complete bootstrap when the version number
changes under an already-configured tree. If you get this error, just force
regeneration of the files not handled by Automake autoregeneration:
make bootstrap-deps
Of course that will trigger the Automake autoregeneration rules to rerun
configure et. al. just like we used to have, only now you get to choose when
you force that, rather that getting it on every single build. I can't think of
a
way to get bootstrap-deps to run only when it's needed, and certainly don't
want to go back to double configuration on every build like we used to endure.
Of course, if any one can provide a patch that will regenerate both ltversion.m4
and ltmain.sh (and then libtool) when git-version-gen output changes -- but
without breaking the constraints required for make distcheck to pass, and
without requiring two full configure runs like we used to have -- then I'll be
very happy to test it. But please don't send any theories that might work if
only I'll spend several hours implementing and testing them... I've been down
this route before, and I'm already convinced that there isn't a good solution.
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
_______________________________________________
https://lists.gnu.org/mailman/listinfo/libtool
