[gentoo-user] New profile, gcc-13.2.1_p20240210 fails to build. ATTN: Peter Humphrey.

[Michael]

Howdy,
I'm doing this in a chroot. This is *not* my live system. This is the
mount info, in case it matters.
/proc on /backup/gentoo-build/proc type proc (rw,relatime)
sysfs on /backup/gentoo-build/sys type sysfs
(rw,nosuid,nodev,noexec,relatime)
debugfs on /backup/gentoo-build/sys/kernel/debug type debugfs
(rw,nosuid,nodev,noexec,relatime)
fusectl on /backup/gentoo-build/sys/fs/fuse/connections type fusectl
(rw,nosuid,nodev,noexec,relatime)
none on /backup/gentoo-build/sys/fs/cgroup type cgroup2
(rw,nosuid,nodev,noexec,relatime,nsdelegate)
devtmpfs on /backup/gentoo-build/dev type devtmpfs
(rw,nosuid,noexec,size=10240k,nr_inodes=4104300,mode=755)
devpts on /backup/gentoo-build/dev/pts type devpts
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /backup/gentoo-build/dev/shm type tmpfs (rw,nosuid,nodev,noexec)
shm on /backup/gentoo-build/dev/shm type tmpfs
(rw,nosuid,nodev,noexec,relatime)
mqueue on /backup/gentoo-build/dev/mqueue type mqueue
(rw,nosuid,nodev,noexec,relatime)
/run on /backup/gentoo-build/run type tmpfs (rw,relatime)
tmpfs on /backup/gentoo-build/run type tmpfs (rw,size=262144k,mode=755)
I've following the news item with this. This is early and already it
has issues. Maybe switching is a bit early yet?? Anyway, this is what
make[3]: Entering directory
'/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/build/x86_64-pc-linux-
gnu/32/libstdc++-v3/include' echo timestamp > stamp-pb
echo timestamp > stamp-host
make[3]: [Makefile:1820: x86_64-pc-linux-gnu/bits/largefile-config.h]
Error 1 (ignored)
echo 0 > stamp-namespace-version
echo 1 > stamp-visibility
echo 1 > stamp-extern-template
echo 1 > stamp-dual-abi
echo 1 > stamp-cxx11-abi
echo 1 > stamp-allocator-new
echo 'define _GLIBCXX_USE_FLOAT128 1' > stamp-float128
sed -e '/^#pragma/b' \
make[3]: Leaving directory
'/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/build/x86_64-pc-linux-
gnu/32/libstdc++-v3/include' config.status: executing libtool commands
config.status: executing generate-headers commands
make[3]: Entering directory
'/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/build/x86_64-pc-linux-
gnu/libstdc++-v3/include' echo timestamp > stamp-pb
echo timestamp > stamp-host
make[3]: [Makefile:1819: x86_64-pc-linux-gnu/bits/largefile-config.h]
Error 1 (ignored)
make[3]: [Makefile:1820: x86_64-pc-linux-gnu/bits/largefile-config.h]
Error 1 (ignored)
echo 0 > stamp-namespace-version
echo 1 > stamp-visibility
echo 1 > stamp-extern-template
echo 1 > stamp-dual-abi
echo 1 > stamp-cxx11-abi
echo 1 > stamp-allocator-new
echo 'define _GLIBCXX_USE_FLOAT128 1' > stamp-float128
sed -e 's/\(UNUSED\)/_GLIBCXX_\1/g' \
-e 's/\(GCC[ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*_H\)/_GLIBCXX_\1/g' \
-e 's/SUPPORTS_WEAK/__GXX_WEAK__/g' \
-e 's/\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*USE_WEAK\)/_GLIBCXX_\1/g' \
-e 's,^#include "\(.*\)",#include <bits/\1>,g' \
<
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/gcc-13-20240210/libstdc
++-v3/../libgcc/gthr-posix.h

x86_64-pc-linux-gnu/bits/gthr-default.h

