From: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
To: Nemo Nusquam via Gdb <gdb@sourceware.org>
Cc: Nemo Nusquam <cym224@gmail.com>
Subject: Re: Unable to build GDB 13.1 on Solaris 11.3 Sparc
Date: Wed, 08 Mar 2023 23:19:26 +0100 [thread overview]
Message-ID: <yddpm9i7uoh.fsf@CeBiTec.Uni-Bielefeld.DE> (raw)
In-Reply-To: <f1912345-842c-80b8-7dd0-838bdd5f2746@gmail.com> (Nemo Nusquam via Gdb's message of "Wed, 8 Mar 2023 16:33:48 -0500")
Nemo Nusquam via Gdb <gdb@sourceware.org> writes:
> I am trying (and failing) to build GDB 13.1 on Solaris 11.3 Sparc.
>
> Here is my configuration script.
>
> CXXFLAGS='-g3 -O0' \
> CFLAGS='-g3 -O0' \
Why? Do you want/need to debug the resulting gdb itself? Otherwise,
just leave the defaults (-g -O2).
> NM=/usr/bin/gnm \
> SHELL=/usr/bin/bash \
Probably rather CONFIG_SHELL. Btw., it's often best to have
/usr/gnu/bin before /usr/bin in $PATH: configure scripts sometimes
assume the GNU tools and fail in weird ways with the native ones.
> AR=/usr/bin/gar \
> AS=/usr/bin/as \
Unnecessary for gdb. Even when building gcc, use --with-as=/usr/bin/as
--without-gnu-as as documented in the installation guide. Relying on
$PATH is risky and fragile.
> CC=/home/build/gcc/git/bin/gcc \
> CXX=/home/build/gcc/git/bin/g++ \
I suppose this is a 32-bit-default gcc (i.e. configured for
sparc-sun-solaris2.11, not sparcv9-sun-solaris2.11)? Any reason not to
use the bundled gcc 7.3.0? That one is 64-bit-default.
> ../configure \
> --with-mpc=/usr/local \
> --with-gmp=/usr/local \
> --with-mpfr=/usr/local \
> --enable-64-bit-bfd \
> --enable-tui \
> --with-curses \
> --disable-bootstrap \
This is gcc only, thus unnecessary for a gdb build.
> --disable-binutils \
> --disable-ld \
> --disable-gprof \
> --disable-gprofng \
> --disable-gold \
> --disable-gas \
> --disable-sim
If you're building from the gdb 13.1 tarball, you can omit those. Btw.,
--disable-binutils is harmful: gdb depends on libbfd and won't link
without, as you've discovered.
> (Some flags taken from https://sourceware.org/gdb/wiki/BuildingNatively .)
In general, please start with the bare minimum of configure flags (like
the --with-* stuff). Unless you known 200% what you're doing,
additional flags usually cause more harm then anything.
> The makefile creates ./gdb inside the build directory and then stops as
> follows:
>
> checking for libgmp... no
> configure: error: GMP is missing or unusable
> gmake[1]: *** [Makefile:11447: configure-gdb] Error 1
> gmake[1]: Leaving directory '/home/build/opt/gdb-13.1/bld'
You can find the exact errors in gdb/config.log. Consulting that is
usually necessary to determine what exactly went wrong.
> I have libgmp (and building gcc 13 uses it) in /usr/local/lib:
>
> /usr/local/lib/libgmp.a: current ar archive, 32-bit symbol table
> /usr/local/lib/libgmp.la: commands text
> /usr/local/lib/libgmp.so: ELF 64-bit MSB dynamic lib SPARCV9 Version
> 1, UltraSPARC3 Extensions Required, dynamically linked, not stripped, no
> debugging information available
> /usr/local/lib/libgmp.so.10: ELF 64-bit MSB dynamic lib SPARCV9 Version
> 1, UltraSPARC3 Extensions Required, dynamically linked, not stripped, no
> debugging information available
> /usr/local/lib/libgmp.so.10.4.1: ELF 64-bit MSB dynamic lib SPARCV9
> Version 1, UltraSPARC3 Extensions Required, dynamically linked, not
> stripped, no debugging information available
>
> Now I note that the Makefile is compiling to 32-bit objects but I have a
> 32-bit libgmp.a. (I tried adding "-m64" but that caused other problems.)
Such as? Please include the details so we can help.
> I am stumped. How do I proceed?
Since your libgmp is 64-bit, you need to ensure a 64-bit build. You can
achieve this either by using a 64-bit-default gcc/g++ or adding -m64 to
CC/CXX. Adding it to CFLAGS/CXXFLAGS often doesn't work as expected,
unfortunately.
You should also add --build sparcv9-sun-solaris2.11 to the configure
flags. config.guess has been badly messed with on Solaris in recent
times and misdetects the 64-bit triple. I've given up fighting the
upstream chaos here and usually specify the correct triple explicitly.
Hope this helps.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
next prev parent reply other threads:[~2023-03-08 22:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-08 21:33 Nemo Nusquam
2023-03-08 22:19 ` Rainer Orth [this message]
2023-03-09 8:08 ` Andreas Schwab
2023-03-09 10:37 ` Rainer Orth
2023-03-09 18:45 ` Nemo Nusquam
2023-03-08 22:43 ` Andrew Pinski
2023-03-09 18:20 ` Nemo Nusquam
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=yddpm9i7uoh.fsf@CeBiTec.Uni-Bielefeld.DE \
--to=ro@cebitec.uni-bielefeld.de \
--cc=cym224@gmail.com \
--cc=gdb@sourceware.org \
/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).