GNOME Bugzilla – Bug 361943
"Could not find a part of the path" / 0.11.1 crashes on startup
Last modified: 2006-10-14 10:22:14 UTC
I have seen this issue in the mailing list archives¹ and I get exactly the same: --- Could not find a part of the path "/home/nx/code/cvs/gnome/banshee/${prefix}/share/banshee". System.IO.DirectoryNotFoundException: Could not find a part of the path "/home/nx/code/cvs/gnome/banshee/${prefix}/share/banshee". at System.IO.FileStream..ctor (System.String name, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, Boolean anonymous, FileOptions options) [0x00000] at System.IO.FileStream..ctor (System.String name, FileMode mode, FileAccess access, FileShare share) [0x00000] at (wrapper remoting-invoke-with-check) System.IO.FileStream:.ctor (string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare) at System.Xml.XmlUrlResolver.GetEntity (System.Uri absoluteUri, System.String role, System.Type ofObjectToReturn) [0x00000] at Mono.Xml2.XmlTextReader.GetStreamFromUrl (System.String url, System.String absoluteUriString) [0x00000] at Mono.Xml2.XmlTextReader..ctor (System.String url, System.Xml.XmlNameTable nt) [0x00000] at System.Xml.XmlTextReader..ctor (System.String url, System.Xml.XmlNameTable nt) [0x00000] at System.Xml.XmlDocument.Load (System.String filename) [0x00000] at Banshee.AudioProfiles.ProfileManager..ctor (System.String path) [0x00000] at Banshee.Base.Globals.<#AnonymousMethod>75 () [0x00000] at (wrapper delegate-invoke) System.MulticastDelegate:invoke_void () at Banshee.Base.ComponentInitializer.Run () [0x00000] at Banshee.Base.Globals.Initialize () [0x00000] at Banshee.BansheeEntry.Startup (System.String[] args) [0x00000] at (wrapper delegate-invoke) System.MulticastDelegate:invoke_void_string[] (string[]) at Banshee.Gui.CleanRoomStartup.Startup (Banshee.Gui.StartupInvocationHandler startup, System.String[] args) [0x00000] --- The problem seems to be src/Banshee.Base/ConfigureDefines.cs, after running autogen on a fresh CVS checkout it ends up being the following: --- namespace Banshee.Base { public sealed class ConfigureDefines { public const string SystemDataDir = "${prefix}/share/banshee/"; public const string LOCALE_DIR = "/opt/gnome2.18/share/locale/"; public const string InstallDir = "/opt/gnome2.18/lib/banshee/"; public const string PACKAGE = "banshee"; public const string VERSION = "0.11.1"; public const string GETTEXT_PACKAGE = "banshee"; public const string ICON_THEME_DIR = "${prefix}/share/icons/hicolor/"; } } --- "${prefix}" seems to be interpreted wrong or it should be expanded to /opt/gnome2.18, if I fix the two lines manually and run make install again it works just fine. [1] http://mail.gnome.org/archives/banshee-list/2006-October/msg00063.html
My answer on the list was to ensure you were running autogen, etc. But as you say this is a clean checkout, it might be a problem with the expansion of datadir in configure.ac. In ConfigureDefines.cs.in, you can see: public const string SystemDataDir = "@expanded_datadir@/@PACKAGE@/"; Where @expanded_datadir@ should actually be expanded in ConfigureDefines.cs. Clearly it is not in your case. I cannot reproduce this on my system. Here's the expansion in configure.ac: expanded_datadir=`( case $prefix in NONE) prefix=$ac_default_prefix ;; *) ;; esac case $exec_prefix in NONE) exec_prefix=$prefix ;; *) ;; esac eval echo $datadir )` AC_SUBST(expanded_datadir) Please give me the exact versions of autoconf, automake.
Confirmed. The problem is not the lack of expansion, it seems like the ${prefix} inside the expanded variable does not get expanded. ruben@tokyo:~ $ autoconf --version autoconf (GNU Autoconf) 2.60 Written by David J. MacKenzie and Akim Demaille. Copyright (C) 2006 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. ruben@tokyo:~ $ automake --version automake (GNU automake) 1.9.6 Written by Tom Tromey <tromey@redhat.com>. Copyright 2005 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. This is Ubuntu Edgy.
I'm on edgy too, but I was using autoconf 2.13 at the time, but using the newer automake doesn't change a thing. Itried to understand the problem but I cannot see why it wouldn't be expanded as InstallDir is for example...
I'm actually seeing this now on SUSE 10.2 Alpha5. Works fine in SLED.
The culprit is autoconf 2.60. On SLED (autoconf 2.59), there's no problem. The problem specifically is this: In <= 2.59 $datadir = ${prefix}/share Which is what we expect, but in 2.60+ it's $datadir = ${datadirroot} <rant>So congratulations to autoconf for totally fucking things over. What's a commitment to an API anyway? Apparently not a damn thing.</rant> This probably breaks things in F-Spot too.
Okay, this only affects $datadir. $bindir and $libdir work as usual (so this doesn't actually break F-Spot, which just expands $libdir). Running a second expansion on expanded_datadir does the trick: expanded_datadir=`(case $prefix in NONE) prefix=$ac_default_prefix ;; *) ;; esac case $exec_prefix in NONE) exec_prefix=$prefix ;; *) ;; esac eval echo $datadir )` expanded_datadir=`(case $prefix in NONE) prefix=$ac_default_prefix ;; *) ;; esac eval echo $expanded_datadir )` Fixed in HEAD, good catch guys, just before the 0.11.1 release. /me stabs autoconf. Please update and test.
A bit strange, my standard autoconf clearly says it's 2.13 (I have autoconf, autoconf2.13 and autoconf2.50) but that seems to be a strange kind of wrapper that runs the newer version nevertheless, great. With latest HEAD, SystemDataDir and ICON_THEME_DIR look good though, works great again, thanks.