On 2014-07-01 08:16, Patrick J. LoPresti wrote:
On Tue, Jul 1, 2014 at 6:17 AM, Lamar Owen <lo...@pari.edu> wrote:
...
That's part of the
reason the CentOS team has changed the statement '100% binary compatible' to
'functionally compatible' since they do mean different things, but the
latter is more indicative of reality than the former ever has.
The *goal* of CentOS used to be binary compatibility, even if it was
never 100% achieved. Since the acquisition by Red Hat, that is no
longer even the goal, for obvious reasons.
Pat, this is nominally impossible with modern compilers as I discovered a
long time ago. The compilers I am used to embed a time stamp in the various
files compiled. This time stamp will differ between machines used to compile
the code. So when you perform the binary compare you will hit errors. The
compiler on which I discovered this first (Microsoft C7) the embedded dates
were not even the same length. So once I hit that difference the binary
compare was broken for the rest of the file. If GNU C has this same feature
prattling about binary identity and so forth is nonsense.
...
- Pat
It is good that some of these issues are being aired. But some of the issues
raised smokescreen other more pertinent and substantive issues such as RHEL
traceability. (In the hardware world I infested long ago all test equipment
had to be calibrated in a manner traceable to NBS (now NIST). That issue was
solved.) This RHEL traceability issue is significant as is traceability back
to creators for non-RHEL code replacements for RHEL proprietary software and
for any add-on software provided by sources in the path from SL back to RHEL.
Fussing about binary compatibility is needless obfuscation.
The issue at its base is "who do you trust"? It helps to know who is asking
you to trust when you make that decision.
{^_^} Joanne
