[Mono-list] RE: [Gtk-sharp-list] DllImport on *.so files (cross post)

[Gustavo Ramos]

Hello, all...

Sorry for the cross and long post, but i think this is an issue of =
common interest. Please see the complete thread: "[Gtk-sharp-list] =
DllImport on *.so files".

Personally I do some practices that has given to me good results. As a =
golden rule to avoid version wreckages, I must always be sure that the =
libraries I link against, have the same binary compatibility among =
versions. I mean, there must not be changes in the signatures of the =
functions. From the dependent-lib-author point of view, there could be =
new functions or changes in the implementation that doesn't affect the =
signatures, and ensuring that the previous headers remain compatible, =
the lib author are keeping you --as a function user-- safe. If a =
parameter type has changed, the compatibility is broken. If a function =
name has changed, our code will not function. Any change in the type of =
the return values will broke things.

A well written configure.in surely will help, but we can't anticipate to =
all the possible changes, or it will easily be broken. But there is a =
more complex scenario behind: Our program requires the feature X from =
the lib M. The lib M should be configured somewhat weird in order to =
support the feature X (./configure --with-a --without-b =
--with-some-sort-of-c ... etc.). That configuration can't be guaranteed =
to be working as we'd wonder in the final user machine.

We simply can't control the changes on these libraries and much less the =
user configurations, either the distro default configs. Thus, to ensure =
that our program will be up and running, we --as intermediate function =
consumers-- should link statically the third-party code that is known to =
be changing quickly, and link to shared libraries only when those =
libraries have reached a good mature state.

I think all of us know the obscure part of distributing our program that =
way: loss of efficiency, loss of a number of ram-bytes, higher bandwidth =
required, etc., etc. But our software will have a wider usage, because =
the easyness of installation.

For the mono framework, the solution shouldn't be too hard, and this =
should be nearby Paolo's post. Ok, we won't need the development =
packages if we change the config of mono, to map the versioned lib. But =
that isn't enough, because the need of hard-coding the version number.

That issue should be resolved with an autogenerated glue library, =
statically or dynamically linked, as required (I mean, the glue library =
could contain the complete library code, or just the wrapper to the so =
lib). That piece of native code should check if the required features =
are available, and which version  of the so library have the best match. =
This would make the code [partially] unportable. Partially because the =
tool that would generate the glue library should be available in the =
supported platforms. It would be fantastic if that tool would become =
part of the compiler. Or if that glue could be generated completely in =
managed code.... :)

Or am I completely lost?

Best regards,

Eureko

-----Mensaje original-----
De: gtk-sharp-list-admin@lists.ximian.com =
[mailto:gtk-sharp-list-admin@lists.ximian.com]En nombre de Mikkel Kruse =
Johnsen
Enviado el: Martes, 19 de Agosto de 2003 01:36 a.m.
Para: Dag Wieers
CC: Paolo Molaro; mono-list@ximian.com; gtk-sharp-list@lists.ximian.com
Asunto: Re: [Gtk-sharp-list] DllImport on *.so files


Hi All


Some way of verifying if function-calls map with existing libraries =
would=20
be prefered.


Here are a set of rules to help you update your library version =
information:


Start with version information of `0:0:0' for each libtool library.=20
Update the version information only immediately before a public release =
of your software. More frequent updates are unnecessary, and only =
guarantee that the current interface number gets larger faster.=20
If the library source code has changed at all since the last update, =
then increment revision (`c:r:a' becomes `c:r+1:a').=20
If any interfaces have been added, removed, or changed since the last =
update, increment current, and set revision to 0.=20
If any interfaces have been added since the last public release, then =
increment age.=20
If any interfaces have been removed since the last public release, then =
set age to 0.=20

There is no way to verifie that functions are in the library, unless you =
run some sort of ABI control on it every time. You have to trust the =
developer to follow the rules above, so that if the current version =
number is changed, then function have changed and the wrapping need to =
be checked.

There is no way in the current situation using only C programs that =
library is cecked for functions, so your gtkhtml3 exemple is also only =
checked with the version number of the libgtkhtml.

But what we really nedd it to have support in RPM and DEP for checking =
assemlies version and even signing for the packages. So you can do like =
this in the SPEC (RPM):

    Signing:        JGJ13234123JGJGJGJGJ12312312

or something, and only a assemplie signed with that key can be used.

/Mikkel=20