reproduce-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #61240] gcc 10.2.1-6 cannot compile gcc 10.2.0; related: unwind, ic


From: Boud Roukema
Subject: [bug #61240] gcc 10.2.1-6 cannot compile gcc 10.2.0; related: unwind, iconv
Date: Sat, 9 Oct 2021 18:51:56 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Update of bug #61240 (project reproduce):

             Open/Closed:                  Closed => Open                   

    _______________________________________________________

Follow-up Comment #5:

I'm restoring this to 'open' status. The workaround which is now in commit
775fc036e0 works on a few systems, but it's not a serious solution to the bug.
Advice from someone or some people who understand the gcc configure/compile
system properly makes more sense for getting a real fix.

Moreover, it seems that the current workaround (in commit 775fc036e0) causes a
different sort of unwind-related fatal error (an "internal compiler error:
segmentation fault") on aarch64 \approx arm64.

On Debian bullseye, gcc 10.2.1-6 compiling 10.2.0 has this bug independently
of Maneage, so it's unlikely to be the fault of the Maneage setup. The bug
also occurs for 10.2.1-6 compiling 11.2.0.

I found that removing _--disable-multiarch_ seems to provide a neater solution
to this bug than the workaround symlinks.

On the #gcc channel at irc.oftc.net I got helpful feedback from Pinskia. It
seems that disabling multiarch on Debian systems will generally be likely to
cause problems, because the Debian include and library directory system for
gcc is set up to be multiarch. This is consistent with what I found with
libunwind.

As before, I don't think that trying to force users to remove _libunwind-dev_
from their system (especially since we don't want to force them to have root
access) is an acceptable option. Unless there is a known problem with removing
_--disable-multiarch_ , then I think that removing _--disable-multiarch_ from
the gcc list of compile options would make sense as a better solution than the
current symlink solution.

However, please wait a bit while I test this on aarch64...


    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/bugs/?61240>

_______________________________________________
  Message sent via Savannah
  https://savannah.nongnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]