Re: [gentoo-user] New profile, gcc-13.2.1_p20240210 fails to build. ATTN: Peter Humphrey.
On Monday, 25 March 2024 07:04:57 GMT Dale wrote: > 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. -- Regards, Peter.
Re: [gentoo-user] New profile, gcc-13.2.1_p20240210 fails to build. ATTN: 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. -- Regards, Peter.
Re: [gentoo-user] New profile, gcc-13.2.1_p20240210 fails to build. ATTN: Peter Humphrey.
Il 25/03/24 08:04, Dale ha scritto: 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
Re: [gentoo-user] New profile, gcc-13.2.1_p20240210 fails to build. ATTN: Peter Humphrey.
On Monday, 25 March 2024 07:04:57 GMT Dale wrote: > Paul Colquhoun wrote: > > 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! signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] New profile, gcc-13.2.1_p20240210 fails to build. ATTN: Peter Humphrey.
Paul Colquhoun wrote: > 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 :-) :-)
Re: [gentoo-user] New profile, gcc-13.2.1_p20240210 fails to build. ATTN: Peter Humphrey.
On Sunday, March 24, 2024 8:49:28 A.M. AEDT Dale wrote: > Michael wrote: > >> 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. -- Reverend Paul Colquhoun, ULC. http://andor.dropbear.id.au/ Asking for technical help in newsgroups? Read this first: http://catb.org/~esr/faqs/smart-questions.html#intro
Re: [gentoo-user] New profile, gcc-13.2.1_p20240210 fails to build. ATTN: Peter Humphrey.
Michael wrote: >> 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 :-) :-)
Re: [gentoo-user] New profile, gcc-13.2.1_p20240210 fails to build. ATTN: Peter Humphrey.
On Saturday, 23 March 2024 21:28:27 GMT Dale wrote: > Michael wrote: > > On Saturday, 23 March 2024 20:45:03 GMT Dale wrote: > >> 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. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] New profile, gcc-13.2.1_p20240210 fails to build. ATTN: Peter Humphrey.
Michael wrote: > On Saturday, 23 March 2024 20:45:03 GMT Dale wrote: >> Howdy, >> >> I'm doing this in a chroot. This is *not* my live system. This is the >> mount info, in case it matters. >> >> <<>> >> >> >> 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 :-) :-)
Re: [gentoo-user] New profile, gcc-13.2.1_p20240210 fails to build. ATTN: Peter Humphrey.
On Saturday, 23 March 2024 20:45:03 GMT Dale wrote: > Howdy, > > I'm doing this in a chroot. This is *not* my live system. This is the > mount info, in case it matters. > > > root@fireball / # mount | grep gentoo > /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) > root@fireball / # > > > 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 > gcc fails with: > > > 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' \ > > > And further down, this: > > > 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 > > > And even further down: > > > 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 ,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 > > > Very close to the end, this: > > > 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 >
[gentoo-user] New profile, gcc-13.2.1_p20240210 fails to build. ATTN: Peter Humphrey.
Howdy,
I'm doing this in a chroot. This is *not* my live system. This is the
mount info, in case it matters.
root@fireball / # mount | grep gentoo
/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)
root@fireball / #
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
gcc fails with:
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' \
And further down, this:
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
And even further down:
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 ,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
Very close to the end, this:
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/libatomic.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