make[3]: Leaving directory
'/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/build/x86_64-pc-linux-
gnu/32/libstdc++-v3/include' config.status: executing libtool commands
config.status: executing generate-headers commands
make[3]: Entering directory
'/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/build/x86_64-pc-linux-
gnu/libstdc++-v3/include' echo timestamp > stamp-pb
echo timestamp > stamp-host
make[3]: [Makefile:1819: x86_64-pc-linux-gnu/bits/largefile-config.h]
Error 1 (ignored)
make[3]: [Makefile:1820: x86_64-pc-linux-gnu/bits/largefile-config.h]
Error 1 (ignored)
echo 0 > stamp-namespace-version
echo 1 > stamp-visibility
echo 1 > stamp-extern-template
echo 1 > stamp-dual-abi
echo 1 > stamp-cxx11-abi
echo 1 > stamp-allocator-new
echo 'define _GLIBCXX_USE_FLOAT128 1' > stamp-float128
Makefile:901: warning: ignoring old recipe for target 'all-multi'
make[8]: Leaving directory
'/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/build/x86_64-pc-linux-
gnu/32/libatomic' make[8]: Entering directory
'/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/build/x86_64-pc-linux-
gnu/32/libatomic' true DO=install multi-do # make
/bin/mkdir -p
'/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/image/usr/lib/../lib'
/bin/sh ./libtool --mode=install /usr/bin/install -c libatomic.la
'/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/image/usr/lib/../lib'
libtool: install: /usr/bin/install -c .libs/libatomic.so.1.2.0
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/image/usr/lib/../lib/libatom
ic.so.1.2.0 libtool: install: (cd
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/image/usr/lib/../lib &&
{ ln -s -f libatomic.so.1.2.0 libatomic.so.1 || { rm -f libatomic.so.1
&& ln -s libatomic.so.1.2.0 libatomic.so.1; }; })
libtool: install: (cd
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/image/usr/lib/../lib &&
{ ln -s -f libatomic.so.1.2.0 libatomic.so || { rm -f libatomic.so && ln
-s libatomic.so.1.2.0 libatomic.so; }; })
libtool: install: /usr/bin/install -c .libs/libatomic.lai
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/image/usr/lib/../lib/libatom
ic.la libtool: install: /usr/bin/install -c .libs/libatomic.a
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/image/usr/lib/../lib/libatom
ic.a libtool: install: chmod 644
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/image/usr/lib/../lib/libatom
ic.a libtool: install: /usr/x86_64-pc-linux-gnu/bin/ranlib
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/image/usr/lib/../lib/libatom
ic.a libtool: install: warning: remember to run `libtool --finish
/usr/lib/../lib'
make[8]: Nothing to be done for 'install-data-am'.
make[8]: Leaving directory
'/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/build/x86_64-pc-linux-
gnu/32/libatomic' make[7]: Leaving directory
'/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/build/x86_64-pc-linux-
gnu/32/libatomic' make[6]: Leaving directory
'/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/build/x86_64-pc-linux-
gnu/32/libatomic' make[5]: Leaving directory
'/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/build/x86_64-pc-linux-
gnu/libatomic' /bin/mkdir -p
'/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/image/usr/lib/../lib64'
/bin/sh ./libtool --mode=install /usr/bin/install -c libatomic.la
'/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/image/usr/lib/../lib64'
libtool: install: /usr/bin/install -c .libs/libatomic.so.1.2.0
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/image/usr/lib/../lib64/libat
omic.so.1.2.0 libtool: install: (cd
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/image/usr/lib/../lib64
&& { ln -s -f libatomic.so.1.2.0 libatomic.so.1 || { rm -f
libatomic.so.1 && ln -s libatomic.so.1.2.0 libatomic.so.1; }; })
libtool: install: (cd
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/image/usr/lib/../lib64
&& { ln -s -f libatomic.so.1.2.0 libatomic.so || { rm -f libatomic.so &&
ln -s libatomic.so.1.2.0 libatomic.so; }; })
libtool: install: /usr/bin/install -c .libs/libatomic.lai
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/image/usr/lib/../lib64/libat
omic.la libtool: install: /usr/bin/install -c .libs/libatomic.a
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/image/usr/lib/../lib64/libat
omic.a libtool: install: chmod 644
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/image/usr/lib/../lib64/libat
omic.a libtool: install: /usr/x86_64-pc-linux-gnu/bin/ranlib
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/image/usr/lib/../lib64/libat
omic.a libtool: install: warning: remember to run `libtool --finish
/usr/lib/../lib64'
make[4]: Nothing to be done for 'install-data-am'.
make[4]: Leaving directory
'/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/build/x86_64-pc-linux-
gnu/libatomic' make[3]: Leaving directory
'/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/build/x86_64-pc-linux-
gnu/libatomic' make[2]: Leaving directory
'/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/build/x86_64-pc-linux-
gnu/libatomic' make[1]: Leaving directory
'/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/build'
* (no error message)
I saw where Peter mentioned in another thread gcc failing with no error
message for him. This could be related. A solution to this may help
more than just me. I'm not sure how to diagnose a failure when it gives
no real error. Heck, having a error sometimes isn't much help. :/ I
might add, the errors listed above didn't stop the compile until close
to the end. It did seem to ignore them since it compiled a good while
afterwards. I'm including in case those errors lead to the failure
later on. They could be nothing or may be a clue.
Open to ideas.
Dale
:-) :-)

