[Gtk-sharp-list] DllImport on *.so files
Wed, 20 Aug 2003 02:42:22 +0200 (CEST)
On Tue, 19 Aug 2003, Paolo Molaro wrote:
> On 08/19/03 Dag Wieers wrote:
> > > <dllmap dll="libgtk-win32-2.0-0.dll" target="libgtk-x11-2.0.so.0" />
> > >
> > > This will load the same library through it's versioned soname, just like
> > > when a normal C program is linked against libgtk+. No need for extra
> > > libraries, you can just fix the config file on your system or test and
> > > submit a patch for the config file installed by default by mono.
> > Nice, and I guess the mapping is used at buildtime ?
> The mapping is used when the P/Invoke function is called.
So it is used at runtime. Doesn't that slow things down ?
> > Still this does not guarantee that the .dll's work with the specific
> > libraries installed, if I'm correct.
> 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).
> > Eg. gtk-sharp requires gtkhtml3 and Red Hat only ships gtkhtml2 (and
> > building gtkhtml3 is a real mess as it requires a newer gtk2 etc etc...)
> If gtk-sharp really requires version 3, you can't use version 2.
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 ;-)))
> > 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.
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.
Thanks for your feedback,
-- dag wieers, firstname.lastname@example.org, http://dag.wieers.com/ --
[Any errors in spelling, tact or fact are transmission errors]