Hide Forgot
Description of problem: applications requiring winforms don't run. Version-Release number of selected component (if applicable): # rpm -q mono-winforms mono-winforms-1.2.5.1-3.fc8 How reproducible: every time Steps to Reproduce: 1. create simple hello world win form, compile 2. run it - mono hello.exe 3. application fails - An exception was thrown by the type initializer for System.Drawing.GDIPlus ---> System.DllNotFoundException: gdiplus.dll Actual results: An exception was thrown by the type initializer for System.Drawing.GDIPlus ---> System.DllNotFoundException: gdiplus.dll Expected results: form on screen Additional info: It looks like the symlink to libgdiplus isn't created in the rpm installer. If you manually create on, the forms works fine. ln -s /usr/lib/libgdiplus.so.0.0.0 /usr/lib/libgdiplus.dll
Created attachment 256951 [details] simple dialog box form
Rather than the exe, can I see the source? Is this also happening with the version in rawhide (1.2.5.2-1)? Should it also not be libgdiplus this is filed against rather than mono as such?
This is a libgdiplus packaging error since 1.2.5-1. %{_libdir}/libgdiplus.so is being packaged in libgdiplus-devel instead of in libgdiplus package. Most of System.Drawing.* and anything relying on it is screwed by this.
I can confirm this. In my install a ln -s /usr/lib/libgdiplus.so.0.0.0 /usr/lib/libgdiplus.so or ln -s /usr/lib/libgdiplus.so.0.0.0 /usr/lib/libgdiplus.dll solved the issue. The priority should be at least medium for this bug. It disables a major part of mono
Fixed in rawhide
(In reply to comment #5) > Fixed in rawhide No, it's not. Adding a dependency to a -devel package to make it work does not fix this, nor make any sense IMHO. What's libgdiplus.so doing in the -devel package anyway if it's required for running apps? libgdiplus is at fault here not mono-winforms. And well, System.Drawing is packaged into mono-core so it's still as broken as before unless for winforms apps.
.so files belong in devel packages. I can't see how libgdiplus is at fault here either. If we start putting .so files in standard packages when they should be in the devel package, we start screwing things up all over the place. Mono is not a simple beast to understand either. Adding the -R to the winforms package may not be the best solution, but it fixes the problem until something making more sense is developed.
(In reply to comment #7) > .so files belong in devel packages. I can't see how libgdiplus is at fault here > either. If we start putting .so files in standard packages when they should be > in the devel package, we start screwing things up all over the place. So making everybody install a -devel package that they don't need nor asked for is better? Once the package is installed it'll never go away from those systems. If you put the .so in the regular package, once the problem is solved in mono runtime, you can just move it to the -devel one and nothing bad happens (it was packaged that way until 1.2.4-1). > Mono is not a simple beast to understand either. Adding the -R to the winforms > package may not be the best solution, but it fixes the problem until something > making more sense is developed. But it doesn't fix it. What depends on libgdiplus.so is System.Drawing which is packaged in mono-core. winforms is just something that happens to use System.Drawing.
Dragging in the -devel package is not right. Why is System.Drawing depending on the .so, not the versioned .so.x. It is not as if mono would drag in devel packages of all the other libraries it depends on, so something must be broken in the way it is using libgdiplus.
From the looks of it (looking at gtk-sharp), what you need is a .dll.config file. Look at /usr/lib/mono/gac/gtk-sharp/2.10.0.0__35e10195dab3c99/gtk-sharp.dll.config
*** Bug 415041 has been marked as a duplicate of this bug. ***
*** Bug 432449 has been marked as a duplicate of this bug. ***
copying F10Target blockage from 432449
*** This bug has been marked as a duplicate of bug 426519 ***