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

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

[Mark Butt]

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.

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

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) 
../../../gcc-8.3.0/libiberty/objalloc.c:95: error: (Each undeclared identifier is reported only once 
../../../gcc-8.3.0/libiberty/objalloc.c:95: error: for each function it appears in.)
../../../gcc-8.3.0/libiberty/objalloc.c:95: error: expected ';' before ‘malloc'
../../../gcc-8.3.0/libiberty/objalloc.c: At top level: 
../../../gcc-8.3.0/libiberty/objalloc.c:115: error: expected '=', ',', ';', 'asm' or '__attribute__' before ‘_objalloc_alloc'
../../../gcc-8.3.0/libiberty/objalloc.c:198: error: expected declaration specifiers or '...' before ‘PTR'
../../../gcc-8.3.0/libiberty/objalloc.c:199: error: conflicting types for ‘objalloc_free_block'
../../../gcc-8.3.0/libiberty/../include/objalloc.h:113: error: previous declaration of 'objalloc_free_block' was here
../../../gcc-8.3.0/libiberty/objalloc.c: In function 'objalloc_free_block’:
../../../gcc-8.3.0/libiberty/objalloc.c:201: error: 'block' undeclared (first use in this function)
../../../gcc-8.3.0/libiberty/objalloc.c:260: error: 'PTR' undeclared (first use in this function)
../../../gcc-8.3.0/libiberty/objalloc.c:260: error: expected ';' before ‘first'
../../../gcc-8.3.0/libiberty/objalloc.c:290: error: expected ';' before ‘p'
make[3]: *** [Makefile:1041: objalloc.o] Error 1
make[3]: Leaving directory '/u01/software/gcc/build-gcc-8.3.0/build-alpha-unknown-openbsd7.2/libiberty'
make[2]: *** [Makefile:2645: all-build-libiberty] Error 2
make[2]: Leaving directory '/u01/software/gcc/build-gcc-8.3.0'
make[1]: *** [Makefile:26838: stage1-bubble] Error 2
make[1]: Leaving directory '/u01/software/gcc/build-gcc-8.3.0'
make: *** [Makefile:952: all] Error 2


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 :) 

If anyone sees this and has an “A-HA!” moment about what could be wrong, I would certainly appreciate any assistance you could offer.

Thanks all and enjoy the weekend!
-M
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

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

[Jonathan Wakely]

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.

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

[Mark Butt]

Hi Jonathan,

Thanks for your fast reply!  My answers and comments are below.  There is also an update at the very bottom.

>> 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?
> 

No, there is no reason to be at 8.3.0 other than this was the minimum required.  I thought that I might have better luck getting 8.3 to work vs
a newer version given the age of the hardware, I will, however, try a newer version as suggested.

Would you recommend going with a particular version or just get the latest and greatest?

>> 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?
> 

Yes, I assumed they would be defaulted as well.  Several postings on various forums/mailing lists about building with GCC on OpenBSD recommended setting them exclusively, but I will try
the build again without specifying them to see if that helps.

>> 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).

Sorry about that,  those extra characters, "10:31:49 [22/1989]" ,  are coming from tmux. 

> 
> 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

You are correct!  Another version is being discovered...  
# 1 "/usr/local/include/ansidecl.h"

> 
> 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.

*** BEGIN UPDATE ***

I made the changes to the configure command that were suggested and the build moves along much further.
It now stops with an error indicating that crt1.o cannot be found when building libgomp.
I have a crt0.o but not a crt1.o

Is that something that I can/should build?  Or is there another change I should make to the configure command?
I know the documentation for the configure options for gcc indicates that you should keep it simple...  perhaps, that might be my problem...

Again, if anyone is able to easily say what they think the problem is, please let me know.  
This is the latest configure command that I have used.

bash-5.2# ../gcc-8.3.0/configure --disable-multilib --disable-cet --enable-language=c,c++ --prefix=/usr/local --disable-nls --disable-lto

I also tried gcc-8.5.0 with the same result... 8.5.0 is definitely what I will be trying to get to work from here out.

bash-5.2# ../gcc-8.5.0/configure --disable-multilib --disable-cet --enable-language=c,c++ --prefix=/usr/local --disable-nls --disable-lto

