From: "H.J. Lu" <hjl.tools@gmail.com>
To: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Cc: Joseph Myers <joseph@codesourcery.com>,
GNU C Library <libc-alpha@sourceware.org>
Subject: Re: [PATCH] Configure GCC with --enable-initfini-array [BZ #27945]
Date: Fri, 5 Nov 2021 15:09:14 -0700 [thread overview]
Message-ID: <CAMe9rOrJdNmduoBZSu+ba39NJ+eevxvdFbzd_Bh2T=V+GWN+9A@mail.gmail.com> (raw)
In-Reply-To: <53e17f0c-b76f-d256-8584-8677926166ab@linaro.org>
On Fri, Nov 5, 2021 at 12:45 PM Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
>
>
>
> On 09/06/2021 17:44, Joseph Myers wrote:
> > On Wed, 9 Jun 2021, Adhemerval Zanella via Libc-alpha wrote:
> >
> >> On 09/06/2021 15:02, Joseph Myers wrote:
> >>> On Wed, 9 Jun 2021, H.J. Lu via Libc-alpha wrote:
> >>>
> >>>> I disagree. The behavior of the cross compiler should be as close to the native
> >>>> Linux system compiler, not other versions of cross compilers, as possible.
> >>>
> >>> But fixing that was the point of your GCC patch. I don't think working
> >>> around deficiencies in previous versions of GCC, that aren't necessary to
> >>> work around for building glibc, is within scope for build-many-glibcs.py;
> >>> it's enough that the bug (cross compiler different from native) was fixed
> >>> in the logically correct place (in GCC, for future GCC releases).
> >>
> >> But this also does not have any really drawback, correct?
> >
> > It's one more thing to track when to remove when the minimum GCC version
> > for building glibc increases. (We have such a comment on the use of
> > --disable-libcilkrts. We ought to have one on the use of
> > --disable-libmpx. If we used --enable-initfini-array, that should have
> > such a comment as well.)
> >
>
> So I stumbled across this issues while testing powerpc64le with the
> build-many-glibcs built gcc with lld, which does not support .ctors
> (it just ignores the sections instead of converting it on .init_array).
>
> I agree with H.J that is unfortunate that gcc has the issue and
> although it does not prevent to work against ld.bfd, it might prevent
> glibc to be built properly with other linkers.
>
> So I think it would be good to have such patch upstream with.
I am checking in this patch now.
Thanks.
--
H.J.
next prev parent reply other threads:[~2021-11-05 22:09 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-09 12:29 H.J. Lu
2021-06-09 16:07 ` Joseph Myers
2021-06-09 17:46 ` H.J. Lu
2021-06-09 18:02 ` Joseph Myers
2021-06-09 18:13 ` Adhemerval Zanella
2021-06-09 19:01 ` H.J. Lu
2021-06-09 20:52 ` Joseph Myers
2021-06-09 20:44 ` Joseph Myers
2021-11-05 19:45 ` Adhemerval Zanella
2021-11-05 22:09 ` H.J. Lu [this message]
2021-11-08 15:01 ` Joseph Myers
2021-11-08 15:51 ` H.J. Lu
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='CAMe9rOrJdNmduoBZSu+ba39NJ+eevxvdFbzd_Bh2T=V+GWN+9A@mail.gmail.com' \
--to=hjl.tools@gmail.com \
--cc=adhemerval.zanella@linaro.org \
--cc=joseph@codesourcery.com \
--cc=libc-alpha@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).