[Kst] Kst 1.8.x build issue

D. V. Wiebe dvw at ketiltrout.net
Sat Feb 13 05:49:17 CET 2010

On Thu, Nov 19, 2009 at 11:49:21AM -0500, Matthew D Truch wrote:
> Hmmm,
> I'm getting the following error when building recent kst 1.8.x when the
> *exact same* build used to work (a few months back).  My guess is that
> some system library dependencies changed and I need to include more
> stuff, but I don't know where to begin to look.  Can someone please
> decifer these errors:
> make[5]: Entering directory
> `/builddir/build/BUILD/kst-1.8.0/kst/src/kst'
> /bin/sh ../../../libtool --silent --tag=CXX   --mode=link g++  -DNDEBUG
> -DNO_DEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
> -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom
> -fasynchronous-unwind-tables -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST
> -L/usr/lib/qt-3.3/lib     -L/usr/lib -L/usr/lib/netcdf  -o kst main.o
> ../libkstapp/libkstapp.la 
> g++: ../libkstapp/.libs/libkstapp.so: No such file or directory
> g++: /builddir/build/BUILD/kst-1.8.0/kst/src/widgets/.libs/libkstwidgets.so: No such file or directory
> g++: /builddir/build/BUILD/kst-1.8.0/kst/src/libkstmath/.libs/libkstmath.so: No such file or directory
> g++: /builddir/build/BUILD/kst-1.8.0/kst/src/libkst/.libs/libkst.so: No such file or directory
> g++: /builddir/build/BUILD/kst-1.8.0/kst/src/extdate/.libs/libkstextdate.so: No such file or directory
> make[5]: *** [kst] Error 1
> make[5]: Leaving directory `/builddir/build/BUILD/kst-1.8.0/kst/src/kst'
> make[4]: *** [all-recursive] Error 1
> make[4]: Leaving directory `/builddir/build/BUILD/kst-1.8.0/kst/src/kst'
> make[3]: *** [all-recursive] Error 1
> make[3]: Leaving directory `/builddir/build/BUILD/kst-1.8.0/kst/src'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory `/builddir/build/BUILD/kst-1.8.0/kst'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/builddir/build/BUILD/kst-1.8.0'
> make: *** [all] Error 2

While talking with Joe Fowler today about GetData, I was reminded of
this bug.  Has it been fixed?  If not, here's a work-around that works
at least on Ubuntu 9.10 (which otherwise fails with the same error).  For
the magic to work, you must start with a clean extract from the tarball:

$ tar -zxvf kst-1.8.0.tar.gz
$ cd kst-1.8.0
$ touch aclocal.m4
$ touch Makefile.in
$ touch configure
$ touch config.h.in
$ ./configure
$ make

Read on if you want to know why the magic works.

Short version: autotools.

Long version:

Here's the problem: as g++ points out, ../libkstapp/.libs/libkstapp.so
doesn't exist.  Actually, it's a symlink and *does* exist, but the thing
it points to, ../libkstapp/.libs/libkstapp.so.1.0.8 doesn't exist.  That
dosn't exist because libtool never built it when it should have.  (If
you remove the --silent flag to libtool, you can notice this in the
build log when make runs through the kst/src/libkstapp subdir.)

This is where the magic comes in: the copy of libtool shipped with kst
in the tarball does the Right Thing, and *will* properly compile kst.

We run into trouble when we rebuild libtool ourselves as part of the
build process.  In general, we shouldn't have to do that since it's
given to us in the tarball, but there's a "bug" in the tarball itself:
some of the files in the tarball have weird timestamps.  Specifically:

* configure.in is newer than ./aclocal.m4, ./Makefile.in and
  ./config.h.in, all of which use it as an input.

* aclocal.m4 is newer than ./Makefile.in (again) and ./configure, both
  of which use it as an input.

Rules in the Makefile set out how to rebuild aclocal.m4, Makefile.in,
config.h.in, and configure from these two files (plus others).  So, when
we start "make", the first thing that happens, is make notices these
files are out-of-date, and rebuilds the entire build tools, including
libtool, using the system-installed autoconf/automake/libtool suite.

The magic above gets around the tarball "bug" by simply adjusting the
timestamps of these four files (in the right order) so they're newer
than their inputs, and "make" thinks everything in the build tools is
up-to-date, and leaves the supplied libtool alone.

So, what's the real probelm?  Why doesn't the rebuilt libtool work?
I don't know.  If I had to guess, I'd say that some update to one of
autoconf, automake, or libtool has broken the KDE3 build system. (Is it
still being maintained?)  As a result, there's some grotty interaction
between the our system-installed auto-whatever-tool and the m4 macros
provided by KDE3 in the admin/ subdir, which ends up producing a
broken libtool.

Debian sees this problem in 1.7.0 because (for whatever reason) they
explicitly rebuild all the tools, even though the timestamp "bug" isn't
present in the kst-1.7.0 tarball.   I think Slackware doesn't see this
problem because the rebuild of the tools fails (because Slack's automake
executable is called "automake" and not "automake-1.10") which means the
working libtool distributed with kst is happily left unmolested, and
make soldiers on.

Matt, I can't find the build logs on koji anymore (presumably they've
been purged), but I'd guess it was rebuilding libtool just like Ubuntu
9.xx does here.  If that's the case, the above should do the trick.

Don Wiebe                                   dvw at phas.ubc.ca
Department of Physics and Astronomy
University of British Columbia
6224 Agricultural Road                      Tele: +1-604-822-2585
University Endowment Lands, BC
Canada   V6T 1Z1                            http://ketiltrout.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kst/attachments/20100212/75e7b4d0/attachment.sig 

More information about the Kst mailing list