I pulled this blurb off a support post from a forum:

*** BEGIN ***
Both crt0/crt1 do the same thing, basically do what is needed before calling main() (like initializing stack, setting irqs, etc.). You should link with one or the other but not both. They are not really libraries but really inline assembly code. As far as I understand, crt comes in two "flavours"

crt1 is used on systems that support constructors and destructors (functions called before and after main and exit). In this case main is treated like a normal function call.
crt0 is used on systems that do not support constructors/destructors.
*** END ***

The following is the message that I am getting when trying to build gcc 8.5.0:

*** BEGIN ***

Checking multilib configuration for libgomp...                                      
Configuring stage 1 in alpha-unknown-openbsd7.2/libgomp                                                                                                                 
configure: loading cache ./config.cache                                             
checking for --enable-version-specific-runtime-libs... no                                                                                                               
checking for --enable-generated-files-in-srcdir... no                               
checking build system type... alpha-unknown-openbsd7.2                                                                                                                  
checking host system type... alpha-unknown-openbsd7.2                               
checking target system type... alpha-unknown-openbsd7.2                                                                                                                 
checking for a BSD-compatible install... /usr/bin/install -c                                                                                                            
checking whether build environment is sane... yes                                   
checking for a thread-safe mkdir -p... /usr/local/bin/mkdir -p                                                                                                          
checking for gawk... awk                                                            
checking whether /usr/local/bin/make sets $(MAKE)... yes                                                                                                                
checking for alpha-unknown-openbsd7.2-gcc... /u01/software/gcc/gcc-8.5.0_build-dir/./gcc/xgcc -B/u01/software/gcc/gcc-8.5.0_build-dir/./gcc/ -B/usr/local/alpha-unknown-
openbsd7.2/bin/ -B/usr/local/alpha-unknown-openbsd7.2/lib/ -isystem /usr/local/alpha-unknown-openbsd7.2/include -isystem /usr/local/alpha-unknown-openbsd7.2/sys-include

checking for C compiler default output file name...                                 
configure: error: in `/u01/software/gcc/gcc-8.5.0_build-dir/alpha-unknown-openbsd7.2/libgomp':                                                                          
configure: error: C compiler cannot create executables                                                                                                                  
See `config.log' for more details.                                                  
make[2]: *** [Makefile:23756: configure-stage1-target-libgomp] Error 77                                                                                                 
make[2]: Leaving directory '/u01/software/gcc/gcc-8.5.0_build-dir'                                                                                                      
make[1]: *** [Makefile:25946: stage1-bubble] Error 2                                
make[1]: Leaving directory '/u01/software/gcc/gcc-8.5.0_build-dir'                                                                                                      
make: *** [Makefile:952: all] Error 2

*** END ***

I looked at the config.log for libgomp:

*** BEGIN ***

configure:3747: /u01/software/gcc/gcc-8.5.0_build-dir/./gcc/xgcc -B/u01/software/gcc/gcc-8.5.0_build-dir/./gcc/ -B/usr/local/alpha-unknown-openbsd7.2/bin/  
-B/usr/local/alpha-unknown-openbsd7.2/lib/ -isystem /usr/local/alpha-unknown-openbsd7.2/include -isystem /usr/local/alpha-unknown-openbsd7.2/sys-include    
-g -O2 -mieee   conftest.c  >&5
/usr/local/alpha-unknown-openbsd7.2/bin/ld: cannot find crt1.o: No such file or directory
/usr/local/alpha-unknown-openbsd7.2/bin/ld: cannot find crti.o: No such file or directory
/usr/local/alpha-unknown-openbsd7.2/bin/ld: cannot find crtn.o: No such file or directory
collect2: error: ld returned 1 exit status
configure:3751: $? = 1
configure:3788: result:
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU Offloading and Multi Processing Runtime Library"
| #define PACKAGE_TARNAME "libgomp"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU Offloading and Multi Processing Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libgomp/"
| #define PACKAGE "libgomp"
| #define VERSION "1.0"
| /* end confdefs.h.  */
|
| int
| main ()
| {
| 
|   ;
|   return 0;
| }
configure:3794: error: in `/u01/software/gcc/gcc-8.5.0_build-dir/alpha-unknown-openbsd7.2/libgomp':
configure:3797: error: C compiler cannot create executables
See `config.log' for more details.

