public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
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

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