weiner@novavax.UUCP (Bob Weiner) (06/01/89)
Request to Dave Clemans who recently posted modifications to GCC and G++
to enable them to work on Apollo 680x0 systems.
Dear Dave,
Recently you posted your change files for getting GCC and G++ on Apollo
SR10.1 BSD systems. I'm sure everyone thanks you very much for the
contribution. I was trying to build the system and ran into some problems
that you point out in the README file.
Compile gcc/gas using the Apollo C compiler (setting the appropriate
flags in the makefile; see existing comments in the GCC makefile). You
may also have to play around with includes of <sys/file.h>, and some
strange function pointer references in gcc/stmt.c; but all changes should
be relatively obvious. None of the changes (except for the <sys/file.h>
ones) has to be permanent once you have a gcc/gas binary.
Since we are under the same environment, I thought you could send out a diff
file or at least make explicit what changes are necessary since they don't
seem obvious to me. stmt.c is too large for anything to be obvious to
someone who is not looking to spend a day or two in the code.
What needs to be done with includes of <sys/file.h>?
Exactly, which pointer references should be changed and how in stmt.c?
Thanks very much,
Bob
Bob Weiner, Motorola, Inc., 1500 NW 22nd Ave.,Rm. L1035,
Boynton Beach, FL 33426
(407) 738-2087
UUCP: ...{gatech!uflorida,ucf-cs}!novavax!weiner
--
Bob Weiner, Motorola, Inc., USENET: ...!gatech!uflorida!novavax!weiner
(407) 738-2087dclemans@mntgfx.mentor.com (Dave Clemans @ APD x1292) (06/02/89)
In article <1318@novavax.UUCP>, weiner@novavax.UUCP (Bob Weiner) writes: > Request to Dave Clemans who recently posted modifications to GCC and G++ > to enable them to work on Apollo 680x0 systems. > > Dear Dave, > > Recently you posted your change files for getting GCC and G++ on Apollo > SR10.1 BSD systems. I'm sure everyone thanks you very much for the > contribution. I was trying to build the system and ran into some problems > that you point out in the README file. > > Compile gcc/gas using the Apollo C compiler (setting the appropriate > flags in the makefile; see existing comments in the GCC makefile). You > may also have to play around with includes of <sys/file.h>, and some > strange function pointer references in gcc/stmt.c; but all changes should > be relatively obvious. None of the changes (except for the <sys/file.h> > ones) has to be permanent once you have a gcc/gas binary. > > Since we are under the same environment, I thought you could send out a diff > file or at least make explicit what changes are necessary since they don't > seem obvious to me. stmt.c is too large for anything to be obvious to > someone who is not looking to spend a day or two in the code. > > What needs to be done with includes of <sys/file.h>? > > Exactly, which pointer references should be changed and how in stmt.c? > > Thanks very much, > > Bob > I don't have that information explicitly saved (it's been quite a while since I have had to use Apollo's compilers on gnu stuff), but in general for #include <sys/file.h> first try ifdef'ing it out; i.e. #ifndef apollo #include <sys/file.h> #endif if that doesn't work, include <unistd.h> instead; i.e. #ifndef apollo #include <sys/file.h> #else #include <unistd.h> #endif for stmt.c, first try to compile it as is (the problem areas may have been changed in current versions). If everything works you can ignore this; else you will get errors messages something like "trying to call a non-function" (or something similar). If you look at the referenced lines, and how the names on those lines are declared, you will that the names causing the errors are functions pointers that haven't been de-referenced. Add de-references to all attempts to call through those function pointers (i.e. change "name" to "(*name)") and stmt.c should compile. Sorry, dgc
guy@auspex.auspex.com (Guy Harris) (06/03/89)
>What needs to be done with includes of <sys/file.h>?
By and large, what needs to be done with includes like that in programs
that don't poke around and read the AT&T-derived "struct file" data
structures in the kernel (I would not be surprised to find that no such
data structures exist on Apollo systems) is to completely nuke them.
The problem is that 4.2BSD picked up "fcntl", the three-argument "open",
and various "open"/"fcntl" flags from System III (O_RDONLY, O_WRONLY,
O_RDWR, O_APPEND, O_TRUNC, O_CREAT, etc.); however, they documented it
differently, for no good reason. In S3/S5, you include <fcntl.h> or
possibly <sys/fcntl.h> to get those flags; this works perfectly well
under BSD, but they decided to tell you to include <sys/file.h> and use
some other internal names for those flags.
POSIX specifies that you get them from <fcntl.h>, so Berkeley'll have to
clean up their documentation act at some point.
I suspect the <sys/file.h> stuff is just that (I have difficulty
imagining why GCC would have to look at internal kernel data structures
- especially since it's supposed to work under VMS!), so you should
apply the appropriate changes and then fold those fixes back into the
*mainline* GCC, so nobody has to do them all over again.