*** END ***

If this is rudimentary and my mistakes are from lack of reading/understanding, please point me in the right direction to what I should study.
I feel like I should be able to solve this on my own, but not sure where to start.

Thanks Everyone, Thanks again Jonathan!
-M

*** END UPDATE ***

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

[Jonathan Wakely]

[-- Attachment #1: Type: text/plain, Size: 12250 bytes --]

On Sun, 22 Jan 2023, 17:38 Mark Butt, <mark@markwbutt.com> wrote:

> Hi Jonathan,
>
> Thanks for your fast reply!  My answers and comments are below.  There is
> also an update at the very bottom.
>
> >> 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?
> >
>
> No, there is no reason to be at 8.3.0 other than this was the minimum
> required.  I thought that I might have better luck getting 8.3 to work vs
> a newer version given the age of the hardware, I will, however, try a
> newer version as suggested.
>
> Would you recommend going with a particular version or just get the latest
> and greatest?
>

You should almost always use the newest for the release series you're
interested in. If you want gcc 8 then use 8.5.0, but if you just want 8 or
later, I see no reason to use an end of life, unsupported release. Use a
newer one.

>
> >> 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?
> >
>
> Yes, I assumed they would be defaulted as well.  Several postings on
> various forums/mailing lists about building with GCC on OpenBSD recommended
> setting them exclusively, but I will try
> the build again without specifying them to see if that helps.
>
> >> 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).
>
> Sorry about that,  those extra characters, "10:31:49 [22/1989]" ,  are
> coming from tmux.
>
> >
> > 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
>
> You are correct!  Another version is being discovered...
> # 1 "/usr/local/include/ansidecl.h"
>
> >
> > 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.
>
> *** BEGIN UPDATE ***
>
> I made the changes to the configure command that were suggested and the
> build moves along much further.
> It now stops with an error indicating that crt1.o cannot be found when
> building libgomp.
>

Unless you actually need OpenMP you could get past that error by
configuring with --disable-libgomp




