GNOME Bugzilla – Bug 710743
2.9 & 2.6 not launching on OS X Mavericks
Last modified: 2020-03-17 09:52:46 UTC
The application won't open on OS X 10.9.
Banshee 2.9.1 was working great on OSX 10.8, then I recently updated to 10.9 Mavericks and it crashes on startup. The crash occurs before any of the window is drawn. I only see anything about it in the main system log, where the crash shows up as follows: 10/24/13 11:39:07.238 AM com.apple.launchd.peruser.501[335]: (fm.banshee.Banshee.13408[1288]) Exited with code: 1 Are there other log locations I could look into, or any other troubleshooting information I can provide to help track the cause?
My apologies - 2.6.1 is the version that is the stable osx release, that was a typo
A little bit more info - ultimately no real leads, but hopefully more details will help narrow it down. I tried launching banshee from the command line with both "open -a Banshee.app" and "sudo [...]", and received this response: LSOpenURLsWithRole() failed for the application /Applications/Banshee.app with error -10810. According to the documentation here, that error means: (https://developer.apple.com/library/mac/documentation/Carbon/Reference/LaunchServicesReference/Reference/reference.html#//apple_ref/c/func/LSOpenURLsWithRole) LSUnknownErr -10810 An unknown error has occurred. On a lark, just in case it was a permissions thing, I tried rebooting with cmd-R and running repair disk and repair permissions on the main system hard drive, and still have the same result.
My apologies for spamming the thread. It might be a mono issue - if I'm looking at it correctly, the packaged version of mono with 2.6.1 osx binary is mono 2.0, and according to the mono changelogs (http://www.mono-project.com/Release_Notes_Mono_3.0) Mono 3.0.12 was the oldest version to support osx 10.9. Is that possibly the issue?
(In reply to comment #4) > My apologies for spamming the thread. > > It might be a mono issue - if I'm looking at it correctly, the packaged version > of mono with 2.6.1 osx binary is mono 2.0, and according to the mono changelogs > (http://www.mono-project.com/Release_Notes_Mono_3.0) Mono 3.0.12 was the oldest > version to support osx 10.9. Is that possibly the issue? That is a very interesting find. Can you install a newer version of mono and tell us the results? rmx3000: do you also have mono 2.x in your mac?
I don't have any independent version of mono installed on my mac, only the binary that is packaged along with the Banshee app bundle. I'll try to install a recent version of the 2.10.XX and 3.XX of mono and try it out. Should I just copy the mono and gcms binaries into the app bundle, or is there a way to directly execute a banshee exe with a different version of mono? I'm used to mono on linux and not as familiar with the functions on OSX.
*** Bug 711139 has been marked as a duplicate of this bug. ***
*** Bug 711160 has been marked as a duplicate of this bug. ***
From bug 711160: [Info 13:57:12.619] Running Banshee 2.6.1: [git-checkout (darwin11.4.0, x86_64) @ 2012-08-23 10:07:18 CEST] Exception has been thrown by the target of an invocation. System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.DllNotFoundException: glibsharpglue-2 at (wrapper managed-to-native) GLib.Thread:glibsharp_g_thread_supported () at GLib.Thread.get_Supported () [0x00000] in <filename unknown>:0 at Banshee.Gui.GtkBaseClient.InitializeGtk () [0x00000] in <filename unknown>:0 at Banshee.Gui.GtkBaseClient.Initialize (Boolean registerCommonServices) [0x00000] in <filename unknown>:0
The banshee bundle brings it's own version of mono, so installing and upgrading the system version will not work. I will try to get roll a new release based on the 2.6.1 branch that includes a newer mono in the next days.
I'm getting the same "System.DllNotFoundException: glibsharpglue-2" exception. Everything was great until I upgraded to Mavericks.
Thanks Timo - I was having some issues trying to recompile the bundle from source based on the development build instructions at http://banshee.fm/download/development/#osx . I can't remember the specifics right now - I know I had to manually download a few tarballs that failed, and then had a compile error. Will be curious to try out new builds!
(In reply to comment #10) > The banshee bundle brings it's own version of mono, so installing and > upgrading the system version will not work. > > I will try to get roll a new release based on the 2.6.1 branch that includes a > newer mono in the next days. Guys, let's keep the discussion off-twitter :) Timo, you said you got a problem with GTK#, can you share it? BTW, I can also share a commit from vargaz that may help on this bug: https://github.com/mono/mono/commit/d6673ca8ec854f291eb32c048446b3868b92de7a David, you also said you did some progress on this? with Clang?
My problem is right now that I bumped Mono to 3.2.3, Mono.Cairo is built against .NET 4.0 profile. Although Gtk# (2-12 branch) then builds, other apps like mono-addins and banshee itself complain that Mono.Cairo is against 4.0 profile, but Gtk# against .NET 2.0 profile.
I have Banshee master building on Mavericks against gtk#3, and GStreamer 1.0 (native, get# still appears to be using 0.10) using Clang 5.0.0. I use Clang since it is the system compiler and I prefer it over having to install GCC. Also it's warnings are infinitely more helpful to me in tracking down problems. However due to some exceedingly annoying problems getting certain packages to compile for 32 bits on my 64 bit machine the build is pure 64 bit. My feelings on the matter are that building 32bit on my machine is so much pain that simply moving with the times is the better choice. It is what the system is optimized for anyways and if our foundation code is not ready for it we'd better start filing some bugs with the relevant upstreams instead. Also, did I mention the pain and loss of sanity? Minor details of note: Mono crashes when I do ./darwin.py -z to package the bundle. This needs to be investigated a bit more but it is nicely reproducible and the trace looked helpful. It will though launch when run in the build sandbox, looking ugly as sin since the Mac integration is currently commented out, having a few missing bits and bobs.. oh and no BCE. I doubt bce will be gtk#3 and friends ready presently so I just disabled it to focus on getting Banshee running. Finally it will sit there using 115% CPU doing nothing and I have not done testing beyond launching it as I ran out of time yesterday. The exceedingly ugly bockbuild used can be found here: https://github.com/DavidNielsen/bockbuild I did include a number of general package updates, mostly since newer releases have proven to be easier to compile with Clang and more likely to be maintained stable packages. In some cases we were simply also significantly behind or not using the recommended upstream stable release. I did sneak in a few patches from MacPorts to compile with Clang in a few places, mostly in places where upstream have proven hostile to changes required for the more strict Clang compiler. The only packages untouched I need to bump are dbus-sharp(-glib), version 0.8.0 of which currently fail to compile and will need investigation, and bumping MonoMac as that is going to involve some surgery to the package. I did a quick back port of the patch (and the follow up for sgen) and applied it to Mono 3.2.3. i suspect I might need a few more such patches, upstream has not helpfully put anything in the 3.2.4 branch so I will dig through the log to see what might be relevant. I have some more time to dedicate to this work today so I will clean up a branch for Timo with some of the changes. Overall it seems that Mono might need a few more patches and otherwise we are down to "merely" fixing Banshee problems, GTK(#)3 on non-Linux and so on.. also it seems certain Apple GStreamer plugins in gst-plugins-bad are not yet ported to the 1.0 API so there might be some.. fun in there eventually. I have no plans to work on making 2.6.x build presently.
Timo: (In reply to comment #14) > My problem is right now that I bumped Mono to 3.2.3, Mono.Cairo is built > against .NET 4.0 profile. Although Gtk# (2-12 branch) then builds, other apps > like mono-addins and banshee itself complain that Mono.Cairo is against 4.0 > profile, but Gtk# against .NET 2.0 profile. Oh I see. Well, Gtk# is also compiled by bockbuild, no? If yes, then cannot you change it to compile with dmcs instead of gmcs? David: (In reply to comment #15) > I have no plans to work on making 2.6.x build presently. Then I recommend you to wait a little bit, because the more you wait the easier it will be to compile Banshee 2.9.x on Mac OS. Some examples: > I have Banshee master building on Mavericks against gtk#3, and GStreamer 1.0 > (native, get# still appears to be using 0.10) using Clang 5.0.0. Yes, Gst# backend still uses 0.10 because the port to use Gst# 1.0 is not committed yet (but ready and fully working in my fork: https://github.com/knocte/banshee , we're just waiting for moving Gst# to freedesktop.org, and do a 0.99.0 release). > However due to some exceedingly annoying problems getting certain packages to > compile for 32 bits on my 64 bit machine the build is pure 64 bit. > My feelings on the matter are that building 32bit on my machine is so much pain > that simply moving with the times is the better choice. It is what the system > is optimized for anyways and if our foundation code is not ready for it we'd > better start filing some bugs with the relevant upstreams instead. Also, did I > mention the pain and loss of sanity? If you didn't use the unmanaged Gst backend, there would be no need to compile C code, right? (Because I guess libossifer doesn't work on Mac yet?) > It will though launch when run in the build sandbox, looking ugly as sin since > the Mac integration is currently commented out, having a few missing bits and > bobs.. oh and no BCE. I doubt bce will be gtk#3 and friends ready presently so > I just disabled it to focus on getting Banshee running. I'll work on that soon, at least we'll have a "gtk2" branch, and in master branch every extension that has not been ported will be disabled by default. > The only packages untouched I need to bump are dbus-sharp(-glib), version 0.8.0 > of which currently fail to compile and will need investigation, and bumping > MonoMac as that is going to involve some surgery to the package. I've heard from Olivier that dbus-sharp 0.8 doesn't work with Banshee yet, so instead of having different versions for different platforms, let's wait until Banshee raises the dbus-sharp dep to 0.8 (my aim is to update the patch of bug 630110 and commit it as a good excuse to do this, if you can help on that?). > I did a quick back port of the patch (and the follow up for sgen) and applied > it to Mono 3.2.3. i suspect I might need a few more such patches, upstream has > not helpfully put anything in the 3.2.4 branch so I will dig through the log to > see what might be relevant. Sadly there's no mono release yet that includes all important bits to us, which I believe are 2: a) 2 commits which are the bugfix to https://bugzilla.xamarin.com/show_bug.cgi?id=15890 b) the bugfix to https://bugzilla.xamarin.com/show_bug.cgi?id=14834 So, either we cherry-pick 3 commits, or we use master? Thanks!
To keep things appart, I think we should focus on the stable-2.6 OS X release here, and discuss upcoming Banshee 2.9/3.x release in another bug report. I think we are close to solving the Mavericks issue by bumping mono to >=3.0.12, without touching much else in the stable bockbuild for OS X @Andrés I will try to compile Gtk# with dmcs and report back if that fixes it.
(In reply to comment #17) > To keep things appart, I think we should focus on the stable-2.6 OS X release > here, and discuss upcoming Banshee 2.9/3.x release in another bug report. Agreed! > I think we are close to solving the Mavericks issue by bumping mono to > >=3.0.12, without touching much else in the stable bockbuild for OS X I hope the bug that affected F# on Mavericks doesn't affect us too, then. (Because the culprit is nothing very specific to F#, just some memory pagination spec that the OS reports differently than previous versions.) > @Andrés I will try to compile Gtk# with dmcs and report back if that fixes it. Cool, thanks for looking into this!
(In reply to comment #16) > Timo: > > (In reply to comment #14) > > My problem is right now that I bumped Mono to 3.2.3, Mono.Cairo is built > > against .NET 4.0 profile. Although Gtk# (2-12 branch) then builds, other apps > > like mono-addins and banshee itself complain that Mono.Cairo is against 4.0 > > profile, but Gtk# against .NET 2.0 profile. > > Oh I see. Well, Gtk# is also compiled by bockbuild, no? If yes, then cannot you > change it to compile with dmcs instead of gmcs? he could likely do so, I think looking at what Debian does to ensure that the compiler name is not hardcoded anywhere would be a good start (they tend to have patches if needed). Then just export it as part of the bockbuild profile. > > David: > > (In reply to comment #15) > > I have no plans to work on making 2.6.x build presently. > > Then I recommend you to wait a little bit, because the more you wait the easier > it will be to compile Banshee 2.9.x on Mac OS. Some examples: > > > I have Banshee master building on Mavericks against gtk#3, and GStreamer 1.0 > > (native, get# still appears to be using 0.10) using Clang 5.0.0. > > Yes, Gst# backend still uses 0.10 because the port to use Gst# 1.0 is not > committed yet (but ready and fully working in my fork: > https://github.com/knocte/banshee , we're just waiting for moving Gst# to > freedesktop.org, and do a 0.99.0 release). We are moving that to fdo, cool. I am just pulling in the latest mono-soc-2013 head for the time being. I am glad there is a plan to keep it part of the actual GStreamer repo. > > However due to some exceedingly annoying problems getting certain packages to > > compile for 32 bits on my 64 bit machine the build is pure 64 bit. > > My feelings on the matter are that building 32bit on my machine is so much pain > > that simply moving with the times is the better choice. It is what the system > > is optimized for anyways and if our foundation code is not ready for it we'd > > better start filing some bugs with the relevant upstreams instead. Also, did I > > mention the pain and loss of sanity? > > If you didn't use the unmanaged Gst backend, there would be no need to compile > C code, right? (Because I guess libossifer doesn't work on Mac yet?) We still need to build all the base packages since there is no official GTK+3 release for OS X. The same is true for GStreamer 1.x I believe. I don't think we have a way to avoid having to compile and ship at least a few bits and bobs for quite a while. We could perhaps do a set of base system packages like what Xamarin does for Mono and GTK#2 that all our projects could depend upon. I would have to figure out how to do that and to ensure that it would be updatable automatically but it is certainly a way forward that should be considered. Doing it in bockbuild should also allow us to reuse the same work for similar Windows work and binary Linux builds. To get GTK3 on OS X working really well though I think we need to coordinate with external people like John Ralls and the Lanedo guys as they have way more expertise in terms of the OS X platform. I can start poking some people if there is an interest in doing this and it is felt to be useful beyond the Banshee build. > > It will though launch when run in the build sandbox, looking ugly as sin since > > the Mac integration is currently commented out, having a few missing bits and > > bobs.. oh and no BCE. I doubt bce will be gtk#3 and friends ready presently so > > I just disabled it to focus on getting Banshee running. > > I'll work on that soon, at least we'll have a "gtk2" branch, and in master > branch every extension that has not been ported will be disabled by default. Excellent news, I didn't suspect this would be a problem for long so I just ignored it in favor of getting a look at just Banshee. Also actually getting GTK#3 and friends to build on OS X in my experience takes a considerable amount of work so getting a head start seemed like a good idea. > > The only packages untouched I need to bump are dbus-sharp(-glib), version 0.8.0 > > of which currently fail to compile and will need investigation, and bumping > > MonoMac as that is going to involve some surgery to the package. > > I've heard from Olivier that dbus-sharp 0.8 doesn't work with Banshee yet, so > instead of having different versions for different platforms, let's wait until > Banshee raises the dbus-sharp dep to 0.8 (my aim is to update the patch of bug > 630110 and commit it as a good excuse to do this, if you can help on that?). I can give it a shot, at least I will bother Jérémie about the compile error when I am certain it is not my own doing. > > I did a quick back port of the patch (and the follow up for sgen) and applied > > it to Mono 3.2.3. i suspect I might need a few more such patches, upstream has > > not helpfully put anything in the 3.2.4 branch so I will dig through the log to > > see what might be relevant. > > Sadly there's no mono release yet that includes all important bits to us, which > I believe are 2: > a) 2 commits which are the bugfix to > https://bugzilla.xamarin.com/show_bug.cgi?id=15890 Those are already in my bockbuild. > b) the bugfix to https://bugzilla.xamarin.com/show_bug.cgi?id=14834 I can back port that real quick, and take it for a spin. The work should be entirely reusable for Banshee 2.6.x so no duplication of effort. > So, either we cherry-pick 3 commits, or we use master? I say we cherry pick those, but if it extends beyond 3 commits or so I would be in favor of shaking down Xamarin to start committing to their 3.2.4 branch and do a release soon. Having to keep more than a few patches in the build in my experience is the path to Ragnarok and certain (painful) doom. Using Mono master in a Banshee release bundle makes me a tad nervous and it is a support nightmare waiting to happen. > Thanks!
*** Bug 715066 has been marked as a duplicate of this bug. ***
I have the exact same issue : Banshee 2.6.1 is not launching after a fresh installation on Mac OS X 10.9. I'm not sure what information I could provide to help you.
This issue is still happening on my computer - I believe I have banshee 2.6.1. After trying to launch Banshee via the finder several times and failing (it showed up in the dock for a few seconds and then disappeared, no windows opened), I tried running /Applications/Banshee/Contents/MacOS/Banshee (which appears to be a shell script) in a terminal, and it tripped while launching Mono. It looks like it couldn't open Mono because, instead of trying to execute /Applications/Banshee/Contents/Resources/bin/mono, it tried to execute /Users/[MY_USERNAME]Applications/Banshee/Contents/Resources/bin/mono, which, due to the incorrectly inserted (and also unnecessary) home directory, didn't exist. Here's the error message that the terminal gave: [COMPUTER_NAME]:~ [MY_USERNAME]$ /Applications/Banshee.app/Contents/MacOS/Banshee /Applications/Banshee.app/Contents/MacOS/Banshee: line 141: /Users/[MY_USERNAME]Applications/Banshee.app/Contents/Resources/bin/mono: No such file or directory /Applications/Banshee.app/Contents/MacOS/Banshee: line 141: exec: /Users/[MY_USERNAME]Applications/Banshee.app/Contents/Resources/bin/mono: cannot execute: No such file or directory
Never mind, it turns out there was more to the error than I thought. It seems as though the error depends on what directory you are in when you launch Banshee. The error I got before came while I was launching it in my home directory. I tried launching it from while in the / directory: [COMPUTERNAME]:/ [USERNAME]$ /Applications/Banshee.app/Contents/MacOS/Banshee Application bundle has moved. Adjusting bundle... [Info 20:32:06.941] Running Banshee 2.6.1: [git-checkout (darwin11.4.0, x86_64) @ 2013-04-19 10:31:24 CEST] Exception has been thrown by the target of an invocation. System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.DllNotFoundException: glibsharpglue-2 at (wrapper managed-to-native) GLib.Thread:glibsharp_g_thread_supported () at GLib.Thread.get_Supported () [0x00000] in <filename unknown>:0 at Banshee.Gui.GtkBaseClient.InitializeGtk () [0x00000] in <filename unknown>:0 at Banshee.Gui.GtkBaseClient.Initialize (Boolean registerCommonServices) [0x00000] in <filename unknown>:0 at Banshee.Gui.GtkBaseClient..ctor (Boolean initializeDefault, System.String defaultIconName) [0x00000] in <filename unknown>:0 at Banshee.Gui.GtkBaseClient..ctor () [0x00000] in <filename unknown>:0 at Nereid.Client..ctor () [0x00000] in <filename unknown>:0 at (wrapper managed-to-native) System.Reflection.MonoCMethod:InternalInvoke (System.Reflection.MonoCMethod,object,object[],System.Exception&) at System.Reflection.MonoCMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0 --- End of inner exception stack trace --- at System.Reflection.MonoCMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0 at System.Reflection.MonoCMethod.Invoke (BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0 at System.Reflection.ConstructorInfo.Invoke (System.Object[] parameters) [0x00000] in <filename unknown>:0 at System.Activator.CreateInstance (System.Type type, Boolean nonPublic) [0x00000] in <filename unknown>:0 at System.Activator.CreateInstance (System.Type type) [0x00000] in <filename unknown>:0 at Banshee.Gui.GtkBaseClient.Startup () [0x00000] in <filename unknown>:0 at Hyena.Gui.CleanRoomStartup.Startup (Hyena.Gui.StartupInvocationHandler startup) [0x00000] in <filename unknown>:0 Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for Gtk.Application ---> System.DllNotFoundException: glibsharpglue-2 at (wrapper managed-to-native) GLib.Thread:glibsharp_g_thread_supported () at GLib.Thread.get_Supported () [0x00000] in <filename unknown>:0 at Gtk.Application..cctor () [0x00000] in <filename unknown>:0 --- End of inner exception stack trace --- at Hyena.Gui.CleanRoomStartup.Startup (Hyena.Gui.StartupInvocationHandler startup) [0x00000] in <filename unknown>:0 at Banshee.Gui.GtkBaseClient.Startup[Client] () [0x00000] in <filename unknown>:0 at Banshee.Gui.GtkBaseClient.Startup[Client] (System.String[] args) [0x00000] in <filename unknown>:0 at Nereid.Client.Main (System.String[] args) [0x00000] in <filename unknown>:0 [ERROR] FATAL UNHANDLED EXCEPTION: System.TypeInitializationException: An exception was thrown by the type initializer for Gtk.Application ---> System.DllNotFoundException: glibsharpglue-2 at (wrapper managed-to-native) GLib.Thread:glibsharp_g_thread_supported () at GLib.Thread.get_Supported () [0x00000] in <filename unknown>:0 at Gtk.Application..cctor () [0x00000] in <filename unknown>:0 --- End of inner exception stack trace --- at Hyena.Gui.CleanRoomStartup.Startup (Hyena.Gui.StartupInvocationHandler startup) [0x00000] in <filename unknown>:0 at Banshee.Gui.GtkBaseClient.Startup[Client] () [0x00000] in <filename unknown>:0 at Banshee.Gui.GtkBaseClient.Startup[Client] (System.String[] args) [0x00000] in <filename unknown>:0 at Nereid.Client.Main (System.String[] args) [0x00000] in <filename unknown>:0 Launching it directly from the /Applications/Banshee/Contents/MacOS directory gave this: [COMPUTERNAME]:/ [USERNAME]$ cd /Applications/Banshee.app/Contents/MacOS/ [COMPUTERNAME]:MacOS [USERNAME]$ Banshee -bash: Banshee: command not found [COMPUTERNAME]:MacOS [USERNAME]$ sh Banshee Application bundle has moved. Adjusting bundle... find: /Applications/Banshee.app/Contents/Contents/Resources/etc: No such file or directory Banshee: line 141: /Applications/Banshee.app/Contents/Contents/Resources/bin/mono: No such file or directory Banshee: line 141: exec: /Applications/Banshee.app/Contents/Contents/Resources/bin/mono: cannot execute: No such file or directory
After launching the app in the terminal from /Applications/Banshee.app/Contents with command "sh MacOS/Banshee" I get the following info and error messages: [Info 11:22:51.525] Running Banshee 2.6.1: [git-checkout (darwin11.4.0, x86_64) @ 2013-04-19 10:31:24 CEST] Exception has been thrown by the target of an invocation. System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.DllNotFoundException: glibsharpglue-2 at (wrapper managed-to-native) GLib.Thread:glibsharp_g_thread_supported () at GLib.Thread.get_Supported () [0x00000] in <filename unknown>:0 at Banshee.Gui.GtkBaseClient.InitializeGtk () [0x00000] in <filename unknown>:0 at Banshee.Gui.GtkBaseClient.Initialize (Boolean registerCommonServices) [0x00000] in <filename unknown>:0 at Banshee.Gui.GtkBaseClient..ctor (Boolean initializeDefault, System.String defaultIconName) [0x00000] in <filename unknown>:0 at Banshee.Gui.GtkBaseClient..ctor () [0x00000] in <filename unknown>:0 at Nereid.Client..ctor () [0x00000] in <filename unknown>:0 at (wrapper managed-to-native) System.Reflection.MonoCMethod:InternalInvoke (System.Reflection.MonoCMethod,object,object[],System.Exception&) at System.Reflection.MonoCMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0 --- End of inner exception stack trace --- at System.Reflection.MonoCMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0 at System.Reflection.MonoCMethod.Invoke (BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0 at System.Reflection.ConstructorInfo.Invoke (System.Object[] parameters) [0x00000] in <filename unknown>:0 at System.Activator.CreateInstance (System.Type type, Boolean nonPublic) [0x00000] in <filename unknown>:0 at System.Activator.CreateInstance (System.Type type) [0x00000] in <filename unknown>:0 at Banshee.Gui.GtkBaseClient.Startup () [0x00000] in <filename unknown>:0 at Hyena.Gui.CleanRoomStartup.Startup (Hyena.Gui.StartupInvocationHandler startup) [0x00000] in <filename unknown>:0 Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for Gtk.Application ---> System.DllNotFoundException: glibsharpglue-2 at (wrapper managed-to-native) GLib.Thread:glibsharp_g_thread_supported () at GLib.Thread.get_Supported () [0x00000] in <filename unknown>:0 at Gtk.Application..cctor () [0x00000] in <filename unknown>:0 --- End of inner exception stack trace --- at Hyena.Gui.CleanRoomStartup.Startup (Hyena.Gui.StartupInvocationHandler startup) [0x00000] in <filename unknown>:0 at Banshee.Gui.GtkBaseClient.Startup[Client] () [0x00000] in <filename unknown>:0 at Banshee.Gui.GtkBaseClient.Startup[Client] (System.String[] args) [0x00000] in <filename unknown>:0 at Nereid.Client.Main (System.String[] args) [0x00000] in <filename unknown>:0 [ERROR] FATAL UNHANDLED EXCEPTION: System.TypeInitializationException: An exception was thrown by the type initializer for Gtk.Application ---> System.DllNotFoundException: glibsharpglue-2 at (wrapper managed-to-native) GLib.Thread:glibsharp_g_thread_supported () at GLib.Thread.get_Supported () [0x00000] in <filename unknown>:0 at Gtk.Application..cctor () [0x00000] in <filename unknown>:0 --- End of inner exception stack trace --- at Hyena.Gui.CleanRoomStartup.Startup (Hyena.Gui.StartupInvocationHandler startup) [0x00000] in <filename unknown>:0 at Banshee.Gui.GtkBaseClient.Startup[Client] () [0x00000] in <filename unknown>:0 at Banshee.Gui.GtkBaseClient.Startup[Client] (System.String[] args) [0x00000] in <filename unknown>:0 at Nereid.Client.Main (System.String[] args) [0x00000] in <filename unknown>:0 Hope it will be of Use... ;)
Banshee is not under active development anymore and had its last code changes more than three years ago. Its codebase has been archived. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is being shut down) if anyone takes the responsibility for active development again. See https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/264 for more info.