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: Tue, 28 Sep 2021 18:27:15 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

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

                 Summary: gcc 10.2.1-6 cannot compile gcc 10.2.0; related:
unwind, iconv
                 Project: Maneage
            Submitted by: boud
            Submitted on: Tue 28 Sep 2021 10:27:13 PM UTC
                Category: None
                Severity: 5 - Blocker
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

Maneage 3a1b96766 [1] fails to build gcc in the configure stage on a
Debian/bullseye (stable) system. Ironically, this means that gcc-10.2.1-6 has
a bug in trying to compile gcc-10.2.0. :P

The bug appears to a known problem related to the unwind library and the
choice of the appropriate iconv library (that of libc6 or that of maneage).
See [2] and [3] for what appear to be the main GNU discussions, and [4] for a
Darwin/xnu discussion (which leads back to [2]). The most meaningful solution
appears to be [5]:


To fix this, the -liconv gettext adds should be immediately preceded by
a -L citing its location, so that other -L's introduced by other
packages don't trigger this (which would cause gdb, too, to link against
/usr/lib/libiconv.dylib and all would be well).


So as I understand it, gcc people see this as a system-level inconsistency
problem (we have a system within a system), not a gcc bug. I'm not quite sure
how we could or should insert a -L option into the gcc compilation rules at
_basic.mk_ or whether this would be the best way to do things consistently.
While waiting for the pending and ambitious GNU C library task
https://savannah.nongnu.org/task/?15390 we'll need some sort of hack,
preferably that one that is the least likely to break anything or worsen
reproducibility.


Full error log: [0]

I tried switching the reproduce/software/conf/* files to gcc-10.3.0 from
upstream. Unsurprisingly, the same error occurs. 

[0] https://cosmo.torun.pl/~boud/log.20210928.config.5.gcc.bug.gz

[1]
http://git.maneage.org/project.git/commit/?id=3a1b96766c9d5c9845f8baacbbf88978db9c3f49

[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78251

[3] https://lists.gnu.org/archive/html/bug-gettext/2021-02/msg00000.html

[4] https://trac.macports.org/ticket/57198

[5] https://lists.gnu.org/archive/html/bug-gettext/2021-02/msg00001.html





    _______________________________________________________

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]