Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!apple!voder!pyramid!ctnews!unix386!mburg From: mburg@unix386.Convergent.COM (Mike Burg) Newsgroups: comp.unix.sysv386 Subject: Re: Why can't elves cough? Message-ID: <6405@unix386.Convergent.COM> Date: 5 Mar 91 20:57:59 GMT References: <27D314DF.1D4E@telly.on.ca> Organization: Unisys/Convergent, San Jose, CA Lines: 99 In article <27D314DF.1D4E@telly.on.ca>, evan@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