I have a crt0.o but not a crt1.o
>
> Is that something that I can/should build?  Or is there another change I
> should make to the configure command?
> I know the documentation for the configure options for gcc indicates that
> you should keep it simple...  perhaps, that might be my problem...
>
> Again, if anyone is able to easily say what they think the problem is,
> please let me know.
> This is the latest configure command that I have used.
>
> bash-5.2# ../gcc-8.3.0/configure --disable-multilib --disable-cet
> --enable-language=c,c++ --prefix=/usr/local --disable-nls --disable-lto
>
> I also tried gcc-8.5.0 with the same result... 8.5.0 is definitely what I
> will be trying to get to work from here out.
>
> bash-5.2# ../gcc-8.5.0/configure --disable-multilib --disable-cet
> --enable-language=c,c++ --prefix=/usr/local --disable-nls --disable-lto
>
> I pulled this blurb off a support post from a forum:
>
> *** BEGIN ***
> Both crt0/crt1 do the same thing, basically do what is needed before
> calling main() (like initializing stack, setting irqs, etc.). You should
> link with one or the other but not both. They are not really libraries but
> really inline assembly code. As far as I understand, crt comes in two
> "flavours"
>
> crt1 is used on systems that support constructors and destructors
> (functions called before and after main and exit). In this case main is
> treated like a normal function call.
> crt0 is used on systems that do not support constructors/destructors.
> *** END ***
>
> The following is the message that I am getting when trying to build gcc
> 8.5.0:
>
> *** BEGIN ***
>
> Checking multilib configuration for libgomp...
>
> Configuring stage 1 in alpha-unknown-openbsd7.2/libgomp
>
>
> configure: loading cache ./config.cache
>
> checking for --enable-version-specific-runtime-libs... no
>
>
> checking for --enable-generated-files-in-srcdir... no
>
> checking build system type... alpha-unknown-openbsd7.2
>
>
> checking host system type... alpha-unknown-openbsd7.2
>
> checking target system type... alpha-unknown-openbsd7.2
>
>
> checking for a BSD-compatible install... /usr/bin/install -c
>
>
> checking whether build environment is sane... yes
>
> checking for a thread-safe mkdir -p... /usr/local/bin/mkdir -p
>
>
> checking for gawk... awk
>
> checking whether /usr/local/bin/make sets $(MAKE)... yes
>
>
> checking for alpha-unknown-openbsd7.2-gcc...
> /u01/software/gcc/gcc-8.5.0_build-dir/./gcc/xgcc
> -B/u01/software/gcc/gcc-8.5.0_build-dir/./gcc/ -B/usr/local/alpha-unknown-
> openbsd7.2/bin/ -B/usr/local/alpha-unknown-openbsd7.2/lib/ -isystem
> /usr/local/alpha-unknown-openbsd7.2/include -isystem
> /usr/local/alpha-unknown-openbsd7.2/sys-include
>
> checking for C compiler default output file name...
>
> configure: error: in
> `/u01/software/gcc/gcc-8.5.0_build-dir/alpha-unknown-openbsd7.2/libgomp':
>
> configure: error: C compiler cannot create executables
>
>
> See `config.log' for more details.
>
> make[2]: *** [Makefile:23756: configure-stage1-target-libgomp] Error 77
>
>
> make[2]: Leaving directory '/u01/software/gcc/gcc-8.5.0_build-dir'
>
>
> make[1]: *** [Makefile:25946: stage1-bubble] Error 2
>
> make[1]: Leaving directory '/u01/software/gcc/gcc-8.5.0_build-dir'
>
>
> make: *** [Makefile:952: all] Error 2
>
> *** END ***
>
> I looked at the config.log for libgomp:
>
> *** BEGIN ***
>
> configure:3747: /u01/software/gcc/gcc-8.5.0_build-dir/./gcc/xgcc
> -B/u01/software/gcc/gcc-8.5.0_build-dir/./gcc/
> -B/usr/local/alpha-unknown-openbsd7.2/bin/
> -B/usr/local/alpha-unknown-openbsd7.2/lib/ -isystem
> /usr/local/alpha-unknown-openbsd7.2/include -isystem
> /usr/local/alpha-unknown-openbsd7.2/sys-include
> -g -O2 -mieee   conftest.c  >&5
> /usr/local/alpha-unknown-openbsd7.2/bin/ld: cannot find crt1.o: No such
> file or directory
> /usr/local/alpha-unknown-openbsd7.2/bin/ld: cannot find crti.o: No such
> file or directory
> /usr/local/alpha-unknown-openbsd7.2/bin/ld: cannot find crtn.o: No such
> file or directory
> collect2: error: ld returned 1 exit status
> configure:3751: $? = 1
> configure:3788: result:
> configure: failed program was:
> | /* confdefs.h */
> | #define PACKAGE_NAME "GNU Offloading and Multi Processing Runtime
> Library"
> | #define PACKAGE_TARNAME "libgomp"
> | #define PACKAGE_VERSION "1.0"
> | #define PACKAGE_STRING "GNU Offloading and Multi Processing Runtime
> Library 1.0"
> | #define PACKAGE_BUGREPORT ""
> | #define PACKAGE_URL "http://www.gnu.org/software/libgomp/"
> | #define PACKAGE "libgomp"
> | #define VERSION "1.0"
> | /* end confdefs.h.  */
> |
> | int
> | main ()
> | {
> |
> |   ;
> |   return 0;
> | }
> configure:3794: error: in
> `/u01/software/gcc/gcc-8.5.0_build-dir/alpha-unknown-openbsd7.2/libgomp':
> configure:3797: error: C compiler cannot create executables
> See `config.log' for more details.
>
> *** END ***
>
> If this is rudimentary and my mistakes are from lack of
> reading/understanding, please point me in the right direction to what I
> should study.
> I feel like I should be able to solve this on my own, but not sure where
> to start.
>
> Thanks Everyone, Thanks again Jonathan!
> -M
>
> *** END UPDATE ***
>

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

[Jeff Law]

On 1/22/23 10:37, Mark Butt wrote:

> 
> No, there is no reason to be at 8.3.0 other than this was the minimum required.  I thought that I might have better luck getting 8.3 to work vs
> a newer version given the age of the hardware, I will, however, try a newer version as suggested.
> 
> Would you recommend going with a particular version or just get the latest and greatest?
I'd just go with the latest release.    You could go with one of the 
weekly development snapshots, but that may introduce problems you don't 
want to deal with.

