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

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

[Dale]

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


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
/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/libatomic.la
libtool: install: /usr/bin/install -c .libs/libatomic.a
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/image/usr/lib/../lib/libatomic.a
libtool: install: chmod 644
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/image/usr/lib/../lib/libatomic.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/libatomic.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/libatomic.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/libatomic.la
libtool: install: /usr/bin/install -c .libs/libatomic.a
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/image/usr/lib/../lib64/libatomic.a
libtool: install: chmod 644
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/image/usr/lib/../lib64/libatomic.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/libatomic.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'
 * ERROR: sys-devel/gcc-13.2.1_p20240210::gentoo failed (install phase):
 *   (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

:-)  :-) 

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

[Michael]

[-- Attachment #1: Type: text/plain, Size: 9615 bytes --]

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 <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
> 
> 
> 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/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'
>  * ERROR: sys-devel/gcc-13.2.1_p20240210::gentoo failed (install phase):
>  *   (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.  

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Dale]

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

:-)  :-) 

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

[Michael]

[-- Attachment #1: Type: text/plain, Size: 1767 bytes --]

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.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Dale]

[-- Attachment #1: Type: text/plain, Size: 1045 bytes --]

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

:-)  :-) 

[-- Attachment #2: Type: text/html, Size: 1699 bytes --]

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

[Paul Colquhoun]

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.

[Dale]

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.

[Michael]

[-- Attachment #1: Type: text/plain, Size: 1331 bytes --]

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!


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[ralfconn]

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.

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

[Paul Colquhoun]

On Sunday, March 24, 2024 8:51:18 P.M. AEDT 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.


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.

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

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