On Mon, 6 Feb 2006, Quentin Garnier wrote:

> > >  gcc: @LIBTOOL_EXPORT_OPTIONS@: No such file or directory
> >
> > This package does indeed set LIBTOOL_EXPORT_OPTIONS in configure[.ac], but
> > that is never AC_SUBST()ed -- so it's no wonder this is broken.  Did it ever
> > work before commit?  Perhaps autoconf auto-running makes it "work"?
>
> Something has changed in libtool I think.  If you have a look at the
> failure for misc/gkrellm-leds, you'll see that it was about the same,
> with a variable @GK_LDFLAGS@.  That one was never set anywhere, so the
> configure script can't be the a part of the issue.

So it seems that the bug IS that it's not set properly in "configure", and
libtool<1.5.22 was papering over said bug.  I just tested:

=====
$ ./libtool-1.5.18 --version |head -1
ltmain.sh (GNU libtool) 1.5.18 (1.1220.2.245 2005/05/16 08:55:27)

$ ./libtool-1.5.18 --mode=link cc -o libx.la @FOO@ -avoid-version -rpath /usr/lib
cc -shared    -Wl,-soname -Wl,libx.so -o .libs/libx.so
ar cru .libs/libx.a
ranlib .libs/libx.a
creating libx.la
(cd .libs && rm -f libx.la && ln -s ../libx.la libx.la)

$ libtool --version|head -1
ltmain.sh (GNU libtool) 1.5.22 (1.1220.2.365 2005/12/18 22:14:06)

$ libtool --mode=link cc -o libx.la @FOO@ -avoid-version -rpath /usr/lib
cc -shared    @FOO@ -Wl,-soname -Wl,libx.so -o .libs/libx.so
cc: @FOO@: No such file or directory
=====

It seems that libtool 1.5.22 exposed bugs that were *already there*.  I
wouldn't be surprised, for instance, if inputmethod/libchewing had symbol
conflicts at runtime linker time with some applications, due to the missing
-export-symbols-regex (which was set by "configure" but never AC_SUBST()ed
properly).

-- 
-- Todd Vierling <tv@duh.org> <tv@pobox.com> <todd@vierling.name>