GNOME Bugzilla – Bug 112348
libtool version conflict
Last modified: 2004-12-22 21:47:04 UTC
When running configure for gnopernicus libtool-1.4.3 is required. However, when running make install, libtool-1.4.3 fails, but libtool 1.4.1 succeeds. When running make install while using libtool 1.4.3, the error message: ../libtool: line 1: s%^.*/%%: No such file or directory is generated repeatedly.
Don: Do you have the environment variable "SED" defined? I believe you need this environment variable for building; if this is the problem then it's not gnopernicus-specific.
It's libtool's problem. Libtool does some checking for the "best" sed on your system so it seems not to be able to find it. The workaround is: export SED=sed This issue that you are discribing is happening to atk, gnome-mag, gnopernicus etc, because in the CVS version of gnome-common (which I suppose you use), some time ago, the standard autogen.sh script was updated, introducing dependecy on libtool-1.4.3.
Bill, I did not have the environment variable SED set. Once I set it libtool 1.4.3 worked fine. Is there a way to add the set to the libtool script?
moving this to gnome-common; I think the default install tools need to check for $SED now and at least warn the user if it's not set.
You should not need to have $SED set. But I will try to come up with some kind of work around for broken systems. Having things mysteriously break for people is not acceptable. Grrr ... I just _love_ trying to work out what libtool is smoking under the covers. It makes the rest of my life seem so much better in contrast. :-(
Just a progress report here: I just managed to reproduce these exact symptoms when I accidently built something with the wrong prefix set. So the immediate libtool scripts were pointing to my /gnome/head/INSTALL prefix, but other parts were coming from the /usr installation. I will investigate further, but I suspect this bug may be a result of a bad libtool installation or an incorrect path setting.
Marking AP3 to reflect a11y team's assessment of a11y impact.
Can somebody from the accessibility team please explain their evluation here? I could quite validly close this report as NOTABUG, since that is a valid assesment. The only reason I have left it open is so that I can think about adding some preventative error checking to the standard autogen.sh.
Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME bug list :)
Malcolm: I think the preventative error checking might be called for, since this seems to be hitting a lot of folks. In particular it seems to hit folks who attempt to build 'part' of GNOME on top of an existing installation.
*** Bug 130815 has been marked as a duplicate of this bug. ***
this was due to a bad version of libtool. I suppose one could argue that gnome-common should have detected that, but I will close this bug as NOTGNOME since I think the real issue was failure of many apps to increment the libtool-required-version. THere's probably a gnome-common bug in here somewhere, but I don't think there's interest revisiting it at this time. Am I right?