Hmm ... my gcc is failing on one of my installations, with no error ... after
it built successfully once already, as part of the initial toolchain update.
:-/

OK, I'm out of ideas too. May have to sleep on this and look at it again
tomorrow.

[Dale]

Post by Michael

Howdy,
I'm doing this in a chroot. This is *not* my live system. This is the
mount info, in case it matters.
<<<SNIP>>>
I saw where Peter mentioned in another thread gcc failing with no error
message for him. This could be related. A solution to this may help
more than just me. I'm not sure how to diagnose a failure when it gives
no real error. Heck, having a error sometimes isn't much help. :/ I
might add, the errors listed above didn't stop the compile until close
to the end. It did seem to ignore them since it compiled a good while
afterwards. I'm including in case those errors lead to the failure
later on. They could be nothing or may be a clue.
Open to ideas.
Dale
:-) :-)

Hmm ... my gcc is failing on one of my installations, with no error ... after
it built successfully once already, as part of the initial toolchain update.
:-/
OK, I'm out of ideas too. May have to sleep on this and look at it again
tomorrow.

Nice to know I'm not alone.  I forgot to mention, it wanted to update
glibc first.  The news item said NOT to let it do that and use the
--nodeps option instead.  So, the command I used had that option.  I've
since restarted it, just in case it finishes.  I'll post back if it
does.  I find it odd that it builds fine one time but fails on others. 
Strange things happen tho. 

Dale

:-)  :-) 

[Michael]

Post by Michael

I saw where Peter mentioned in another thread gcc failing with no error
message for him. This could be related. A solution to this may help
more than just me. I'm not sure how to diagnose a failure when it gives
no real error. Heck, having a error sometimes isn't much help. :/ I
might add, the errors listed above didn't stop the compile until close
to the end. It did seem to ignore them since it compiled a good while
afterwards. I'm including in case those errors lead to the failure
later on. They could be nothing or may be a clue.
Open to ideas.
Dale
:-) :-)

Hmm ... my gcc is failing on one of my installations, with no error ...
after it built successfully once already, as part of the initial
toolchain update.>
:-/
OK, I'm out of ideas too. May have to sleep on this and look at it again
tomorrow.

Nice to know I'm not alone. I forgot to mention, it wanted to update
glibc first. The news item said NOT to let it do that and use the
--nodeps option instead. So, the command I used had that option. I've
since restarted it, just in case it finishes. I'll post back if it
does. I find it odd that it builds fine one time but fails on others.
Strange things happen tho.
Dale
:-) :-)

There's a new patch for gcc. You need to follow the guide as you did, then
resync portage to fetch the latest ebuild for gcc, before you start the emerge
--emptytree world. This is how I managed to get ggc to build after previous
attempts with 'no error' failures. Hope this works for you.

[Dale]

Post by Michael

Nice to know I'm not alone. I forgot to mention, it wanted to update
glibc first. The news item said NOT to let it do that and use the
--nodeps option instead. So, the command I used had that option. I've
since restarted it, just in case it finishes. I'll post back if it
does. I find it odd that it builds fine one time but fails on others.
Strange things happen tho.
Dale
:-) :-)

There's a new patch for gcc. You need to follow the guide as you did, then
resync portage to fetch the latest ebuild for gcc, before you start the emerge
--emptytree world. This is how I managed to get ggc to build after previous
attempts with 'no error' failures. Hope this works for you.

It just failed the second attempt.  I'll sync again and hopefully the
new ebuild will fix things.  If nothing else, they working out the
kinks.  Since I'm in a chroot, messing up won't matter. 

Maybe Peter will see this, update and try again.  May help him as well. 

Thanks.

Dale

:-)  :-) 

[Paul Colquhoun]

Post by Michael

Nice to know I'm not alone. I forgot to mention, it wanted to update
glibc first. The news item said NOT to let it do that and use the
--nodeps option instead. So, the command I used had that option. I've
since restarted it, just in case it finishes. I'll post back if it
does. I find it odd that it builds fine one time but fails on others.
Strange things happen tho.
Dale
:-) :-)

There's a new patch for gcc. You need to follow the guide as you did, then
resync portage to fetch the latest ebuild for gcc, before you start the
emerge --emptytree world. This is how I managed to get ggc to build
after previous attempts with 'no error' failures. Hope this works for
you.

It just failed the second attempt. I'll sync again and hopefully the
new ebuild will fix things. If nothing else, they working out the
kinks. Since I'm in a chroot, messing up won't matter.
Maybe Peter will see this, update and try again. May help him as well.

I had the gcc compile fail, but was successful after removing the "objc" use
flag.

