From kde-core-devel Sun Mar 10 10:18:07 2002 From: Michael Matz Date: Sun, 10 Mar 2002 10:18:07 +0000 To: kde-core-devel Subject: That admin/libtool update X-MARC-Message: https://marc.info/?l=kde-core-devel&m=101575604409032 Hi all, If answering bear in mind, I don't read kde-devel@, so either include me directly, or use kde-core-devel@. short version: * get autoconf 2.52, automake 1.5 if you don't have them already * rm -rf $buildir (1) * make -f Makefile.cvs * (cd $builddir; $srcdir/configure $kdeconfoptions; make; make install) alternative to (1) without guarantees: * rm $builddir/config.cache * find $builddir -name '*.la' | xargs rm * find $builddir -type f -perm 755 | xargs rm long version: the last days there was some heat on the lists about the recent libtool update. My mail to kde-core and kde-solaris/nonunix obviously wasn't enough, and I can understand people seeing it like this. I should have mentioned, that it requires autoconf 2.5x. That it will need relinking everything is something which I considered immediately clear, but obviously I was wrong in that respect. I'm sorry I didn't send out a mail explaining it in excruciating detail when I commited it, but at that time I could barely walk straight, not because of the amount of alcohol I usually need before working on libtool (read my poem regarding that on a former update of libtool on kde-cvs@), but because of not sleeping for 36 hours or so, after an active week. That's the reason I also wasn't available yesterday, so I couldn't react sooner. Anyway we (I) had good reasons to not only update libtool, but also put it into the release candidate. Please do not think we made this decision lightly. The libtool we were using was based on a discontinued version of libtool, which never has seen a release. Not only that, it also was heavily changed for KDE. This became more and more of a burden. One reason is, that we couldn't incorporate easily changes from the libtool maintainers (because they are working on a completely different code base), another reason is that we were getting bugreports, which couldn't be easily forwarded to the libtool guys. The reason for really really wanting it in the release candidate should be obvious: more testing. As it also changes some bits in the built libraries we don't want such an update in some minor version, so KDE 4 would be the next opportunity. Until then it probably would've broke apart. So the time was pressing. Eventual build bugs can be fixed the next week, even without needing a new release candidate (that's currently only my opinion, but I think Dirk will agree). Now to the technical side. The current system is known to work with autoconf 2.52 and automake 1.5 on linux. For automake 1.4 I installed a hack, so that seems to work too. automake 2.53 gives strange warnings which are not caused by us, at least that's my current belief. automake 1.6 isn't tested by me (was just released some days ago), but reported to have issues. Those things I will investigate. Some months ago I considered to "port" the then current libtool back to autoconf 2.13, but never really did the work, partly because it's not really usefull, as 2.5x is widely available, but see below. For rebuilding: either start completely from scratch, or remove (in the builddir) all .la files and all executables. Remove config.cache, Make Makefile.cvs, reconfigure, rebuild. Done. There was a small time window where kdesupport was broken, just at the time libtool was updated. If you get strange warnings about libxml.la or libxslt.la, update kdesupport and rebuild. autoconf/automake are development tools. They are not needed for those downloading tarballs/snapshots or release candidates. I.e. they are needed only for developers. I expected developers to be able to update two stinky packages on their own. There are other projects which have much stricter prerequisits, than just some version of autoconf/make released a long time ago. Sorry, but I can't resist to say: If you fear about "updating you operating system" (although I find it strange that someone believes to have to update a system for a package), then for gods sake, just install that tool into /usr/local, which is even how it installs itself by default. Or to be really really sure, into $HOME/install. That way it can't disrupt anything. That being said yesterday coolo installed a hack for all who didn't want to update auto*. Please be aware, that this will not last for long, and bugreports against admin/old-* will be forwarded to /dev/null. Please use more current auto*, and try to find build bugs with them, which exist, I'm sure. Even more so, on archs != linux, as the new libtool is a little bit stricter. Ciao, Michael. P.S: That with the alcohol was a joke, for those of you permanently stern.