From: Jonathan Wakely <jwakely.gcc@gmail.com>
To: Mark Butt <mark@markwbutt.com>
Cc: gcc-help <gcc-help@gcc.gnu.org>
Subject: Re: Building and install GCC 8.3.0, OpenBSD 7.2 on DEC Alpha EV5
Date: Sun, 22 Jan 2023 18:36:02 +0000 [thread overview]
Message-ID: <CAH6eHdRNw5HZw8Coz=Cf1eWAty2StJ4wLV_mT71883OrV=KdTA@mail.gmail.com> (raw)
In-Reply-To: <1069636641.353816.1674409053357.JavaMail.zimbra@markwbutt.com>
[-- 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 ***
>
next prev parent reply other threads:[~2023-01-22 18:36 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-20 15:40 Mark Butt
2023-01-20 17:30 ` Jonathan Wakely
2023-01-22 17:37 ` Mark Butt
2023-01-22 18:36 ` Jonathan Wakely [this message]
2023-01-22 18:40 ` Jeff Law
2023-01-27 17:58 ` Segher Boessenkool
2023-01-27 19:21 ` Mark Butt
2023-01-27 19:25 ` Arsen Arsenović
2023-01-27 20:17 ` Jonathan Wakely
2023-01-27 21:14 ` Segher Boessenkool
2023-01-27 19:41 ` Christer Solskogen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAH6eHdRNw5HZw8Coz=Cf1eWAty2StJ4wLV_mT71883OrV=KdTA@mail.gmail.com' \
--to=jwakely.gcc@gmail.com \
--cc=gcc-help@gcc.gnu.org \
--cc=mark@markwbutt.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).