<html><body>
<p><tt>&gt; Well, the reason companies like Microsoft and Apple can get away without <br>
&gt; these sorts of specs is because the software itself defines the ABI. I <br>
&gt; understand that you wish to allow the ability to fork, substitute <br>
&gt; implementations and so on, but I don't see why this leads to &quot;must <br>
&gt; precisely document the ABI&quot;.</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. &nbsp; The API/ABI must be precisely specified for binary application stability.</tt><br>
<tt><br>
&gt; If you want to fork or reimplement a library while maintaining <br>
&gt; compatibility then the binaries/source of the original library is the <br>
&gt; standard you are working to - as experience from Wine shows, even things <br>
&gt; like what bugs are in the original library can be very important. I <br>
&gt; really doubt the LSB specifies what bugs shine through the interface, right?<br>
&gt; </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 &quot;what bugs shine through the interface&quot;, 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>