Re: Building and install GCC 8.3.0, OpenBSD 7.2 on DEC Alpha EV5

[Jonathan Wakely <jwakely.gcc@gmail.com>]

On Fri, 20 Jan 2023 at 15:41, Mark Butt <mark@markwbutt.com> wrote:
>
> Hi Everyone,
>
> I have OpenBSD 7.2 installed and running on an AlphaServer 4100.  DEC Alpha EV5 processors.
> No major issues with getting it running on this old hardware other than a slight bug one of the developers over at OpenBSD squashed for me.
>
> I have been having great success with building modern tools and software on the system.  No problems at all.  Except for one…
>
> A particular piece of software I am trying to build requires GCC 8.3.0 which is much newer than the version that comes with OpenBSD.  I am attempting to build and install GCC 8.3.0 in a separate location from the main system compiler as OpenBSD doesn’t usually take kindly to having its system compiler version changed.
>
> I have used the gcc-8.3.0 included script to download and extract the dependancies that GCC will need.  I have also downloaded, compiled and installed the latest version of binutils.  Installed to /usr/local
>
> These are the configure and make commands I am using, and I am running this in a location NOT in the source tree.

All that info rules out 90% of the questions on this list, so that's a
great start!

Do you really need gcc-8.3.0 specifically? You should generally use
the newest from a given release series. If you need gcc-8 then 8.5.0
would be my choice. Why would 8.3.0 be better than 8.5.0?

> bash-5.2# pwd
> /u01/software/gcc/build-gcc-8.3.0
>
> bash-5.2# ../gcc-8.3.0/configure CFLAGS="-I/usr/include -I/usr/local/include" LDFLAGS="-L/usr/lib -L/usr/local/lib" --disable-multilib --disable-cet --enable-language=c,c++ --prefix=/usr/local --disable-nls

Why are you setting those CFLAGS and LDFLAGS? Aren't those the default
locations that are always searched anyway?

> bash-5.2# /usr/local/bin/make
>
> Things appear to go well for quite a while (two 300Mhz processors), then the make dies with:
>
> gcc -c -DHAVE_CONFIG_H -I/usr/include -I/usr/local/include  -I. -I../../../gcc-8.3.0/libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstr10:31:49 [22/1989]
> dantic  -D_GNU_SOURCE ../../../gcc-8.3.0/libiberty/objalloc.c -o objalloc.o
> ../../../gcc-8.3.0/libiberty/objalloc.c: In function 'objalloc_create’:
> ../../../gcc-8.3.0/libiberty/objalloc.c:95: error: 'PTR' undeclared (first use in this function)
[...]
> I took a look at ../gcc-8.3.0/libiberty/objalloc.c  and it appears to be having issues with:
> Line 95 referenced in the error above:  ret->chunks = (PTR) malloc (CHUNK_SIZE);
>
> This could entirely be down to me going about this endeavour the wrong way.  I have been doing a lot of reading, and experimenting over the past two weeks… but not much luck getting past this.  I have tried the default shell for OpenBSD as well as the bash shell noted above incase there was something about the bash install I did… I have a personal preference towards bash :)

This has nothing to do with your shell. PTR should be defined by
include/ansidecl.h

#if defined (__STDC__) || defined(__cplusplus) || defined (_AIX) ||
(defined (__mips) && defined (_SYSTYPE_SVR4)) || defined(_WIN32)
/* All known AIX compilers implement these things (but don't always
   define __STDC__).  The RISC/OS MIPS compiler defines these things
   in SVR4 mode, but does not define __STDC__.  */
/* eraxxon@alumni.rice.edu: The Compaq C++ compiler, unlike many other
   C++ compilers, does not define __STDC__, though it acts as if this
   was so. (Verified versions: 5.7, 6.2, 6.3, 6.5) */

#define PTR        void *
[...]
#else    /* Not ANSI C.  */

#define PTR        char *


So it's either defined to void* or to char*. I don't see how it can be
undefined, if that file has been included properly. Right at the top
of libiberty/objalloc.c we have:

#include "config.h"
#include "ansidecl.h"

You'll need to figure out what's happening there. Go into the
/u01/software/gcc/build-gcc-8.3.0/build-alpha-unknown-openbsd7.2/libiberty
build directory and run make (without any -j option). That will give
you the gcc command being run to build objalloc.o (which is shown
above, but seems to have a "10:31:49 [22/1989]" in it, maybe from your
terminal or something).

Re-run that command with -save-temps added and then inspect the
objalloc.i file to see if ansidecl.h is being included, and if so,
which path it's being found in. It should be the one in the gcc-8.3.0
source tree, at gcc-8.3.0/include/ansidecl.h
Is some other ansidecl.h elsewhere in your filesystem being found?
I strongly suspect it is, because of your custom CFLAGS:
-I/usr/include -I/usr/local/include  -I.
-I../../../gcc-8.3.0/libiberty/../include

The third path there is the one that should lead to ansidecl.h but if
a file with that name is present in /usr/include or /usr/local/include
then things will break.