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

[Dag Wieers]

On Wed, 20 Aug 2003, Paolo Molaro wrote:

> On 08/20/03 Dag Wieers wrote:
> 
> > 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.

Ok, but it causes problems for deploying because only the developer who 
wrote the P/Invoke calls knows the ABI version. And we have no real way to 
find out if it fits my current system.

The perfect example is that I wasn't aware that gtkhtml3.so (I don't even 
know what version) was used by gtk-sharp because building it and packaging 
it wasn't complaining about this.

Only after someone was using things from one of the dll's he got these 
problems. And I only know gtkhtml3 is missing, even packaging gtkhtml3 
will not guarantee I'm using the right one.


> > 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).

Sure I can override it, but I will never be sure if I'm doing the correct 
thing because only the developer knows what version is supposed to work.

And a. isn't really considered a bug because there's no policy for 
choosing the library we are working against. Hell, there isn't even a 
list, just a bunch of dllimported soname's.

Personally I think using the soname is the wrong way of doing it (if you 
state that you can override it). I'd very much prefer at least the 
libmajor be added by the developer. And you can still remove that libmajor 
even automatically, if you want. The other way around is almost impossible 
because this information lies in the hands of the developers.

Would that be ok with you ?


> > 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.

I understand, and I'm not even a developer. But it would be nice if this 
was on a todo-list somewhere so that at least I know where we stand and 
that it is a temporary situation.

But just a list of library version that are known to work would already be 
useful.


> > 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.

Ok, this makes it clear that only the gtk-sharp libraries are a 
difficult moving target here. Especially with Gnome 2.4 arriving.


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

It would be nice if it wasn't just documented but listed somewhere so it 
can be processed. Maybe I need to write a script that just goes over the 
DllImports and ask the developers which versions they think it should work 
against, a simple list would suffice. Better than nothing ;)


Thanks for your time,

--   dag wieers,  dag@wieers.com,  http://dag.wieers.com/   --
[Any errors in spelling, tact or fact are transmission errors]