FWIW, I do 3-stage bootstraps of the alpha port in my tester once a week 
(using qemu).  This includes binutils, gcc, glibc and a kernel build 
using the tip-of-trunk sources for each component.  It's also a linux 
environment, not a BSD environment.

While that work isn't directly applicable to you, it does provide some 
degree of reassurance that the alpha port basically works.  Any notable 
issues are likely BSD specific.

http://law-sandy.freeddns.org:8080/job/alpha-linux-gnu/

jeff

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

[Segher Boessenkool]

On Sun, Jan 22, 2023 at 11:40:46AM -0700, Jeff Law via Gcc-help wrote:
> On 1/22/23 10:37, Mark Butt wrote:
> >No, there is no reason to be at 8.3.0 other than this was the minimum 
> >required.  I thought that I might have better luck getting 8.3 to work vs
> >a newer version given the age of the hardware, I will, however, try a 
> >newer version as suggested.
> >
> >Would you recommend going with a particular version or just get the latest 
> >and greatest?
> I'd just go with the latest release.    You could go with one of the 
> weekly development snapshots, but that may introduce problems you don't 
> want to deal with.

Yes.  And some things that have been fixed in the newest release series
have not been fixed in older ones, for various reasons (too dangerous,
too difficult, compared with expected benefit).  And nothing is fixed
anymore in release series that have reached end of life of course (so
everything before GCC 10, currently).

If you have no particular reason to want something older (or newer), use
the latest released version?  That is GCC 12.2 now.  The main reason to
use an older release series is if you already were using it :-)


Segher

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

[Mark Butt]

Thanks Segher!
I tried 12.2 a few days ago but I am getting errors that I think are about the compiler that comes with OpenBSD being too old to build 12.2.
I haven't given up yet, but I think I need to reinstall OpenBSD for sanity sake to make sure I haven't messed something up over the weeks of trying to figure it out.
This morning I found a great article about how to build gcc for an Alpha emulated VM running Tru64.  I am going to try to roughly translate what I can in to OpenBSD to see if that helps.
I do have Tru64 on another set of SCSI disks so I might give it a go... just to see if the steps work for a stock Tru64 5.1b.

When I started this small project I didn't think it would much trouble at all.  I had assumed modern OpenBSD would be similar to using something like modern AIX which supports a lot of GNU-linked products very well... either that was a poor assumption on my part, I am doing something wrong, the Alpha architecture (yes, ancient I know) or a combination of several of those.

When I do have a working GCC installation I will report back with the steps required to get there.  Incase anyone else happens to feel the need to compile GCC on an old Alpha.
I am thinking I am getting close...  GCC is building it seems, but encounters errors during the subsequent steps.  It complains that it cannot create executables. 

I did notice that the configure script is detecting the host as:  alpha-unknown-openbsd7.2
Does anyone know if that looks right or if I should be manually specifying the host type?

Again, thanks all for the help and taking the time to respond.
-M

----- Original Message -----
From: "Segher Boessenkool" <segher@kernel.crashing.org>
To: "Jeff Law" <jeffreyalaw@gmail.com>
Cc: "Mark Butt" <mark@markwbutt.com>, "Jonathan Wakely" <jwakely.gcc@gmail.com>, "gcc-help" <gcc-help@gcc.gnu.org>
Sent: Friday, January 27, 2023 2:28:45 PM
Subject: Re: Building and install GCC 8.3.0, OpenBSD 7.2 on DEC Alpha EV5

On Sun, Jan 22, 2023 at 11:40:46AM -0700, Jeff Law via Gcc-help wrote:
> On 1/22/23 10:37, Mark Butt wrote:
> >No, there is no reason to be at 8.3.0 other than this was the minimum 
> >required.  I thought that I might have better luck getting 8.3 to work vs
> >a newer version given the age of the hardware, I will, however, try a 
> >newer version as suggested.
> >
> >Would you recommend going with a particular version or just get the latest 
> >and greatest?
> I'd just go with the latest release.    You could go with one of the 
> weekly development snapshots, but that may introduce problems you don't 
> want to deal with.

