Bug 692784 - System.DllNotFoundException: libglib-2.0.dll
Summary: System.DllNotFoundException: libglib-2.0.dll
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gkeyfile-sharp
Version: 14
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Christian Krause
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-04-01 06:56 UTC by Dave Jones
Modified: 2015-01-04 22:31 UTC (History)
6 users (show)

Fixed In Version: gkeyfile-sharp-0.1-5.fc14
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-05-19 04:57:42 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Log from starting banshee and then connecting ipod (10.88 KB, application/octet-stream)
2011-04-25 13:06 UTC, Daniel Sjoholm
no flags Details

Description Dave Jones 2011-04-01 06:56:41 UTC
starting up banshee, I see this ..
Exception in Gtk# callback delegate
  Note: Applications can use GLib.ExceptionManager.UnhandledException to handle the exception.
System.DllNotFoundException: libglib-2.0.dll
  at (wrapper managed-to-native) KeyFile.GKeyFile:g_key_file_free (intptr)
  at KeyFile.GKeyFile+FinalizerInfo.Handler () [0x00000] in <filename unknown>:0 
  at GLib.Timeout+TimeoutProxy.Handler () [0x00000] in <filename unknown>:0 
   at GLib.ExceptionManager.RaiseUnhandledException(System.Exception e, Boolean is_terminal)
   at GLib.Timeout+TimeoutProxy.Handler()
   at Gtk.Application.gtk_main()
   at Gtk.Application.Run()
   at Banshee.Gui.GtkBaseClient.Run()
   at Banshee.Gui.GtkBaseClient.Startup()
   at Hyena.Gui.CleanRoomStartup.Startup(Hyena.Gui.StartupInvocationHandler startup)
   at Banshee.Gui.GtkBaseClient.Startup()
   at Banshee.Gui.GtkBaseClient.Startup(System.String[] args)
   at Nereid.Client.Main(System.String[] args)
   at System.AppDomain.ExecuteAssembly(System.Reflection.Assembly , System.String[] )
   at System.AppDomain.ExecuteAssemblyInternal(System.Reflection.Assembly a, System.String[] args)
   at System.AppDomain.ExecuteAssembly(System.String assemblyFile, System.Security.Policy.Evidence assemblySecurity, System.String[] args)
   at System.AppDomain.ExecuteAssembly(System.String assemblyFile)
   at Booter.Booter.BootClient(System.String clientName)
   at Booter.Booter.Main()


missing dependancy ?


this is with banshee-1.8.1-1.fc14.x86_64

Comment 1 Daniel Sjoholm 2011-04-25 13:06:45 UTC
Created attachment 494670 [details]
Log from starting banshee and then connecting ipod

Getting the same issues, but only when I have my ipod connected and/or connect it.
(Crashes on start if connected, crashes the moment the ipod is recognized and mounted if not connected from start)

Comment 2 javiermon 2011-05-02 11:10:43 UTC
Hi

I can confirm this bug in fedora 15.

rpm -qa banshee
banshee-2.0.0-2.fc15.x86_64

Comment 3 javiermon 2011-05-06 20:28:39 UTC
I've found a workaround for this bug, 
if you add this to /etc/mono/config:

<dllmap dll="libglib-2.0.dll" target="libglib-2.0.so.0" os="!windows,osx"/>

banshee starts and works.

I think it's not the best solution. If I grep through the config files provided by banshee I see:

/usr/lib64/banshee$ grep libglib *
Banshee.Core.dll.config:  <dllmap dll="libglib-2.0-0.dll" target="libglib-2.0.so.0" os="!windows,osx"/>
Banshee.Core.dll.config:  <dllmap dll="libglib-2.0-0.dll" target="libglib-2.0.dylib" os="osx"/>
Banshee.Services.dll.config:  <dllmap dll="libglib-2.0-0.dll" target="libglib-2.0.so.0" os="!windows,osx"/>
Banshee.Services.dll.config:  <dllmap dll="libglib-2.0-0.dll" target="libglib-2.0.dylib" os="osx"/>
Hyena.dll.config:  <dllmap dll="libglib-2.0-0.dll" target="libglib-2.0.so.0" os="!windows,osx"/>
Hyena.dll.config:  <dllmap dll="libglib-2.0-0.dll" target="libglib-2.0.dylib" os="osx"/>
Hyena.Gui.dll.config:  <dllmap dll="libglib-2.0-0.dll" target="libglib-2.0.so.0" os="!windows,osx"/>
Hyena.Gui.dll.config:  <dllmap dll="libglib-2.0-0.dll" target="libglib-2.0.dylib" os="osx"/>

Maybe the .config files are wrong as they search for libglib-2.0-0.dll and not libglib-2.0.dll ?

Comment 4 Christian Krause 2011-05-08 10:05:11 UTC
The issue is caused by gkeyfile-sharp.dll which wrongly references libglib-2.0.dll. New packages which contain the bug fix are on their way.

Comment 5 Fedora Update System 2011-05-08 10:06:48 UTC
gkeyfile-sharp-0.1-6.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/gkeyfile-sharp-0.1-6.fc15

Comment 6 Fedora Update System 2011-05-08 10:09:41 UTC
gkeyfile-sharp-0.1-4.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/gkeyfile-sharp-0.1-4.fc14

Comment 7 Fedora Update System 2011-05-08 18:22:44 UTC
gkeyfile-sharp-0.1-7.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/gkeyfile-sharp-0.1-7.fc15

Comment 8 Fedora Update System 2011-05-08 18:24:58 UTC
gkeyfile-sharp-0.1-5.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/gkeyfile-sharp-0.1-5.fc14

Comment 9 Fedora Update System 2011-05-09 01:51:41 UTC
Package gkeyfile-sharp-0.1-5.fc14:
* should fix your issue,
* was pushed to the Fedora 14 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing gkeyfile-sharp-0.1-5.fc14'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/gkeyfile-sharp-0.1-5.fc14
then log in and leave karma (feedback).

Comment 10 Fedora Update System 2011-05-19 04:57:36 UTC
gkeyfile-sharp-0.1-7.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 11 Fedora Update System 2011-05-19 21:57:54 UTC
gkeyfile-sharp-0.1-5.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.