Bugzilla – Bug 198377
f-spot does not work
Last modified: 2006-10-22 22:49:59 UTC
starting f-spot, I directly get a window with "F-Spot encountered a fatal error". The contents is: An unhandled exception was thrown: libgphoto2.so.2 in <0x00048> (wrapper managed-to-native) LibGPhoto2.Context:gp_context_new () in <0x0001f> LibGPhoto2.Context:.ctor () in <0x0001d> GPhotoCamera:.ctor () in <0x003f1> SourceMenu:.ctor (ImportCommand) in <0x001cc> ImportCommand:ImportFromFile (PhotoStore,string) in <0x0004a> MainWindow:ImportFile (string) in <0x0004d> ImportCommand:Execute () in <0x00037> (wrapper delegate-invoke) System.MulticastDelegate:invoke_bool () in <0x0002a> IdleProxy:Handler () in <0x00036> (wrapper native-to-managed) IdleProxy:Handler () in (unmanaged) 0xb7eeb080 in <0x00004> (wrapper managed-to-native) Gtk.Application:gtk_main () in <0x00007> Gtk.Application:Run () in <0x00007> Gnome.Program:Run () in <0x005aa> FSpot.Driver:Main (string[]) .NET Version: 1.1.4322.2032 Assembly Version Information: libgphoto2-sharp (1.0.2411.40252) FlickrNet (1.1.0.0) gconf-sharp (2.8.0.0) pango-sharp (2.8.0.0) SemWeb (0.5.0.2) glade-sharp (2.8.0.0) gtkhtml-sharp (2.8.0.0) System.Data (1.0.5000.0) Mono.Data.SqliteClient (1.0.5000.0) gdk-sharp (2.8.0.0) gnome-vfs-sharp (2.8.0.0) dbus-sharp (0.62.0.0) System (1.0.5000.0) Mono.Posix (1.0.5000.0) atk-sharp (2.8.0.0) gtk-sharp (2.8.0.0) glib-sharp (2.8.0.0) gnome-sharp (2.8.0.0) f-spot (0.0.0.0) mscorlib (1.0.5000.0) Platform Information: Linux 2.6.18-rc4-2-default i686 i386 GNU/Linux Disribution Information: [/etc/lsb-release] LSB_VERSION="core-2.0-noarch:core-3.0-noarch:core-2.0-ia32:core-3.0-ia32" [/etc/SuSE-release] SUSE Linux 10.1.1 (i586) Alpha3 VERSION = 10.1.1
Guessing that libgphoto2 was updated. Larry will be doing a release shortly in stable
Stable has new packages, is this still a problem?
Yes, same error in Alpha4. The issue appears to be that libgphoto2 is not a dep of f-spot and is not installed by default. CC'ing rudi, I thought that this would be picked up by the autobuild mono deps system. If not, should be simple to add a libgphoto2 dep.
I don't see how it should be picked up automatically right now. f-spot itself _provides_ "mono(libgphoto2-sharp)", so the libgphoto2 mono bindings are provided by f-spot itself. And there does not seem to be any binary that is linked against libgphoto2 in the f-spot package. The mono find-provides/requires scripts currently do only find requires and provides for mono binaries themselves, but not for these foo.dll.config or foo.exe.config files. Actually this sounds like a useful extension to /usr/bin/mono-find-requires, maybe the mono-team can comment on this.
It would be neat if mono-find-[provides|requires] also located DllImports as well. The problem is that the selection process that the runtime uses isn't very simple. .exe.config files are not required, but can be used to provide a dllmap from the dllname used in the source code to a name or path to a specific library. The runtime also does some name mangling to try to find a library (prepends lib, tries different extensions of .so, .dll, .dylib, etc...). The other issue I see is that determining these provides at build time is not always the correct thing to do since the selection is made at runtime. It would be useful, but I'm not sure it's worth the work to come up with a correct solution.
Providing NEEDINFO...
added a libgphoto2 dep to the specfile.
So fixed for now, re-assigning to rudi for consideration of #4 and #5 with the mono-find-requires script. Note: This would catch problems we've had in the past.
well, I really don't know enough about mono internals to say how much effort a complete implementation would need. I could imagine that a tool like "ldd" for binaries would make sense for mono executables as well ... from ldd: # This is the `ldd' command, which lists what shared libraries are # used by given dynamically-linked executables. It works by invoking the # run-time dynamic linker as a command and setting the environment # variable LD_TRACE_LOADED_OBJECTS to a non-empty value. not sure if something analog is doable with mono, reassigning to mono maintainer to decide (or close this bug)
*** Bug 208411 has been marked as a duplicate of this bug. ***
*** Bug 147946 has been marked as a duplicate of this bug. ***
Turns out Debian's packaging scripts check .config files and some other things that help create most automatic dependencies. I'll have to try to integrate some of those techniques in mono's rpm find/provides. But, this is a different bug, so I'll close this one.