Bug 380131

Summary: mono-winforms rpm doesn't create symlink to libgdiplus.so to libgdiplus.dll
Product: [Fedora] Fedora Reporter: Dan Naughton <dan>
Component: monoAssignee: Xavier Lamien <lxtnow>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 8CC: danw, katzj, paul
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-10-20 12:09:30 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 438944    
Attachments:
Description Flags
simple dialog box form none

Description Dan Naughton 2007-11-13 15:15:32 UTC
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

Comment 1 Dan Naughton 2007-11-13 15:15:32 UTC
Created attachment 256951 [details]
simple dialog box form

Comment 2 Paul F. Johnson 2007-11-13 15:27:23 UTC
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?

Comment 3 Angel Marin 2007-11-15 09:12:02 UTC
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.

Comment 4 Yousif Al Saif 2007-11-17 10:37:42 UTC
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


Comment 5 Paul F. Johnson 2007-11-17 11:59:03 UTC
Fixed in rawhide

Comment 6 Angel Marin 2007-11-17 13:10:53 UTC
(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.

Comment 7 Paul F. Johnson 2007-11-17 16:08:16 UTC
.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.

Comment 8 Angel Marin 2007-11-17 18:31:17 UTC
(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.

Comment 9 Matthias Clasen 2008-01-28 14:02:26 UTC
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.

Comment 10 Matthias Clasen 2008-01-28 14:37:10 UTC
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

Comment 11 Matthias Clasen 2008-02-02 14:40:05 UTC
*** Bug 415041 has been marked as a duplicate of this bug. ***

Comment 12 Dan Winship 2008-10-16 22:22:27 UTC
*** Bug 432449 has been marked as a duplicate of this bug. ***

Comment 13 Dan Winship 2008-10-16 22:24:05 UTC
copying F10Target blockage from 432449

Comment 14 Paul F. Johnson 2008-10-20 12:09:30 UTC

*** This bug has been marked as a duplicate of bug 426519 ***