Bug 380131 - mono-winforms rpm doesn't create symlink to libgdiplus.so to libgdiplus.dll
mono-winforms rpm doesn't create symlink to libgdiplus.so to libgdiplus.dll
Status: CLOSED DUPLICATE of bug 426519
Product: Fedora
Classification: Fedora
Component: mono (Show other bugs)
8
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Xavier Lamien
Fedora Extras Quality Assurance
: Reopened
: 415041 432449 (view as bug list)
Depends On:
Blocks: F10Target
  Show dependency treegraph
 
Reported: 2007-11-13 10:15 EST by Dan Naughton
Modified: 2008-10-20 08:09 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-20 08:09:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
simple dialog box form (3.00 KB, application/octet-stream)
2007-11-13 10:15 EST, Dan Naughton
no flags Details

  None (edit)
Description Dan Naughton 2007-11-13 10:15:32 EST
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 10:15:32 EST
Created attachment 256951 [details]
simple dialog box form
Comment 2 Paul F. Johnson 2007-11-13 10:27:23 EST
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 04:12:02 EST
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 05:37:42 EST
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 06:59:03 EST
Fixed in rawhide
Comment 6 Angel Marin 2007-11-17 08:10:53 EST
(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 11:08:16 EST
.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 13:31:17 EST
(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 09:02:26 EST
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 09:37:10 EST
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 09:40:05 EST
*** Bug 415041 has been marked as a duplicate of this bug. ***
Comment 12 Dan Winship 2008-10-16 18:22:27 EDT
*** Bug 432449 has been marked as a duplicate of this bug. ***
Comment 13 Dan Winship 2008-10-16 18:24:05 EDT
copying F10Target blockage from 432449
Comment 14 Paul F. Johnson 2008-10-20 08:09:30 EDT

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

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