[M3devel] platform names again.

[Jay K]

I'm not sure that is true.
I know some of the BSDs sometimes carry compatibility libraries -- old versions of libc.
I'm not sure the struct sockaddr is a libc change or a kernel change.
The mention in the release notes sounds like possibly a kernel change.
 
 
I find the level of incompatibility knowingly introduced surprising in some of these systems.
The commercial systems all seem to try and do achieve much better.
 
 
As to more of the original questions, no, I don't think there is much you can do about the "LINUXLIBC6" directory name, in the distributed packages. For when you build from source, BUILD_DIR and TARGET are strictly speaking separate values. BUILD_DIR perhaps should be more fine grained and include more of uname.
 
 
Ultimately we may very well go back to a release form of:
  assembly code for all the Modula-3 code, that goes into just cm3 
  uncompiled C code, again just what cm3 uses 
  a makefile 
  source to everything else 
 
 
That will address this issue.
 
 
And then specific builds for specific systems, like Debian 4.0, Debian 5.0, OpenSUSE 11.0, Fedora 10, etc., the small number we can afford to provide -- possibly in the generic form, possibly in rpm/deb format as the systems "prefer" -- note that this is two separate variables -- the packaging format and the actual ABI.
 
 
It would be good to nail this all down with more certainty -- what actually has changed in the past and/or is likely to change in the future. I wish the set was empty, but 64bit FreeBSD provides enough of an example to prove it is not.
 
 
But, I have to ask, how the check do things like Adobe Flash, Acrobat Reader, etc. work?
 
 
 - Jay


----------------------------------------
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] platform names again.
> Date: Mon, 24 Aug 2009 11:25:26 -0700
> From: mika at newasync.async.caltech.edu
>
>
> On FreeBSD, I find that generally you can install the compiler and
> libraries and headers from the older version and always have that work.
>
> You cannot, however, expect to use a compiler, or an object, from a
> newer version of the system on an older version and have it work.
>
> Mika
>
> jay.krell at cornell.edu writes:
>>We have the same compatibility of any uninteresting multithreaded C
>>code, whatever that is.
>>On reasonable systems that is full compatibility. I don't know if
>>Linux is reasonable. For example 64 bit FreeBSD is not reasonable,
>>struct sockaddr changed from 6.4 to 7.0.
>>
>> - Jay (phone)
>>
>>On Aug 24, 2009, at 1:06 PM, hendrik at topoi.pooq.com wrote:
>>
>>> I have one home directory, shared via NFS among several machines.
>>> Some
>>> run Debian lenny, some run Debian squeeze, one is and AMD64.
>>>
>>> Now I really appreciate the fact that when I run cm3 I get my
>>> executables in a system-dependent diractory.
>>>
>>> But it occurs to me that both Debian lenny and Debian squeeze end you
>>> using the directory LINUXLIBC6.
>>>
>>> Are the files generated there truly Debian-release-independent? Might
>>> they depend in some way on the contents of Debian's shared C
>>> libraries,
>>> for example? And if so, is there a way of overriding the word
>>> "LINUXLIBC6" with some other word so that I can distinguish
>>> them?
>>>
>>> By the time I ship them to /usr/local/cm3, the problem is over, of
>>> course, since eash system has its own /usr/local. But on the way to
>>> there, there could be mishaps in LinuxLIBC6.
>>>
>>> -- hendrik
>>>
>>>