Hello Joakim, * Joakim Tjernlund wrote on Tue, Dec 08, 2009 at 03:23:39PM CET: > > We just upgraded libtool from 1.5.26 to 2.2.6 and our build > broke. Our host requires 2.2.6 so keeping the old appears difficult. > > Even though we only run autoreconf manually in our project, the new libtool > slipped into the project and the build broke. > I can fix this by rerunning autoreconf -i -f in the current trunk but > I cannot do that in already released SW. > I had the impression that the libtool files installed by libtoolize -f > should contain everything needed by libtool, that is, there would not be > any dependencies of the host libtool.
That is normally the case. Note that with Libtool 2.2.x, you can also use the following strategy: add AC_CONFIG_MACRO_DIR([m4]) to configure.ac, add ACLOCAL_AMFLAGS = -I m4 to Makefile.am, and run 'libtoolize -f --install' to have the Libtool macro files be copied into your tree. That way, aclocal.m4 will refer to them (rather than carry around a copy of their contents). > How can I prevent the new host libtool from slipping into > the project? I'm afraid I can't tell you with the information that you have given. Please show, not describe, how the host Libtool gets into your project; i.e., cut and paste the commands you enter and their output that shows something goes wrong. If your project is open source, don't refrain to link to a tarball or repository. > I would like to be able to run autoreconf even after upgrading the > host libtool too, if possible. Ah, if all you're after is to prevent autoreconf from running libtoolize, then try LIBTOOLIZE=true autoreconf Another issue may be that aclocal fails to find the in-tree libtool macros, but finds some installed ones. That can typically be found out by passing --verbose to aclocal (passing --verbose to autoreconf will do that). Hope that helps. Cheers, Ralf _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
