After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 305544 - Please use current libtool
Please use current libtool
Status: RESOLVED DUPLICATE of bug 305641
Product: gnome-common
Classification: Core
Component: general
git master
Other All
: Normal normal
: ---
Assigned To: Gnome Common Maintainer(s)
Gnome Common Maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2005-05-26 13:09 UTC by Stepan Kasal
Modified: 2005-05-27 10:56 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Stepan Kasal 2005-05-26 13:09:43 UTC
I have Gnome installed with prefix /opt/gnome2.
When I build gnome-vfs, the build fails because of some inter-library dependencies.

The build works if I use a newer libtool.  I'd be glad if you could upgrade
libtool on the host where you make releases.  Version 1.5.6 from 2003 is really
too old.

I raised the priority to get the message through.
Comment 1 Stepan Kasal 2005-05-26 13:57:47 UTC
Actually, I found out there are two ways to fix the problem:
1) running "make LIBTOOL=libtool" which replaces the distributed libtool script
with the current version I have installed on my machine

2) running "aclocal && autoconf && automake" before ./configure;
This replaces Automake 1.6 by version 1.9.

But the combination of old tools was deadly for my environment.

Besides upgrading libtool on the machine used to make dists, I suggest that you
use automake 1.9 for dist tarballs.  (Gnumeric does this, I think.) 
Unfortunately, because current gnome-autogen has a tendency to prefer older
automake, you have to temporarily change REQURED_AUTOMAKE_VERSION to 1.9 in your
autogen.sh before making the distribution.
Comment 2 Christian Neumair 2005-05-26 14:14:47 UTC
Thanks for your bug report.
Nautilus simply invokes gnome-autogen.sh, this should be solved for all packages
using it. As far as I know, it was planned to require more recent
autotools/libtool versions in new gnome-common versions. From what I can see
from CVS, it still requires 1.4, though, which is very lax.
Reassigning to gnome-common.
Comment 3 Christophe Fergeau 2005-05-26 15:57:41 UTC
What kind of system are you using to get libtool issues? Can you be more precise
about the issues you are getting?
Released tarballs happen to use whatever autotools are available on the machine
of the developer doing the release. At least on debian and ubuntu, the latest
libtool package available is 1.5.6, so getting a more up to date package in
distros would help I guess ;) Another possibility is also to enforce using a
"not too old" libtool in gnome-common, but that may annoy people making releases
if the necessary libtool version isn't easy to get.
Comment 4 Sebastien Bacher 2005-05-26 16:09:31 UTC
what the issue with libtool 1.5.6?
Comment 5 Stepan Kasal 2005-05-27 05:26:46 UTC
Linking programs/gnomevfs-cat failed, stating that it cannot find from
libbonobo-2.so and libORBitCosNaming-2.so.  At that moment, gnomevfs-cat is
linked against not-yet-installed library libgnomevfs-2.so.

With newer automake or newer libtool, you get explicit
/opt/gnome2/lib/libbonobo-2.so and /opt/gnome2/lib/libORBitCosNaming-2.so on the
gcc command line generated by libtool.

OK, it really takes more then 9 months for libtool to get to unstable.
This is yet another reason why we should upgrade automake, stay tuned...
Comment 6 Stepan Kasal 2005-05-27 10:56:10 UTC
OK, this should be solved in gnome-autogen.sh .
Because my original bug report was confused, I started a new bug, #305641.
So I close this one.

*** This bug has been marked as a duplicate of 305641 ***