Why can't elves cough?

[Mike Burg]

In article <27D314DF.1D4E at telly.on.ca>, evan at telly.on.ca (Evan Leibovitch) writes:
[text deleted]

I don't think that either "camp" of the PC UNIX producers (AT&T and SCO)
want to supply detail compatiblity for each other. [And with some older
versions of their own OS! ;-) ;-)]. They want you to use their product
and (in case of developers) to produce for their product.
 
> Is there indeed no backwards compatability in the R4 compiler? Although
> the obvious answer is to buy SCO because binaries compiled on it will
> run on all UNIX vendors' current releases, I'm very hesitant to buy
> software mainly because it's the lowest common denominator.

The only backwards compability for R4 cc is the ability to execute COFF
binaries, and convert COFF to ELF format (i.e. ld, size, dis, etc will all
accept COFF but will do a internal convertion to ELF).

> 
> So what are the other choices? Which of these options is best? Are they
> even possible? Are there other options?
> 
> - If you have a present copy of Interactive/Dell/ESIX R3.2, can you hang
>   onto the 3.2 software development set when you upgrade to R4? Then you
>   could load the 3.2 compiler, which should run fine under R4 (though the
>   libraries will still be the old ones).

I've heard this can be done.  All of the SVR4 compiler is located in
/usr/ccs with links to /usr/bin. However, there are some libraries left
in /usr/lib you'll have to watch out for.

> 
> - Are there any plans for SCO 3.2 to support elf? Considering the
>   direction the company is going (back to the Xenix philosophy), it
>   seems that such a move would not be in the company's strategic
>   interest. But we can hope...

It will be interesting to see if they do. I highly doubt it if they
do anything about ELF - they have stated on record that their "users"
don't have a demand for it ("SVR4 features").

> - Use gcc. Can it possibly be built to use the R4 libraries, while
>   having a run-time switch to produce either coff or elf?

I've tried using GCC-1.37.1 (no Gnu ld or GAS) on SVR4. It's fine to
compile most things, but however it will gack on the #if machine(i386)
directives commonly found in /usr/include/sys files. Anyone else have
any luck? 1.38, 1.39?

All of the SVR4 libraries are in ELF format, plus the functions are compiled
for a SVR4 enviroment (i.e. a lot of system calls have been extended in
SVR4 - see below). GCC would have to be taught about a 3.2 enviroment
verus a R4 one - which libraries, include files, binary formats to use.
You'd still need the 3.2 libraries.

> - Will it be economically worthwhile for a commercial compiler vendor to
>   offer a development set with cross-compiling options?

Well, it depends on how large of a demand there is for producing COFF
binaries on a SVR4, SCO binaries on SVR4/3.2, or ELF under SCO.
It's like anything else - if there's money to be made......

My personal opinion is develop/compile it on the platform the product
is intended for. You'll won't have the hassiles of compability. However,
this can only be done if you have the resources.

As far as compiling for R3.2 under R4 - AT&T or any other AT&T Unix
vendor could produce a 3.2 development system that would work and be
installed "cleanly" in R4. It just a matter of having the install scripts
place the package into another directory tree, and having the utilities make
use of the altered layout (namely 'cc').

> A larger question is "what are the advantages of compiling for elf when
> coff is more portable?" What features of R4 *require* something to be
> compiled with elf?

The two big advantages with ELF is dynamic libraries (space saving) and the
ability to directly map the executable into memory without having to do page
aligment from disk (load and page fault time savings). Both features make
heavy use of mmap().

The other features are pretty minor (for COFF verus ELF):
- clean binary information extraction across different machine architectures,
"self describing" binary sections, read only (const char */int/etc) data areas.

Once the kernel has loaded the binary, every system call acts the same for
COFF or ELF - the expection is for Xenix binaries. As for the question
of what about SVR3.2 and SVR4 common system calls that have different
arguments or different argument formats work together.  (i.e. stat in 3.2
has a 16-bit inode file, while SVR4 has a 32-bit plus extra fields). Some of
SVR4 system calls are really renamed - take a look at /usr/include/sys/stat.h.
When you call stat() you are really calling _xstat with a version number as
one of it's arguments.  It is possible for a ELF binary to call a old SVR3.2
old format system call, while a COFF binary can call a new SVR4 one.

>  Evan Leibovitch, Sound Software, located in beautiful Brampton, Ontario
-- 
----------------------------------
Michael Burg -  Unisys/Convergent Corp.  Unix Intel Platforms Division San Jose
Phone: (408) 456-5934 UUCP: uunet!pyramid!ctnews!unix386.Convergent.com!mburg