earle%prophet@SUN.COM (Greg Earle) (10/19/88)
Many people have been gracious enough to point out that the file /usr/include/sys/ioccom.h should have been altered and stored in /usr/local/lib/gcc-include/sys by `fixincludes'. Because this was not true, I went to find out why. The real reason for the problem is that the `fixincludes' script does not work under SunOS 4.0, because it makes use of the `dirname' command which was inadvertently left off the SunOS 4.0 release tapes. This causes the `fixincludes' script to fail for most cases, and a new (fixed) version of `ioccom.h' was never created. This caused the problem. For anyone interested, to fix this problem just obtain a copy of the /usr/bin/dirname shell script from any SunOS 3.5 system (or, more specifically, look at your own SunOS 3.x `dirname'; if it has an sccsid that contains `from S5R2 1.2' then it is a correct version. To make it a `proper' 4.0 version, change the version number to `@(#)dirname.sh 1.4 88/02/08' I have submitted this oversight as a bug. - Greg Earle Sun Los Angeles Consulting earle@Sun.COM poseur!earle@lroy.JPL.NASA.GOV (quicker)
earle@MAHENDO.JPL.NASA.GOV (Greg Earle) (10/20/88)
In article <8810182235.AA04232@prophet.sun.com> I wrote: >The real reason for the problem is that the `fixincludes' script does not >work under SunOS 4.0, because it makes use of the `dirname' command which >was inadvertently left off the SunOS 4.0 release tapes. This causes the >`fixincludes' script to fail for most cases, and a new (fixed) version of >`ioccom.h' was never created. This caused the problem. Whoops! Check that; `dirname' was NOT left off the SunOS 4.0 release tapes; it is part of the `System V' software that I steadfastly refuse to dump onto my system. So, Sun users, beware, if you don't install the `System V' software during `suninstall' this will bite you, when you try to run `fixincludes'. >I have submitted this oversight as a bug. Not now I haven't ... :^) - Greg