[M3devel] libXaw.so.6 again

[Jay]

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.


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?


There is a point to ship C, just not likely relevant to binary compatibility.


 - Jay (briefly/pocket-sized-computer-aka-phone)

On May 14, 2012, at 1:00 PM, Jay <jay.krell at cornell.edu> wrote:

> 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.
> 
> 
> Shipping assembly source would help -- where the breakage is only the .so name. I want to ship C source.
> 
>  - Jay (briefly/pocket-sized-computer-aka-phone)
> 
> On May 14, 2012, at 5:24 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:
> 
>> Hi all:
>> '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.
>> 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?
>> Thanks in advance
>> 
>>  
>> 
>> --- El lun, 14/5/12, Jay K <jay.krell at cornell.edu> escribió:
>> 
>> De: Jay K <jay.krell at cornell.edu>
>> Asunto: Re: [M3devel] libXaw.so.6 again
>> Para: "Mika Nystrom" <mika at async.caltech.edu>, dragisha at m3w.org
>> CC: "m3devel" <m3devel at elegosoft.com>
>> Fecha: lunes, 14 de mayo, 2012 02:20
>> 
>> Apparently free/open Unices (Linux, OpenBSD, FreeBSD, NetBSD) have no binary compatibility.
>> I find this very surprising, crazy, disappointing, but apparently true.
>> We must distribute source to achieve the usual expected portability.
>>  C source at that, to achieve the usual expected buildability.
>> Or maybe I'm confused.
>> The various commerical systems (Solaris, AIX, Irix, VMS, Windows, Darwin, HP-UX) do/did not have this problem.
>> 
>> 
>>  - Jay
>> 
>> 
>> > To: dragisha at m3w.org
>> > Date: Sun, 13 May 2012 23:51:15 -0700
>> > From: mika at async.caltech.edu
>> > CC: m3devel at elegosoft.com
>> > Subject: Re: [M3devel] libXaw.so.6 again
>> > 
>> > =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes:
>> > ...
>> > >Another is to ln -s existing libXaw.so.7 to libXaw.so.6
>> > ...
>> > 
>> > "Not guaranteed to work" but almost always does, right?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120514/1a8fa988/attachment-0002.html>