<html><body>
<p><tt>> Well, the reason companies like Microsoft and Apple can get away without <br>
> these sorts of specs is because the software itself defines the ABI. I <br>
> understand that you wish to allow the ability to fork, substitute <br>
> implementations and so on, but I don't see why this leads to "must <br>
> precisely document the ABI".</tt><br>
<br>
<tt>One OS on one hardware architecture is easier than 100+ GNU/Linux variants on a dozen different architectures which are built on infinite possible permutations of upstream open source packages. The API/ABI must be precisely specified for binary application stability.</tt><br>
<tt><br>
> If you want to fork or reimplement a library while maintaining <br>
> compatibility then the binaries/source of the original library is the <br>
> standard you are working to - as experience from Wine shows, even things <br>
> like what bugs are in the original library can be very important. I <br>
> really doubt the LSB specifies what bugs shine through the interface, right?<br>
> </tt><br>
<br>
<tt>It is not possible to standardize on just a binary library.</tt><br>
<br>
<tt><a href="http://lsbbook.gforge.freestandards.org/si.html#SI-WHAT">http://lsbbook.gforge.freestandards.org/si.html#SI-WHAT</a></tt><br>
<br>
<tt>If you are depending on "what bugs shine through the interface", then you are not writing portable code and your binary will definitely not be compatabile from release to release or distro to distro.</tt><br>
<br>
<tt>George (gk4)</tt><br>
</body></html>