Bug 116295

I don't see any reason to have a -devel package for libgdiplus.

Also no need to package the .a and .la files.

There's already a libgdiplus-devel package, no need to do anything IMO.

I don't understand the problem.

The problem is that there is a libgdiplus-devel package containing the file that
should be in libgdiplus.  The -devel  package needs to be sent to the bit bucket.  

Otherwise, every app that requries libgdiplus will need to depend on the -devel
package.

Submitted in autobuild 

On Mon, 2005-09-19 at 00:51 +0200, ro@suse.de wrote:
Script 'mail_hack' called by root
> Hi mono-maintainers@suse.de,
> /work/src/done/STABLE/libgdiplus was not checked in for the following reasons:
> 
> why remove a devel package ? 

There's no need for a -devel package for libgdiplus.  No one is going to link
against libgdiplus.  Ben, would you like to comment?

yes, that's correct. libgdiplus is private to mono.

added this bugzilla number to changelog.   
The -devel package was never a real devel package anyways...   
Checked in. 

I really do not understand the whole issue at all. 
 
a .so symlink is a clear case for a -devel subpackage. 
same goes for static libraries (.a), pkgconfig files (.pc) and 
libtool archives/helper files (.la) 
 
requiring any of these at runtime is just plain broken and any code 
requiring these is wrong. 
Installing static libs will just increase size of a binary installation, 
and the issue of the .so files has been discussed over and over already. 
 

We don't need the static libs, .la, or .pc file at all. Really, we shouldn't
version libgdiplus at all, and it should just install a .so. It is a
mono-internal library -- nobody should ever link against it.

Me including the .pc and .la files was my mistake.  That shouldn't have been done.

The problem is that mono apps in general depend on the .so file.  Everyone who
writes mono apps do it this way.

Options:

1. -Include the .so in the runtime
2. -Modify the dllimports for all apps to use the .so.x.x name
3. -Modify/Add .dll.config for all dlls to provide a mapping to from .so to .so.x.x
4. -Modify the mono runtime to look for .so.0 as well as .so when searching for
a dll

In my opinion, #1 the easiest option at this point.  Obviously, that option
doesn't make everyone happy :)

Option 2 requires patching to all mono apps and/or retrain the mono world of how
to do dllimports.  This requires apps to bind to a specific .so file version.

Option 3 requires patching to all rpms containing .dll files and possibly a
smaller amount of training to the mono world.

Option 4 doesn't always solve the problem because the file may not be versioned
.so.0, it may be versioned something else, and at that point, how is the runtime
going to know what to try?

Option #1 is the quickest way to have working mono apps.  I'm not sure what the
best long term solution is...

We should include the .so in the libgdiplus package.

As you point out, we should not have a libgdiplus-devel, libgdiplus is an
internal library to Mono, and its API is not exposed to the public.

We should not include any *.a files either.

option #4 is basically correct but missing the important point: 
do not look for .so.0 but look for the only thing that counts: the SONAME 
that one has to be determined at link time and used at runtime, 
like any other application does. 
 

Option #4 is not going to be implemented in Mono.  The user specified file.so,
not file.so.RUNTIMEGUESS

There is no "linktime" with P/Invoke, this stuff is never linked before its
called it.  

P/Invoke is merely a mechanism to do dlopen/dlsym and glue things together.

Marking this bug as fixed.