GCC 3.0.2 build on OSF1 5.1a

[wadedl]

   To the GCC developer community:

   Please post this as it may be of help to those trying to compile GCC 3.0.2
on Compaq Alpha systems.

Thank You
David L. Wade

**********************************************************************
David L. Wade                                EMail: address@hidden
Senior Systems Programmer Analyst                     Ph. 858-455-3342
General Atomics                                       Fx. 858-455-2692
3550 General Atomics Court                San Diego, California  92121     
**********************************************************************
opinions, conclusions, or recommendations expressed above are my own
and do not necessarily represent the views of my employer.

Dear Christian.PENON;

   Your email prompted me to a new tactic on the OSF1 5.1a compile of gcc.
I am pleased to say with more success than previous. Thank you for your email.
No one else had replied to my etreaties, for several months and I had all 
but given up on ever building gcc for OSF1 5.1. I think my fix in the build
produces a good compiler, but since it is so new, I haven't given it a good
run-through. It seems to work compiling some simple programs. Since I do not
have DejaGNU installed, I have not tested my build with it, but for the fix
to the stdio.h I have guessed at, the compile seems clean and I have tested 
gcc,g++ and g77 with small programs. It seems to work.

   First let me say that the truncation of libiberty.a is caused by the GNU
ar. The actual file which causes the truncation is necessary to the build, 
so To get around the GNU ar I insure that the Tru64 5.1a ar is used. This 
is done by insuring the GNU distribution is later in the path than /usr/bin.
Since the gcc build will require other GNU utilities 
( especially make, the 5.1a make incurrs "line too long" error
s and won't work), you have to be careful where you include GNU in your path.
There is a point in my build where a corrupt line in stdio.h causes the 
compile to fail. I beleive there is a bug in the make which puts extraneous
characters before the macro name va_list. The compile fails because it
does not know how to redefine __va_list. Without lots of investigation I assume 
the programmer really wants va_list and I fix it with vi before resuming
the build, as you will see.

   I have built gcc from the new gcc-3.0.2 release which is now available
from ftp.gnu.org/pub/gcc/gcc-3.0.2. I haven't tried my method on earlier
releases. At all times I am using GNU utilities I have build myself from
the distribution. I rely only on the native compilers provided by Compaq
(that is, all GNU utilities are built with cc, not any gcc). I begin with
a virgin GNU installation directory and build and install the gunzip, make,
flex. bison and binutils utilities one at a time in that order.
I obtain these from the official gnu site ftp.gnu.org

   Here is what I do:

   Begin with an empty GNU installation directory,

   /usr/local/gnu
   
   Using the configure line 

   ./configure -prefix=/usr/local/gnu -exec-prefix=/usr/local/gnu

   build and install the following ( in order ):

   gzip-1.2.4a
   make-3.79.1
   flex-2.5.4a  ( non-gnu, but from the ftp.gnu.org/non-gnu )
   bison-1.28
   binutils-2.11.2

   The configure should find cc not any gcc, and on my systems all of
   these build cleanly from the source.
   You begin the build of gcc then with these utilities in your
   local gnu bin directory.

   Since we want the OSF1 5.1a ar to be found, we place the /usr/local/gnu/bin
   last in our path:

   set path = ($path /usr/local/gnu/bin)

   My path looks like this when I begin the build of gcc:

   path    (/home/wadedl /home/wadedl/bin /bin /sbin /usr/bin /usr/sbin 
/usr/local/bin /usr/ucb /usr/ccs/bin /usr/bin/X11 /usr/local/gnu/bin)

   Get the gcc-3.0.2 and gcc-testsuite-3.0.2 into the build directory and
   do the following:


host> gunzip gcc-3.0.2.tar.gz
host> gunzip gcc-testsuite-3.0.2.tar.gz
host> tar xvf gcc-3.0.2.tar
host> tar xvf gcc-testsuite-3.0.2.tar
host> mkdir objdir
host> cd objdir
host> ../gcc-3.0.2/configure -prefix=/var/tmp/gnu -exec-prefix=/var/tmp/gnu 
-enable-shared
host> /usr/local/gnu/bin/make bootstrap
    /* this will fail on a compile error from the file
       ../objdir/gcc/include/stdio.h beneath your build directory,
       mine is /var/tmp, so I edit the file /var/tmp/objdir/gcc/include/stdio.h
       and find around the referenced line number 421 __va_list instead of
       va_list. Guessing that the programmer means va_list I correct it. */
host> vi /var/tmp/objdir/gcc/include/stdio.h
     /* In or around line 421, change __va_list to va_list */
host> /usr/local/gnu/bin/make bootstrap
host> /usr/local/gnu/bin/make all
host> /usr/local/gnu/bin/make check
host> /usr/local/gnu/bin/make install
host> /usr/local/gnu/bin/make clean
host> /usr/local/gnu/bin/make distclean

   To clarify, let me explain that when I change __va_list to va_list I am
guessing that this is what is intended. I haven't confirmed any of this
with the developer, or the GCC consortium or anybody like that. Since stdio.h
is produced in the build directory from the configure and make, there should 
be a way to fix the distribution so it produces a compilable line 421 
in stdio.h. I haven't tried to do this. Because make knows what has been 
built up to, after fixing stdio I simple restart the make. As caveat emptor
I consider my build to be a voodoo fix, which hasn't been given yet a complete
trial.

   Well, I hope this helps - Please let me know success or failure, or if
you have problems with this method, or with the build itself. I will keep
you informed.

Thanks!

Yours,
David L. Wade

**********************************************************************
David L. Wade                                EMail: address@hidden
Senior Systems Programmer Analyst                     Ph. 858-455-3342
General Atomics                                       Fx. 858-455-2692
3550 General Atomics Court                San Diego, California  92121     
**********************************************************************
opinions, conclusions, or recommendations expressed above are my own
and do not necessarily represent the views of my employer.