geirt@Lise.Unit.NO (Geir Torheim) (06/21/91)
I've heard that IV3.0 requires At&T C++.
Will there be a version for g++ as well?
When can we expect such a version?
Please answer ASAP!!
- Geir
email: geirt@lise.unit.no smail: Geir Torheim
Centre for Computed Aided Learning
Phone: +47 7 59 47 87 DSL-UNIT, NTH
Fax: +47 7 59 14 37 7034 TRONDHEIM bowles@stsci.EDU (Richard Bowles) (06/22/91)
geirt@Lise.Unit.NO (Geir Torheim) writes: >I've heard that IV3.0 requires At&T C++. >Will there be a version for g++ as well? >When can we expect such a version? >Please answer ASAP!! > - Geir >email: geirt@lise.unit.no smail: Geir Torheim > Centre for Computed Aided Learning >Phone: +47 7 59 47 87 DSL-UNIT, NTH >Fax: +47 7 59 14 37 7034 TRONDHEIM I was hoping this question (and it's answer) would be in the FAQ -- is there someone who can authoritatively keep everyone up-to-date on what works with g++ and what still requires cfront? Richard Bowles bowles@stsci.edu
mrs@MA.SECS.CSUN.EDU (Mike Stump) (06/25/91)
Well, since people ask, here is something, someone can put in there FAQ list (Linton, I think put out one before). I am a pretty good person to bug about the g++ work and InterViews, unless one person that knows who he is wants to volunteer instead. ;-) Mail can be sent to ``mrs@csun.edu''. The address this came from will also work, so feel free to just reply. For me, all things work except Unidraw and doc. This means that there is no ibuild or idraw, yet. At the end is my pre iv-3.0-g++-1.3 work. > Date: 21 Jun 91 20:36:35 GMT > From: bowles@stsci.edu (Richard Bowles) > Organization: Space Telescope Science Institute, Baltimore, MD 21218 > Subject: Re: g++ and IV3.0 > Message-Id: <bowles.677536595@ghost.stsci.edu> > References: <1991Jun21.093536.15229@ugle.unit.no> > Sender: owner-comp-windows-interviews@shelby.stanford.edu > > geirt@Lise.Unit.NO (Geir Torheim) writes: > > >I've heard that IV3.0 requires At&T C++. > >Will there be a version for g++ as well? > >When can we expect such a version? > > > - Geir > > >email: geirt@lise.unit.no smail: Geir Torheim > > Centre for Computed Aided Learning > >Phone: +47 7 59 47 87 DSL-UNIT, NTH > >Fax: +47 7 59 14 37 7034 TRONDHEIM > > I was hoping this question (and it's answer) would > be in the FAQ -- is there someone who can authoritatively > keep everyone up-to-date on what works with g++ and > what still requires cfront? > > Richard Bowles > bowles@stsci.edu Here is my pre iv-3.0-g++-1.3 work: (1.2 is on interviews.stanford.edu, but I would not recommend it at this point, as things have progressed quite a bit since then.) Here are four sets of patches to help you get iv-3.0-beta working with g++. I am using iv-3.0-beta and libg++1.39.0 and gcc-1.92 on a sun4 SPARC to cross compile to a vax running Ultrix 4.1. (It is faster that way!) Also, I manual do a: for i in *.c do mv $i ${i}c done in the IV source directories on demand. Also, I have "rcp -r"ed the whole /usr/include over to my SPARC, and then "rcp -r"ed my gcc fixincludes directory on top of my new directory, replacing any unneeded system headers. The script below was then run in the new include directory: #!/bin/sh while read i do echo "doing $i" if [ -d "$i.bak" -o -f "$i.bak" ]; then echo "$i: already exists" >&2 else mv "$i" "$i.bak" sed 's/\(#[ ]*include[ ]*["<]\)/\1BASE\//' <"$i.bak" >"$i" if cmp -s "$i" "$i.bak"; then rm -f "$i" mv "$i.bak" "$i" fi rm -f "$i.bak" fi done The final step was to provide a symbolic link in the gcc-include directory from BASE to . as in ln -s . BASE. This hackery makes it impossible for a system headerfile to escape back into the c++ include hierarchy. Also, this way, you can have many cross compilers install on your system and the g++ header files from libg++ will choose not the files in /usr/include, but whatever files it should! Note, expr.c should be hand compiled without any optimization flags, as gcc cannot compile it correctly on a sparc. Repeat by compiling: unsigned ui; main() { return ui / 23; } on a sparc for a vax. Watch the core dump. This file does not constitute a release, or a permanent migration version of iv. In the future, I will provide ONLY diffs against virgin sources. What you get with these patches is: ability to compile all of src/lib ability to compile all of src/bin/alert ability to compile all of src/bin/dclock ability to compile most (all but 6 files) of src/bin/doc ability to compile all of src/bin/ibuild ability to compile all of src/bin/iclass ability to compile all of src/bin/idraw ability to compile all of src/bin/ifb ability to compile all of src/bin/ifc ability to compile all of src/bin/logo ability to compile all of src/bin/mailbox After patching, keep this file around, because when you get the next one, you will need to UNDO these patches, or re-extract virgin 3.0-beta. Note, these patches should now enable you to compile any interviews programs you have. If you are a new user, these are not yet for you, don't waste your time. [ Comments about compiler availability... ] If you don't feel like patching, building and installing it, don't bother trying to uses these diffs. dclock, iclass, ifb, ifc, logo, mailbox all appear to work just fine. alert did work, but now won't link, workaround, specify the LIBS twice. ibuild, idraw and doc may not work perfectly yet. idraw does work on a sparc though. Here is my planning guide: Phase One (Completed) Get the source files turned into .o files a quickly as possible If this means making weird changes to IV, so be it. Phase Two (Completed) Get things to link Phase Three (In progress) Verify that the a.out's work. Bug fix the compiler where necessary. Bug fix IV where necessary. (This so far has not been the case, usually) Workaround as necessary. Phase Four (About to start) Reduce the number of #ifdef __GNUC__ in the code, by way of compiler enhancement, to an absolute minimum. Phase Five (Accepting offers) Write the missing library code for libg++ for those things (like doc) that need it. Phase Six Verify that author released versions of software work as well as what I have. If not, submit bug fixes and enhancements. Send any mods, additions or problems to Mike Stump <mrs@csun.edu>. The vax-include.diffs file is a short file containing diffs against some standard headerfiles on ultrix that needed fixing.