Yes.  And some things that have been fixed in the newest release series
have not been fixed in older ones, for various reasons (too dangerous,
too difficult, compared with expected benefit).  And nothing is fixed
anymore in release series that have reached end of life of course (so
everything before GCC 10, currently).

If you have no particular reason to want something older (or newer), use
the latest released version?  That is GCC 12.2 now.  The main reason to
use an older release series is if you already were using it :-)


Segher

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

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 2027 bytes --]

Hi Mark,

Mark Butt <mark@markwbutt.com> writes:

> Thanks Segher!
> I tried 12.2 a few days ago but I am getting errors that I think are about the
> compiler that comes with OpenBSD being too old to build 12.2.
> I haven't given up yet, but I think I need to reinstall OpenBSD for sanity sake
> to make sure I haven't messed something up over the weeks of trying to figure
> it out.

OpenBSD 7.2 seems to includes GCC 4.2.1 and Clang 13.  The former is too
old, however, the latter should work fine.  Try to configure with
CC=clang CXX=clang++ or something like that.

> This morning I found a great article about how to build gcc for an Alpha
> emulated VM running Tru64.  I am going to try to roughly translate what I can
> in to OpenBSD to see if that helps.
> I do have Tru64 on another set of SCSI disks so I might give it a go... just to
> see if the steps work for a stock Tru64 5.1b.
>
> When I started this small project I didn't think it would much trouble at all.
> I had assumed modern OpenBSD would be similar to using something like modern
> AIX which supports a lot of GNU-linked products very well... either that was a
> poor assumption on my part, I am doing something wrong, the Alpha architecture
> (yes, ancient I know) or a combination of several of those.
>
> When I do have a working GCC installation I will report back with the steps
> required to get there.  Incase anyone else happens to feel the need to compile
> GCC on an old Alpha.
> I am thinking I am getting close...  GCC is building it seems, but encounters
> errors during the subsequent steps.  It complains that it cannot create
> executables.
>
> I did notice that the configure script is detecting the host as:  alpha-unknown-openbsd7.2
> Does anyone know if that looks right or if I should be manually specifying the host type?

Assuming this is an Alpha host, that seems right.

> Again, thanks all for the help and taking the time to respond.
> -M

Have a nice night.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

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

[Jonathan Wakely]

[-- Attachment #1: Type: text/plain, Size: 714 bytes --]

On Fri, 27 Jan 2023, 19:21 Mark Butt, <mark@markwbutt.com> wrote:

>
> When I started this small project I didn't think it would much trouble at
> all.  I had assumed modern OpenBSD would be similar to using something like
> modern AIX which supports a lot of GNU-linked products very well... either
> that was a poor assumption on my part, I am doing something wrong, the
> Alpha architecture (yes, ancient I know) or a combination of several of
> those.
>


AIX has people actively testing GCC regularly, and reporting bugs and
contributing patches. Nobody does that for openbsd so it's unsurprising
that it bitrots, especially for the combination of alpha and openbsd which
will be even less frequently tested.

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

[Segher Boessenkool]

On Fri, Jan 27, 2023 at 03:51:12PM -0330, Mark Butt wrote:
> I tried 12.2 a few days ago but I am getting errors that I think are about the compiler that comes with OpenBSD being too old to build 12.2.

A C++11 compiler is required:
  ISO C++11 compiler
  Necessary to bootstrap GCC.  GCC 4.8.3 or newer has sufficient
  support for used C++11 features, with earlier GCC versions you
  might run into implementation bugs.

> I did notice that the configure script is detecting the host as:  alpha-unknown-openbsd7.2
> Does anyone know if that looks right or if I should be manually specifying the host type?

That isn't the host.  The target triple is cpu-vendor-os.  "unknown"
is pretty normal here, and doesn't usually make a difference.  If you
do use something here you will have to use the same thing for all tools,
so it is easier to just use the detected thing usually.


Segher

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

[Christer Solskogen]

On 20.01.2023 16:40, Mark Butt 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.
> 


IIRC OpenBSD doesn't have any prebuilt packages for alpha, but you 
should be able to install gcc by using ports, which does most of the 
heavy lifting for you. In case your application *really* needs 8.x, the 
ports system have that too.

-- 
chs