I'm trying to rebuild gcc-10 (after huge world upgrade after half-a-year pause, and after migrating to 17.1 profile), and it fails to build, complaining on: ```config.status: executing default commands In file included from /var/tmp/portage/sys-devel/gcc-10.3.0-r2/work/gcc-10.3.0/gcc/d/d-system.h:23, from /var/tmp/portage/sys-devel/gcc-10.3.0-r2/work/gcc-10.3.0/gcc/d/dmd/root/dsystem.h:24, from /var/tmp/portage/sys-devel/gcc-10.3.0-r2/work/gcc-10.3.0/gcc/d/dmd/idgen.c:17: /var/tmp/portage/sys-devel/gcc-10.3.0-r2/work/gcc-10.3.0/gcc/system.h:544:20: error: conflicting declaration of C function ‘const char* strsignal(int)’ 544 | extern const char *strsignal (int); | ^~~~~~~~~ In file included from /var/tmp/portage/sys-devel/gcc-10.3.0-r2/work/gcc-10.3.0/libstdc++-v3/include/c_global/cstring:42, from /var/tmp/portage/sys-devel/gcc-10.3.0-r2/work/gcc-10.3.0/gcc/system.h:235, from /var/tmp/portage/sys-devel/gcc-10.3.0-r2/work/gcc-10.3.0/gcc/d/d-system.h:23, from /var/tmp/portage/sys-devel/gcc-10.3.0-r2/work/gcc-10.3.0/gcc/d/dmd/root/dsystem.h:24, from /var/tmp/portage/sys-devel/gcc-10.3.0-r2/work/gcc-10.3.0/gcc/d/dmd/idgen.c:17: /usr/include/string.h:462:14: note: previous declaration ‘char* strsignal(int)’ 462 | extern char *strsignal (int __sig) __THROW; | ^~~~~~~~~ In file included from /var/tmp/portage/sys-devel/gcc-10.3.0-r2/work/gcc-10.3.0/gcc/system.h:695, from /var/tmp/portage/sys-devel/gcc-10.3.0-r2/work/gcc-10.3.0/gcc/d/d-system.h:23, from /var/tmp/portage/sys-devel/gcc-10.3.0-r2/work/gcc-10.3.0/gcc/d/dmd/root/dsystem.h:24, from /var/tmp/portage/sys-devel/gcc-10.3.0-r2/work/gcc-10.3.0/gcc/d/dmd/idgen.c:17: /var/tmp/portage/sys-devel/gcc-10.3.0-r2/work/gcc-10.3.0/gcc/../include/libiberty.h:112:14: error: ambiguating new declaration of ‘char* basename(const char*)’ 112 | extern char *basename (const char *) ATTRIBUTE_RETURNS_NONNULL ATTRIBUTE_NONNULL(1); | ^~~~~~~~ In file included from /var/tmp/portage/sys-devel/gcc-10.3.0-r2/work/gcc-10.3.0/libstdc++-v3/include/c_global/cstring:42, from /var/tmp/portage/sys-devel/gcc-10.3.0-r2/work/gcc-10.3.0/gcc/system.h:235, from /var/tmp/portage/sys-devel/gcc-10.3.0-r2/work/gcc-10.3.0/gcc/d/d-system.h:23, from /var/tmp/portage/sys-devel/gcc-10.3.0-r2/work/gcc-10.3.0/gcc/d/dmd/root/dsystem.h:24, from /var/tmp/portage/sys-devel/gcc-10.3.0-r2/work/gcc-10.3.0/gcc/d/dmd/idgen.c:17: /usr/include/string.h:508:26: note: old declaration ‘const char* basename(const char*)’ 508 | extern "C++" const char *basename (const char *__filename) | ^~~~~~~~ make[3]: *** [/var/tmp/portage/sys-devel/gcc-10.3.0-r2/work/gcc-10.3.0/gcc/d/Make-lang.in:338: d/idgen.dmdgen.o] Error 1 make[2]: *** [Makefile:4785: all-stage2-gcc] Error 2 make[1]: *** [Makefile:24739: stage2-bubble] Error 2 make: *** [Makefile:24954: bootstrap-lean] Error 2 ``` Since /usr/include/string.h belongs to glibc, I bet it is incompatibility with new (already stabilized, btw) glibc-2.33 (I doubt that it can be related to revbumps)
Created attachment 736993 [details] emere --info sys-devel/gcc:10
Created attachment 736996 [details] sys-devel:gcc-10.3.0-r2:20210831-071448.log.bz2
(In reply to Vadim A. Misbakh-Soloviov (mva) from comment #0) > [snip] > Since /usr/include/string.h belongs to glibc, I bet it is incompatibility > with new (already stabilized, btw) glibc-2.33 (I doubt that it can be > related to revbumps) As discussed on IRC, I don't think this is likely to be the case (or at least not for everybody), given it's been tested quite a bit. Interestingly some of the folks who have hit this before have contaminated environments, so I've suggested trying a build with env -i and going from there (https://stackoverflow.com/questions/12255058/g-4-7-1-compilation-error-conflicting-types-for-strsignal).
UPD: @sam told me on IRC to try with `env -i`. It didn't help and build also failed. I'm not sure if I should post `emerge --info` with `env -i`.
Well, I just looked carefully, and noticed that it most probably related to USE="d" on GCC. So, that may be the reason of "not for everyone". And also side note: gcc:11 not hitting that problem, so, it still looks for me like "already fixed (in 11), but not backported (to 10) glibc compatibility issue"
I doubt it's https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d3ae0f515d0c675d42f4f18fc267e8e75f6b6f26 but it could be.
(In reply to Vadim A. Misbakh-Soloviov (mva) from comment #5) > > And also side note: gcc:11 not hitting that problem, so, it still looks for > me like "already fixed (in 11), but not backported (to 10) glibc > compatibility issue" ^ that's good news, given that gcc-11 is now already stable
I can't reproduce this with any glibc-2.33.
sys-libs/glibc-2.33-r7 not have `crypt` USE-flag, that needed to sys-devel/gcc:10
(In reply to Alexander from comment #9) > sys-libs/glibc-2.33-r7 not have `crypt` USE-flag, that needed to > sys-devel/gcc:10 That doesn’t seem to be relevant to this bug but I don’t understand your point. Please file a new bug with more output to explain what you mean, but that is intentional for the libxcrypt migration (see news item).
Not seen any reports of this since, assuming fixed in snapshot since or 10.4.0.