Unfortunately, it seemd to be required by app-arch/unar during step 16,
rebuild world.

I'm re-enbleing it and will see how it all goes.

[Dale]

Post by Paul Colquhoun
I had the gcc compile fail, but was successful after removing the "objc" use
flag.
Unfortunately, it seemd to be required by app-arch/unar during step 16,
rebuild world.
I'm re-enbleing it and will see how it all goes.

Here is my update.  I wanted to skip the system update and change
profiles first.  Then do the emerge -e world which would also update
anything that was new as well.  I'd only have to compile once tho. 
Well, that may have caused a problem.  It may work for some but it
didn't here.  I first had to do my usual emerge -auDN world and get a
clean run.  I had one build to fail, had to work on that.  Anyway, where
it says update first, it is best to do that.  It might work if you
don't, might not.  I'm now up to the part where I recompile everything. 
Oh the joy.  At least it is a cool night so the extra heat will keep me
warm.  ROFL 

Oh, where it says to emerge gcc and no dependencies, may as well go
ahead and add the --nodeps bit.  It has to run that way anyway so it
doesn't hurt anything but it does save time since emerge doesn't need to
look to see if anything else needs to be updated or you have to go back
and add the option to insure it doesn't.  On my rig, which isn't the
fastest or slowest, it saves a couple minutes.  YMMV. 

Overall, the devs did a really good job with the instructions.  Just
have to update first as it says.  It works better.  ;-)  I just wonder
who went through the torture of figuring out what went in what order.  O_O 

Dale

:-)  :-) 

[Michael]

Post by Paul Colquhoun
I had the gcc compile fail, but was successful after removing the "objc"
use flag.
Unfortunately, it seemd to be required by app-arch/unar during step 16,
rebuild world.
I'm re-enbleing it and will see how it all goes.

Here is my update. I wanted to skip the system update and change
profiles first. Then do the emerge -e world which would also update
anything that was new as well. I'd only have to compile once tho.
Well, that may have caused a problem. It may work for some but it
didn't here. I first had to do my usual emerge -auDN world and get a
clean run. I had one build to fail, had to work on that. Anyway, where
it says update first, it is best to do that. It might work if you
don't, might not.

I'm trying to do the same on an old, slow PC which had not been touched for a
few months now. Most packages would need updating anyway and didn't fancy
spending a week to get it up to date before changing the profile, only to
rebuild everything once more. We'll see how it goes ...

Overall, the devs did a really good job with the instructions. Just
have to update first as it says. It works better. ;-)

A big thank you to the devs for their effort to make our life easier!

[ralfconn]

Post by Dale
Here is my update.  I wanted to skip the system update and change
profiles first.  Then do the emerge -e world which would also update
anything that was new as well.  I'd only have to compile once tho.
Well, that may have caused a problem.  It may work for some but it
didn't here.  I first had to do my usual emerge -auDN world and get a
clean run.  I had one build to fail, had to work on that.  Anyway, where
it says update first, it is best to do that.  It might work if you
don't, might not.  I'm now up to the part where I recompile everything.
Oh the joy.  At least it is a cool night so the extra heat will keep me
warm.  ROFL

As I noted in another thread, the profile switch involves a change in
the LDFLAGS, with the addition of the 'pack-relative-relocs' option.
https://rfc.archlinux.page/0023-pack-relative-relocs/ suggests that
adding this flag might trigger issues with tools not up-to-date. I
suppose that is why the gentoo devs instruct to rebuild binutils/gcc
before 'emerge -e', and that might be the reason why your first attempt
worked only partially.

BTW my update to split-usr 23-0 went pretty smoothly, next will be to go
with the merged-usr.

raf

[Peter Humphrey]

Overall, the devs did a really good job with the instructions. Just
have to update first as it says. It works better. ;-) I just wonder
who went through the torture of figuring out what went in what order. O_O

Indeed, they've done a thorough job - and not, I assume, just the one whose
name appears on the news item.

[Paul Colquhoun]

Post by Paul Colquhoun
I had the gcc compile fail, but was successful after removing the "objc" use
flag.
Unfortunately, it seemd to be required by app-arch/unar during step 16,
rebuild world.
I'm re-enbleing it and will see how it all goes.

The full rebuild, with the "objc" use flag enabled, completed almost without
error.
I had to clean out a few old packages that hadn't been an issue earlier, so
the consistency checking appears to have improved.

[Peter Humphrey]

On Saturday, 23 March 2024 20:45:03 GMT Dale wrote:

--->8

I saw where Peter mentioned in another thread gcc failing with no error
message for him. This could be related.

Nope. I was all fingers and thumbs at the time, now all straightened out.