Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!husc6!cs.utexas.edu!pp!riunite!rfg
From: rfg@riunite.ACA.MCC.COM (Ron Guilmette)
Newsgroups: comp.lang.c++
Subject: Re: Are C++ translators usable under Xenix?
Message-ID: <208@riunite.ACA.MCC.COM>
Date: 14 May 89 19:06:38 GMT
References: <53174@linus.UUCP>
Reply-To: rfg@riunite.UUCP (Ron Guilmette)
Organization: MCC  Austin, Texas
Lines: 88

In article <53174@linus.UUCP> nsds@mbunix.mitre.org (Neil Smith) writes:
>...  I'm working on
>porting some C++ code (developed using an AT&T-derived translator under
>Ultrix) to Xenix-386.  The Xenix C++ development environment (also
>using an AT&T-derived translator) naturally uses the native Xenix C
>compiler to generate object files from the translated C++.  As it
>turns out, that C compiler recognizes unique identifiers only through
>the first 31 characters.  This causes compiles to fail...

Yessir.

>Has anyone else run into this problem, and/or found a workaround?  

You bet!

>...that use compilers with (relatively) short identifier lengths.
>I should think that MSDOS-hosted translators using Microsoft C would
>suffer from the same problem...

Right again.

>Sigh...maybe this will convince the powers-that-be go to sys V...

Correct me if I'm wrong, but Xenix *is* System V.

There is a solution to you problem, but it requires some work on
your part.

First, try to find out if the version of Xenix you are using makes
use of AT&T's COFF object formet (I believe that it does).

Assuming that your version of XENIX uses either COFF or "a.out"
object format (and *not* any funny Intel/Microsoft format) you
are in luck.  Here is what you need to do.

First, get a copy of the GNU project assembler (available from the
Free Software Foundation).  Send me mail if you need instructions on
how to obtain this GNU/FSF software.  The GNU assembler is written
in C and can be hosted and targeted for a 386 (and COFF I believe...
somebody correct me if I'm wrong).  Use your Xenix C compiler to
create a version of "gas" (i.e. the GNU assembler) for your system.
This step is necessary because the Microsoft assembler deviates too
far from a "standard" UNIX-style assembler to be of much use to you
when you are using the other GNU tools.

Second, get the GNU ANSI C compiler and use the Xenix C compiler to
create a version of this compiler for your system.  This may entail
a lot of dinking around to get this bootstrap process going because
the Microsoft C compiler is buggy in lots of little ways (which
become obvious when you try to port C code to a Xenix or MS-DOS
system).  Fortunately, you are not alone.  I can give you E-mail
addresses for a couple of people who have already done this port
and they can (and probably would be willing to) help you reproduce
what they have already accomplished (only with a lots less grief).

Now you have a good UNIX-style assembler and a good ANSI C compiler.
Now for the final step.  Get the sources for the GNU C++ compiler
(written in C of course).  Use the GNU C compiler to compiler the
GNU C++ compiler.  Before you do, add in the (unofficial and
unapproved) COFF patches for the GNU C++ sources which are available
from the GNU underground (i.e. me).

Note that I have not yet heard of *anybody* who has actually gotten
GNU C++ running on Xenix, but I don't forsee any special problems.

Finally, get the sources for GNU libg++ which has a lot of the stuff
in it to support C++ streams, etc.  Use your new GNU C++ compiler
to compile libg++.

As should be obvious, the above process is *not* for the faint of heart.
You need to be able to get in and hack for yourself when necessary.
**** This is *not* shrink-wrapped software. ****  If that is what you
want or need then forget all about this.  If however you feel that
you qualify as at least a "brown belt" level UNIX/compilers/tools
guru, then this route may be for you.  Keep in mind before you decide
to start down this road that "formal" support is totally non-existant.
Many people may be willing to help you in their spare time, but nobody
is getting paid to do it.  Another way of saying this is "If you can't
stand the bugs, stay out of the roach-motel." :-)

On the other hand, there is (at least) one *very* nice thing about all
of these software tools.  You can't beat the price.

-- 
// Ron Guilmette  -  MCC  -  Experimental Systems Kit Project
// 3500 West Balcones Center Drive,  Austin, TX  78759  -  (512)338-3740
// ARPA: rfg@mcc.com
// UUCP: {rutgers,uunet,gatech,ames,pyramid}!cs.utexas.edu!pp!rfg