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 710743 - 2.9 & 2.6 not launching on OS X Mavericks
2.9 & 2.6 not launching on OS X Mavericks
Status: RESOLVED WONTFIX
Product: banshee
Classification: Other
Component: general
2.9.0
Other Mac OS
: Normal critical
: 3.0
Assigned To: Banshee Maintainers
Banshee Maintainers
gnome[unmaintained]
: 711139 711160 715066 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2013-10-23 17:42 UTC by rmx3000
Modified: 2020-03-17 09:52 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description rmx3000 2013-10-23 17:42:52 UTC
The application won't open on OS X 10.9.
Comment 1 areinartz 2013-10-24 18:13:13 UTC
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?
Comment 2 areinartz 2013-10-24 18:58:08 UTC
My apologies - 2.6.1 is the version that is the stable osx release, that was a typo
Comment 3 areinartz 2013-10-25 05:08:11 UTC
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.
Comment 4 areinartz 2013-10-25 05:14:53 UTC
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?
Comment 5 Andrés G. Aragoneses (IRC: knocte) 2013-10-25 08:05:23 UTC
(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?
Comment 6 areinartz 2013-10-25 17:09:37 UTC
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.
Comment 7 Andrés G. Aragoneses (IRC: knocte) 2013-10-30 11:58:20 UTC
*** Bug 711139 has been marked as a duplicate of this bug. ***
Comment 8 Andrés G. Aragoneses (IRC: knocte) 2013-10-30 16:10:38 UTC
*** Bug 711160 has been marked as a duplicate of this bug. ***
Comment 9 Andrés G. Aragoneses (IRC: knocte) 2013-10-30 16:11:51 UTC
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
Comment 10 Timo Dörr 2013-11-01 09:57:35 UTC
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.
Comment 11 Michael Foster 2013-11-01 13:48:00 UTC
I'm getting the same "System.DllNotFoundException: glibsharpglue-2" exception. Everything was great until I upgraded to Mavericks.
Comment 12 areinartz 2013-11-01 15:39:22 UTC
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!
Comment 13 Andrés G. Aragoneses (IRC: knocte) 2013-11-05 19:09:58 UTC
(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?
Comment 14 Timo Dörr 2013-11-05 21:11:08 UTC
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.
Comment 15 David Nielsen 2013-11-06 10:34:13 UTC
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.
Comment 16 Andrés G. Aragoneses (IRC: knocte) 2013-11-06 10:59:16 UTC
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!
Comment 17 Timo Dörr 2013-11-06 11:07:42 UTC
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.
Comment 18 Andrés G. Aragoneses (IRC: knocte) 2013-11-06 11:13:44 UTC
(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!
Comment 19 David Nielsen 2013-11-06 11:30:52 UTC
(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!
Comment 20 Andrés G. Aragoneses (IRC: knocte) 2013-11-23 17:28:17 UTC
*** Bug 715066 has been marked as a duplicate of this bug. ***
Comment 21 Delete this account 2013-12-04 15:43:33 UTC
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.
Comment 22 znkonscratch 2014-07-17 03:03:45 UTC
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
Comment 23 znkonscratch 2014-07-17 03:11:11 UTC
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
Comment 24 thomas.gruet 2014-08-16 09:33:38 UTC
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... ;)
Comment 25 André Klapper 2020-03-17 09:52:46 UTC
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.