news@linus.UUCP (USENET NEWS) (05/12/89)
Here's a nice juicy implementation-related topic (just when you
thought the language lawyers were having all the fun). 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, since cfront
transforms C++ identifiers into rather long C identifiers.
From: nsds@mbunix.mitre.org (Neil S. Smith)
Path: mbunix!nsds
An example: the code fragment
#include <stream.hxx>
istream *qin;
ostream *qout;
int foo(streambuf *sba, streambuf *sbb) {
qin = new istream(sba);
qout = new ostream(sbb);
return 0;
}
causes the generation of (among other things):
...
register struct istream
*_au0__Xthis__ctorFPCstreambuf__I_PC_ostream___istream = 0;
struct ostream *_au0__Xthis__ctorFPCstreambuf___ostream ;
...
Both of these declarations are identical in the first 31 characters,
so the C compiler chokes when trying to process this code. The Ultrix
C++ translator has no problems with this; I believe that its cc can
handle identifers out to 256 characters.
Now for the questions:
Am I up the proverbial creek (I believe so)?
Has anyone else run into this problem, and/or found a workaround?
Please don't tell me to re-write the code so that cfront generates an
identifier of < 31 characters. Considering the simplicity
of the constructs involved, this problem represents a significant
limitation with the IMPLEMENTATION of cfront-style C++ translators
that use compilers with (relatively) short identifier lengths.
I should think that MSDOS-hosted translators using Microsoft C would
suffer from the same problem...
Sigh...maybe this will convince the powers-that-be go to sys V...
---------------------
Neil Smith "Relax, don't worry, have a homebrew!"
The MITRE Corporation M/S B310 Burlington Road Bedford, MA 01730
Ma Bell: (617) 271-8278 Internet: nsds@mitre.orgrfg@riunite.ACA.MCC.COM (Ron Guilmette) (05/15/89)
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
jima@hplsla.HP.COM (Jim Adcock) (05/15/89)
Well, I would certainly recommend that you 1) play with an already ported version of g++ on some other machine in order to get some feel for what you'd be getting if you do port g++ to your machine. 2) check out, and maybe verify with a lawyer that the Gnu copyleft restrictions don't negatively impact the way you do business. 3) talk to someone who has done a g++ port to get a feel for what is involved. I've used both the AT&T and Gnu products, and they both have their advantages and disadvantages.
ark@alice.UUCP (Andrew Koenig) (05/16/89)
I suppose it's worth mentioning that cfront 2.0 is much better than previous versions at generating names less than 32 characters long if needed. It uses a more compact encoding for names of functions that have several arguments of the same type. Moreover, if the encoded name is still too long, it uses a hashing scheme (under control of a compilation option) to cut the name down to 31 characers while still maintaining what we hope is an acceptably small probability of collision. -- --Andrew Koenig ark@europa.att.com