<html><body bgcolor="#FFFFFF"><div>Clarification: shipping assembly source would include, in today's structuring, shipping a little C too. Heck, we could ship .o files and some .c, & that would fix the entire binary compatibility problem for us (assembly or .o). Playing a little fast&loose wrt Xlib.h but probably ok.</div><div><br></div><div><br></div><div>My plan to ship C would probably ship strange low level C that doesn't improve things wrt binary compatibility. Unless someone has a scheme in mind for a backend that generates #include sys/types & such?<br><br></div><div><br></div><div>There is a point to ship C, just not likely relevant to binary compatibility.</div><div><br></div><div><br> - Jay (briefly/pocket-sized-computer-aka-phone)</div><div><br>On May 14, 2012, at 1:00 PM, Jay <<a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div><div>The age of the toolchain is not the problem. And gcc has little/nothing to do with it (unless you worry about C++ exceptionhandling/RTTI ABI) Linux/OpenBSD/FreeBSD/NetBSD seemingly don't try to retain binary compatibility. I don't know if security fixes are too blame but I doubt it.</div><div><br></div><div><br></div><div>Shipping assembly source would help -- where the breakage is only the .so name. I want to ship C source.<br><br> - Jay (briefly/pocket-sized-computer-aka-phone)</div><div><br>On May 14, 2012, at 5:24 AM, "Daniel Alejandro Benavides D." <<a href="mailto:dabenavidesd@yahoo.es"><a href="mailto:dabenavidesd@yahoo.es">dabenavidesd@yahoo.es</a></a>> wrote:<br><br></div><div></div><blockquote type="cite"><div><table cellspacing="0" cellpadding="0" border="0"><tbody><tr><td valign="top" style="font: inherit;">Hi all:<br>'forwards compatibility' is not achieved by any of OSes because of Gcc merits as it should be, but backwards also don't say a word as expected, mainly due "security issues", so I don't know if commercial *ix are, at least have the sources should make that easier I guess; I once tried to compile a virtual machine package and I was told that first find my distro's 'minimum common factor' and cross-compile to that system and then recompile everything on it, but I solved hacking the virtual machine sources, so my guess is that you can have 'forwards compatibility' if you can get a sufficient old version of your tool chain and OS to cross-compile from newer.<br>Modula-3 had this nice thing of emitting the "assembly sources" and emit native code for the platform in-situ and relink everything (so sort of eliminate the requisite of having an older compiler,
but just native gcc nice to do). Maybe this would be a nice to have item for next releases, wouldn't be?<br>Thanks in advance<br><br> <br><br>--- El <b>lun, 14/5/12, Jay K <i><<a href="mailto:jay.krell@cornell.edu"><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a></a>></i></b> escribió:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>De: Jay K <<a href="mailto:jay.krell@cornell.edu"><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a></a>><br>Asunto: Re: [M3devel] libXaw.so.6 again<br>Para: "Mika Nystrom" <<a href="mailto:mika@async.caltech.edu"><a href="mailto:mika@async.caltech.edu">mika@async.caltech.edu</a></a>>, <a href="mailto:dragisha@m3w.org"></a><a href="mailto:dragisha@m3w.org"><a href="mailto:dragisha@m3w.org">dragisha@m3w.org</a></a><br>CC: "m3devel" <<a href="mailto:m3devel@elegosoft.com"><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a></a>><br>Fecha: lunes, 14 de mayo, 2012 02:20<br><br><div id="yiv2001619518">
<style><!--
#yiv2001619518 .yiv2001619518hmmessage P
{
margin:0px;padding:0px;}
#yiv2001619518 body.yiv2001619518hmmessage
{
font-size:10pt;font-family:Tahoma;}
--></style><div><div dir="ltr">
Apparently free/open Unices (Linux, OpenBSD, FreeBSD, NetBSD) have no binary compatibility.<br>I find this very surprising, crazy, disappointing, but apparently true.<br>We must distribute source to achieve the usual expected portability.<br> C source at that, to achieve the usual expected buildability.<br>Or maybe I'm confused.<br>The various commerical systems (Solaris, AIX, Irix, VMS, Windows, Darwin, HP-UX) do/did not have this problem.<br><br><br> - Jay<br><br><br><div><div id="yiv2001619518SkyDrivePlaceholder"></div>> To: <a href="mailto:dragisha@m3w.org"></a><a href="mailto:dragisha@m3w.org"><a href="mailto:dragisha@m3w.org">dragisha@m3w.org</a></a><br>> Date: Sun, 13 May 2012 23:51:15 -0700<br>> From: <a href="mailto:mika@async.caltech.edu"></a><a href="mailto:mika@async.caltech.edu"><a href="mailto:mika@async.caltech.edu">mika@async.caltech.edu</a></a><br>> CC: <a href="mailto:m3devel@elegosoft.com"></a><a href="mailto:m3devel@elegosoft.com"><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a></a><br>> Subject: Re: [M3devel] libXaw.so.6 again<br>> <br>> =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes:<br>> ...<br>> >Another is to ln -s existing libXaw.so.7 to libXaw.so.6<br>> ...<br>> <br>> "Not guaranteed to work" but almost always does, right?<br></div>
</div></div>
</div></blockquote></td></tr></tbody></table></div></blockquote></div></blockquote></body></html>