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 130815 - compile error with 0.9.4
compile error with 0.9.4
Status: RESOLVED DUPLICATE of bug 112348
Product: gok
Classification: Deprecated
Component: build
unspecified
Other Windows
: Normal normal
: ---
Assigned To: David Bolter
David Bolter
Depends on:
Blocks:
 
 
Reported: 2004-01-07 21:11 UTC by Matt Lavin
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: 2.5/2.6



Description Matt Lavin 2004-01-07 21:11:50 UTC
This is the same bug as bug 129629 but for some reason I don't have the
option to re-open it.  

I disagree about it being a problem with libtool.  It might be a problem
with the version of libtool that gok includes, but every other desktop
component (the 2.5.2 set) compiles fine without SED being defined.

I tried to find a difference between gok and other components and all I can
tell is that the version of libtool packaged with it must be broken in some
way.  

Is it possible that an old version of libtool is being included with gok?
Comment 1 David Bolter 2004-01-07 21:26:06 UTC
dtb@otter:~/code/gok> ./libtool --version
ltmain.sh (GNU libtool) 1.5 (1.1220.2.1 2003/04/14 22:48:00)

Copyright (C) 2003  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
dtb@otter:~/code/gok> 
Comment 2 bill.haneman 2004-01-07 23:46:44 UTC
matt - I've seen this with other GNOME components as well.

Perhaps the 0.9.4 tarball includes a b0rked libtool - libtool isn't in
CVS so it's not part of GOK sources _per se_.

there are other reports of build issues with 0.9.4, due to a packaging
problem in make dist.  Unfortunately I haven't been able to diagnose
the problem, which seem to be on the dist build machine (my machine!),
and it, err, "works for me".
Comment 3 Matt Lavin 2004-01-08 13:01:01 UTC
I looked for other instances of this problem in gnome bugzilla.  I 
found two different instances, bug 112348 and bug 104895.  I'm not 
even close to a libtool/autoconf/automake expert but maybe it will 
help
Comment 4 David Bolter 2004-01-12 14:51:20 UTC
Bill are you taking this?

I've closed the related bug 130807

I don't feel qualified to follow up on this general libtool issue.  
Comment 5 bill.haneman 2004-01-27 16:08:27 UTC
closing as dup of 112348 (though it's not strictly the same, being a
different package).  I think the libtool.m4 used in 0.9.4 was faulty.

If this problem reappears with a GOK tarball post-0.9.10, please
re-open this bug and I'll try (again) to fix.

*** This bug has been marked as a duplicate of 112348 ***
Comment 6 Malcolm Tredinnick 2004-01-27 22:25:15 UTC
This is not going to be fixed if I do something about #112348. The
latter bug concerns building from CVS (i.e. running autogen.sh and
hence installing the system libtool when libtoolize is run). This bug
is about building from tarballs, which uses the libtool scripts that
are shipped with the tarballs. There is a difference. The
circumstances in this bug can only be fixed by using non-broken
libtool scripts on the machine used the make the tarball.

I'm not going to un-duplicate things (leaving that up to somebody
involved with this bug), but just letting everybody know that somebody
may have misunderstood something here.
Comment 7 bill.haneman 2004-01-28 12:47:48 UTC
Malcolm; I thought your fix for #112348 would fix this issue
long-term, i.e. subsequent tarballs delivered from machines where
112348 was fixed wouldn't have broken libtools, and thus the tarballs
would be OK.