public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: YunQiang Su <wzssyqa@gmail.com>
To: Xi Ruoyao <xry111@xry111.site>
Cc: YunQiang Su <yunqiang.su@cipunited.com>,
	 apinski--- via Gcc-patches <gcc-patches@gcc.gnu.org>,
	Matthias Klose <doko@debian.org>,
	 "Maciej W. Rozycki" <macro@orcam.me.uk>
Subject: Re: [PATCH] MIPS: fix building on multiarch platform
Date: Fri, 23 Sep 2022 20:35:19 +0800	[thread overview]
Message-ID: <CAKcpw6UxL0iEPapZkWY8Q5ZHynyofszcAdTAr0qnm-ztocTv1Q@mail.gmail.com> (raw)
In-Reply-To: <c8f6663967d170dd51e2bc33481618e1beffb313.camel@xry111.site>

Xi Ruoyao via Gcc-patches <gcc-patches@gcc.gnu.org> 于2022年9月21日周三 23:09写道:
>
> On Wed, 2022-09-21 at 11:31 +0000, YunQiang Su wrote:
> > On platforms that support multiarch, such as Debian,
> > the filesystem hierarchy doesn't fellow the old Irix style:
> >         lib & lib/<multiarch> for native
> >         lib64 for N64 on N32/O32 systems
> >         lib32 for N32 on N64/O32 systems
> >         libo32 for O32 on N64/N32 systems
> >
> > Thus we cannot
> >  #define STANDARD_STARTFILE_PREFIX_1
> >  #define STANDARD_STARTFILE_PREFIX_2
> > on N32 or N64 systems, else collect2 won't look for libraries
> > on /lib/<multiarch>.
> >
> > gcc/ChangeLog:
> >         * configure.ac: AC_DEFINE(ENABLE_MULTIARCH, 1)
> >         * configure: Regenerated.
> >         * config.in: Regenerated.
> >         * config/mips/mips.h: don't define STANDARD_STARTFILE_PREFIX_1
> >           if ENABLE_MULTIARCH is defined.
> >         * config/mips/t-linux64: define correct multiarch path when
> >           multiarch is enabled.
> > ---
> >  gcc/config.in             |  6 ++++++
> >  gcc/config/mips/mips.h    |  2 ++
> >  gcc/config/mips/t-linux64 | 21 ++++++++++++++++++++-
> >  gcc/configure             |  4 ++++
> >  gcc/configure.ac          |  3 +++
> >  5 files changed, 35 insertions(+), 1 deletion(-)
> >
> > diff --git a/gcc/config.in b/gcc/config.in
> > index 6ac17be189e..b2ce6361327 100644
> > --- a/gcc/config.in
> > +++ b/gcc/config.in
> > @@ -2312,6 +2312,12 @@
> >  #endif
> >
> >
> > +/* Specify if mutliarch is enabled. */
> > +#ifndef USED_FOR_TARGET
> > +#undef ENABLE_MULTIARCH
> > +#endif
> > +
> > +
> >  /* The size of `dev_t', as computed by sizeof. */
> >  #ifndef USED_FOR_TARGET
> >  #undef SIZEOF_DEV_T
> > diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h
> > index 74b6e11aabb..fe7f5b274b9 100644
> > --- a/gcc/config/mips/mips.h
> > +++ b/gcc/config/mips/mips.h
> > @@ -3427,6 +3427,7 @@ struct GTY(())  machine_function {
> >
> >  /* If we are *not* using multilibs and the default ABI is not ABI_32
> > we
> >     need to change these from /lib and /usr/lib.  */
> > +#ifndef ENABLE_MULTIARCH
> >  #if MIPS_ABI_DEFAULT == ABI_N32
> >  #define STANDARD_STARTFILE_PREFIX_1 "/lib32/"
> >  #define STANDARD_STARTFILE_PREFIX_2 "/usr/lib32/"
> > @@ -3434,6 +3435,7 @@ struct GTY(())  machine_function {
> >  #define STANDARD_STARTFILE_PREFIX_1 "/lib64/"
> >  #define STANDARD_STARTFILE_PREFIX_2 "/usr/lib64/"
> >  #endif
> > +#endif
>
> Should we just remove STANDARD_STARTFILE_PREFIX_{1,2} unconditionally?
> I just took a look and the only Linux ports using these macros are MIPS
> and LoongArch (borrowed these macros from MIPS, I guess).  On a non-
> multilib distro /usr/lib is likely used, and on multilib distros the
> macros are not used anyway.
>

Yes. As Maciej pointed, the old mips style for MIPS filesystem
hierarchy is quite quirk.
This is from Irix.
It does make lots of trouble for distribution makers to support
multilib for mips64,
since

On non-multilib distributions, like OpenWrt for mips64, lib is used,
and lib64 is a symlink to lib.
While on multilib-enabled ports, like Fedora, the old Irix style is used.

So, we should keep the code.

> >  /* Load store bonding is not supported by micromips and fix_24k.  The
> >     performance can be degraded for those targets.  Hence, do not bond for
> > diff --git a/gcc/config/mips/t-linux64 b/gcc/config/mips/t-linux64
> > index 2fdd8e00407..37d176ea309 100644
> > --- a/gcc/config/mips/t-linux64
> > +++ b/gcc/config/mips/t-linux64
> > @@ -20,7 +20,26 @@ MULTILIB_OPTIONS = mabi=n32/mabi=32/mabi=64
> >  MULTILIB_DIRNAMES = n32 32 64
> >  MIPS_EL = $(if $(filter %el, $(firstword $(subst -, ,$(target)))),el)
> >  MIPS_SOFT = $(if $(strip $(filter MASK_SOFT_FLOAT_ABI, $(target_cpu_default)) $(filter soft, $(with_float))),soft)
> > -MULTILIB_OSDIRNAMES = \
> > +ifeq (yes,$(enable_multiarch))
> > +  ifneq (,$(findstring gnuabi64,$(target)))
> > +    MULTILIB_OSDIRNAMES = \
> > +       ../lib32$(call if_multiarch,:mips64$(MIPS_EL)-linux-gnuabin32$(MIPS_SOFT)) \
> > +       ../libo32$(call if_multiarch,:mips$(MIPS_EL)-linux-gnu$(MIPS_SOFT)) \
> > +       ../lib$(call if_multiarch,:mips64$(MIPS_EL)-linux-gnuabi64$(MIPS_SOFT))
> > +  else ifneq (,$(findstring gnuabin32,$(target)))
> > +    MULTILIB_OSDIRNAMES = \
> > +       ../lib$(call if_multiarch,:mips64$(MIPS_EL)-linux-gnuabin32$(MIPS_SOFT)) \
> > +       ../libo32$(call if_multiarch,:mips$(MIPS_EL)-linux-gnu$(MIPS_SOFT)) \
> > +       ../lib64$(call if_multiarch,:mips64$(MIPS_EL)-linux-gnuabi64$(MIPS_SOFT))
> > +  else
> > +    MULTILIB_OSDIRNAMES = \
> > +       ../lib32$(call if_multiarch,:mips64$(MIPS_EL)-linux-gnuabin32$(MIPS_SOFT)) \
> > +       ../lib$(call if_multiarch,:mips$(MIPS_EL)-linux-gnu$(MIPS_SOFT)) \
> > +       ../lib64$(call if_multiarch,:mips64$(MIPS_EL)-linux-gnuabi64$(MIPS_SOFT))
> > +  endif
> > +else
> > +  MULTILIB_OSDIRNAMES = \
> >         ../lib32$(call if_multiarch,:mips64$(MIPS_EL)-linux-gnuabin32$(MIPS_SOFT)) \
> >         ../lib$(call if_multiarch,:mips$(MIPS_EL)-linux-gnu$(MIPS_SOFT)) \
> >         ../lib64$(call if_multiarch,:mips64$(MIPS_EL)-linux-gnuabi64$(MIPS_SOFT))
> > +endif
>
> Hmm, I don't think we should touch this.  The default setting of
> MULTILIB_OSDIRNAMES is simply not designed to suit all distros (at least
> for now) and many distros are patching it.  Change it here won't give
> the distro maintainers any benefit, but will force them to rebase the
> patch.
>

It is not for distro: this patch try to fix the build gcc from source on Debian.
Aka, currently, gcc ftbfs on Debian MIPS with simple: ./configure && make.

> If we want to make the distro maintainers' life easier we'd make a
> global decision (for all ports) and maybe add some configuration options
> for MULTILIB_OSDIRNAMES.
>
>
> --
> Xi Ruoyao <xry111@xry111.site>
> School of Aerospace Science and Technology, Xidian University



-- 
YunQiang Su

      parent reply	other threads:[~2022-09-23 12:35 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-21 11:31 YunQiang Su
2022-09-21 15:08 ` Xi Ruoyao
2022-09-21 16:03   ` Maciej W. Rozycki
2022-09-23 12:35   ` YunQiang Su [this message]

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=CAKcpw6UxL0iEPapZkWY8Q5ZHynyofszcAdTAr0qnm-ztocTv1Q@mail.gmail.com \
    --to=wzssyqa@gmail.com \
    --cc=doko@debian.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=macro@orcam.me.uk \
    --cc=xry111@xry111.site \
    --cc=yunqiang.su@cipunited.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).