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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] nombre de Mikkel Kruse Johnsen Enviado el: Martes, 19 de Agosto de 2003 01:36 a.m. Para: Dag Wieers CC: Paolo Molaro; [EMAIL PROTECTED]; [EMAIL PROTECTED] Asunto: Re: [Gtk-sharp-list] DllImport on *.so files Hi All Some way of verifying if function-calls map with existing libraries would 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. 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. If the library source code has changed at all since the last update, then increment revision (`c:r:a' becomes `c:r+1:a'). If any interfaces have been added, removed, or changed since the last update, increment current, and set revision to 0. If any interfaces have been added since the last public release, then increment age. If any interfaces have been removed since the last public release, then set age to 0. 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 _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
