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

[Boud Roukema]

Follow-up Comment #3, bug #61240 (project reproduce):

EXPLANATION: Seems like this is now solved. Here's a difference between the
two systems:

system B = with the bug:

dpkg -l |grep unwind
ii  libunwind-dev:amd64                           1.3.2-2                     
   amd64        library to determine the call-chain of a program -
development
ii  libunwind8:amd64                              1.3.2-2                     
   amd64        library to determine the call-chain of a program - runtime


system OK = without the bug:

dpkg -l |grep unwind


Installing _libunwind-dev_ (libunwind8 is a dependence of libunwind-dev) into
system OK (which previously did not show the buggy behaviour) caused the bug
to occur; removing it again caused the bug to disappear again. So the
bug/feature is that gcc will use the system-level _libunwind_ by default. It
presumes that you want it to be used, since otherwise you wouldn't have
installed it. :P  But in Maneage, the user shouldn't need root privileges, so
the assumption is invalid.

What is less clear is whether the problem is only in the header files, or in
both the header files and the compiled binary libraries.

PROPOSED SOLUTION: See
https://codeberg.org/boud/maneage_dev/commit/8221126409b47d224ee4990b739c1deb765228a2
for a proposed fix.

This hack sym-links the generic file _libgcc/unwind-generic.h_ to the two
directories in which a file #includes _"unwind.h"_ or _<unwind.h>_ , so that
the gcc compilation system uses this gcc source file instead of searching for
a system-level one.

This appears to solve the bug.

A minor bonus is included in the commit. While wondering if _ncurses_ was
involved, I noticed that on the system with the bug, many of the library files
are created with the executable bit set, and the default 'ls' command is
aliased to use the '-F' option.  Together, these could potentially lead to
errors in command pipes that assume that 'ls' yields undecorated text without
the addition of asterisks or escape characters for bold or coloured fonts.
This bonus adds the command 'unalias ls' just before invoking 'ls', to reduce
the probability of getting an unwanted asterisk or other annoying
non-alphanumeric character in a string. A backup of '||true' is used in case
the host system shell does not have 'alias' (I don't know if 'alias' is
required in posix, though we probably should check that 'unalias' cannot do
something bad).


OTHER POSSIBLE SOLUTIONS:

* There's a gcc-10.2.0 configure option _--with-system-unwind_ that can be set
in gcc-10.2.0/configure, but this does not have a 'no' or disable option, and
does not seem to anything significant for the _amd64_ (x86-64) architecture,
so its behaviour does not match what we in Maneage might expect from its name
in the context of this bug. Experimentally, setting this parameter doesn't
seem to solve the bug either. (In this sense, this could be proposed as a GCC
usability bug if we were sure enough; see 'MORE READING' below.)

* Check if _libunwind-dev_ (with slightly different names in non-Debian
systems) exists in the system files, warn the reader, and strongly recommend
that the system-level files be removed. This solution would violate the
principle of a Maneage package only needing user-level access to the system if
we included a 'sudo' type command, and leaving it as a human-readable
recommendation would defeat the point of having an automated user-level
script.


MORE READING:
The old discussion of the bug/feature here seems to be the most useful:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14925 ; though
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78251 is more recent and suggests
that maybe something should be proposed upstream to gcc, though I'm not sure.


BUG STATUS:
Feel to close this once either commit 8221126 or a better solution has been
merged into Maneage.


    _______________________________________________________

Reply to this item at:

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

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