[Mono-list] Re: [Gtk-sharp-list] DllImport on *.so files

[Paolo Molaro]

On 08/20/03 Dag Wieers wrote:
> > The mapping is used when the P/Invoke function is called.
> 
> So it is used at runtime. Doesn't that slow things down ?

No, because the lookup is done only once.

> > There is no way for any CLR implementation to fix the billions of ways
> > a programmer can screw up:-) When you use P/Invoke you're implicitly
> > using one binary interface of a library, so you must make sure that
> > specific library is loaded (hence the use of the versioned soname in the
> > dll mapping instead of the simple .so map).
> 
> Well, it surprised me that what is hardcoded is the .so file and not a 
> versioned one. The developers now best what version(s) work. I would have 
> expected a more intelligent way for developers to indicate what versioned 
> soname are guaranteed to work (or at least should work).

There is only no soname that is guaranteed to work because there are
gazillion ways for the developer to screw up the code and for the user
to screw up his system:-)
As a general rule only the developer who wrote the P/Invoke calls can (should!)
know the ABI version he wrote the code for.

> Well, there's no way for me (an end-user or packager) to know this unless 
> I test applications that use these libraries in any possible way. I only 
> know that 'libgtkhtml3' is hardcoded what may mean that
> 
>   a. The developer has this by sheer luck installed and therefor used it
>   b. The developer thinks it's better to use this one for what he needs it
>   c. The developer _knows_ gtkhtml2 is not sufficient
> 
> I'd assume c. is the real reason, but there's no way to find out (because 
> the others are plausible too ;-)))

a would be a bug. Re b: you can change the config file on your system
and override the developer decision (or lack thereof). I went with the config 
file entry design mostly because of this. c is what should happen (the
developer should possibly document which ABI versions of a library work
with his binding).

> > > Some way of verifying if function-calls map with existing libraries would 
> > > be prefered.
> > 
> > With C libraries you can check just the function name: not very useful.
> 
> That's why I would have expected something more thorough (by relying on 
> header-files) to find out whether the API is supported. So that you at 
> least know when it will never work.

Feel free to write the tool if you have several months of spare time to
dedicate to it, I guess it can be useful to some. It's not an easy task
as it seems you may think.

> But don't mind my criticism, I'm just a concerned packager and a novice C# 
> developer that is trying to understand what the best way to make sure I'm 
> not shipping packages that may break for other developers.

There are three sets of libraries P/Invoke is used against:

*) system libraries those version basically never changes (but the
version may well be system-specific), like libc. Those should be handled
by the default mono install or by whoever packages mono for a system.
*) helper C libraries maintained together with their managed assembly:
these are under the direct control of the assembly developer, so no
issue here.
*) other libraries like libgtk+ that are maintained sanely (they change
the lib version when the ABI changes): it should be documented which ABI
version the P/Invoke calls where intended for.

I ignored libraries which are not maintained correctly: in that case all
bets are off.

lupus

-- 
-----------------------------------------------------------------
lupus@debian.org                                     debian/rules
lupus@ximian.com                             Monkeys do it better