Thanks a lot for these confirmations Boud :-).

Since the versions of Coreutils and GCC have been updated as part of task #16103 (Software update 2022-1) and the note on "vampires" has been added as part of bug #61336 (Aarch64 = arm64 fixes); I am closing this task.

> have you tried updating Maneage's GCC to version 11.2?

As I said in comment #5:

> The bug also occurs for 10.2.1-6 compiling 11.2.0.

So 'yes'. In other words, on x86_64, the bug also occurs with --disable-multiarch for system-level 10.2.1-6 compiling 11.2.0 source. Andrew Pinski in the #gcc irc discussion considered this to not be a gcc bug - the user is expected to understand that on Debian there's no point disabling multiarch when compiling with the Debian gcc.

Do we have any strong reasons for disabling multiarch? (Apart from the obvious one that reproducibility is only intended on the single machine being used, so multiarch is not needed, but that's an argument against not needing multiarch, it's not an argument to disable multiarch since some systems have multiarch directory usage for header and library files.)

Testing on aarch64 is continuing, right now with gcc-11.2.0-8 compiling gcc-11.2.0 source code, since for combinations tested so far, there's a reproducible ICE (internal compiler error) bug that may or may not be related or prevent testing of the current bug. This may be an independent bug, although it does appear related to unwind code. Details later...

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...

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.

In the log file,

grep --color -B4 libiconv log.20210928.config.5.gcc.bug

(-B4 because the compile commands are continued over several lines) seems to show the lines where we would want to insert -L/BUILD/software/installed/lib before /BUILD/software/installed/lib/libiconv.so rather than after it, I assume. Something like a hack or addition of a .m4 file is my guess at a workaround, so that at least gcc can be compiled (by gcc).

Here is a related libiconv g++ related bug from July 2019:

https://savannah.nongnu.org/bugs/?56702

but I think that there have been a lot of iconv related changes since then.