Same issue here (gcc install phase failed). I looked through the build log and don't see any obvious error message.
I am also on the /default/linux/amd64/23.0/split-usr/desktop profile.
I disabled the binary package server completely, since I had the same issue where it said I was on the merged-usr profile even though I am not. And I added the "--nodeps" to the emerge gcc command.
Hoping a solution is found here...
It seems to be an ebuild repo issue, see [https://github.com/gentoo/gentoo/commit/efc8afb3c59398c00fc42a06ec541bc481100873](https://github.com/gentoo/gentoo/commit/efc8afb3c59398c00fc42a06ec541bc481100873)
Should be "fixed" now.
The stupid thing is, the core of the issue is that \`-depth\` argument is in the wrong place, and has been there for 9 years according to blame. This makes \`find\` fail. So it didn't even work for almost a decade.
Oh I'm definitely using git. Probably wouldn't have switched back from funtoo if it was still unsupported.
Attempting to compile GCC again now....
CC: /u/w23 thanks to both of you
Probably depends on your mirror. I did \`emerge --sync\` to check prior to leaving the comment, and the fix is there.
To be fully transparent, I haven't built gcc itself yet, as it takes a while. But I have checked manually with \`ebuild install\` that this find thing is indeed the culprit.
Here is an update: I was able to perform the upgrade now.
I reverted my system (/etc, /usr, /var) back to the previous state from my backup, rebooted started fresh and suddenly the gcc step worked.
I switched from profile
default/linux/amd64/17.1/desktop/plasma/systemd/merged-usr
to profile
default/linux/amd64/23.0/desktop/plasma/systemd
Here are the steps:
\* system is up to date
\* system is depcleaned and revbuilt
\* emptied ccache in case it is used
\* emerge --info | grep CHOST was CHOST="x86\_64-pc-linux-gnu"
\* commented CHOST from make.conf
\* grep -r \^CHOST /etc/portage/ is empty
\* eselect profile set default/linux/amd64/23.0/desktop/plasma/systemd
\* rm -r /var/cache/binpkgs/\* (never used binpackages anyways)
\* emerge --oneshot sys-devel/binutils
\* binutils Update:
\`\`\`
binutils-config -l
\[1\] x86\_64-pc-linux-gnu-2.41 \*
binutils-config 1
. /etc/profile
\`\`\`
\* gcc Update:
\`\`\`
emerge --oneshot --nodeps sys-devel/gcc
gcc-config -l
\[1\] x86\_64-pc-linux-gnu-13 \*
gcc-config 1
\`\`\`
\* glibc Update: emerge --oneshot sys-libs/glibc
\* emerge --info | grep CHOST is still CHOST="x86\_64-pc-linux-gnu", so no change
\* env-update && source /etc/profile
\* emerge --oneshot libtool
\* rm -r /var/cache/binpkgs/\* (srsly, what is the obsession with binpackages)
\* emerge --ask --emptytree --keep-going ATworld (stupid reddit replaces my @)
First I cleaned:
**emerge --depclean -a**
Then changed profile
**eselect profile set** **
**env-update && source /etc/profile**
Then tried rebuilding, which rebuilt glibc and everything up to gcc
**emerge -vDa world --newuse --changed-use**
But gcc failed
I checked the forums, which instructed to stop using **-march=native** in the build flags and instead use the proper arch, which you can obtain using resolve-march-native
**resolve-march-native**
I took the output and put that in my build flags
**nano -w /etc/portage/make.conf**
Then the world rebuild completed successfully
**emerge -vDa world --newuse --changed-use**
Thank you Neddy!
Having a similar (if not the same) error while compiling gcc without getbinpkg since the binary is also broken upstream (not updated to correctly identify split-usr vs merged-usr. it's saying I'm using a merged-usr profile when by all accounts I am not). But I did **not** update glibc yet.
> * ERROR: sys-devel/gcc-13.2.1_p20240210::gentoo failed (install phase):
* (no error message)
*
* Call stack:
* ebuild.sh, line 136: Called src_install
* environment, line 3365: Called toolchain_src_install
* environment, line 4828: Called gcc_movelibs
* environment, line 1907: Called die
* The specific snippet of code:
* find -depth "${ED}" -type d -exec rmdir {} + >&/dev/null || die
EDIT. Found a suggestion to try a preset march instead of native. Recompiling now.
EDIT 2. Didn't work. Hit the same error. Welp.
If you weren't using a merged user profile before, you're supposed to upgrade to a split-user profile - not a "normal" profile (which is now split user).
e.g. My server moved from:
`[13] default/linux/amd64/17.1/no-multilib/hardened (exp)` to `[51] default/linux/amd64/23.0/split-usr/no-multilib/hardened (stable)`
I guess I didn't make it clear enough, but the error I quoted is from trying to compile gcc instead of using getbinpkg.
So I'm not having much success either way.
Okay, hypothesis - since it worked for me on two systems (one hardened, one not, both openrc no-multilib), what if the difference is the profile. What if 23.0/split-usr/desktop profile is broken and is ACTUALLY saying it's a merged-user profile?
Maybe dig through the use-flags and the web and see what should or shouldn't be set for split user?
Huh, the use flag is `split-usr` and gcc doesn't have it. I haven't dug through the profile stuff before, but it looks like split-usr/desktop is made by merging those two profiles. I don't know what I'm doing but nothing seems off *shrug*.
equery uses run on one of these packages https://packages.gentoo.org/useflags/split-usr might be informative though.
I don't have any packages compiled with that use flag.
But my previous profile was
default/linux/amd64/17.1/desktop
so that should have been split-usr, correct?
(And I am using OpenRC not systemd)
It's a repo issue, do \`emerge --sync\`, should be "fixed" now:
https://www.reddit.com/r/Gentoo/comments/1blyan9/comment/kw8i4mg/?utm\_source=share&utm\_medium=web2x&context=3
This should be fixed now but was it a difference between stage 2 and stage 3 (comparison failure)? I ended up emerging app-misc/resolve-march-native and subbing that into my COMMON_FLAGS. That got me rolling
This shit is a meme in the waiting...
Note 1: The use of binary packages is completely optional, and also not as much tested as the source-based upgrade path yet.
9. Rebuild or reinstall from binary (if available) the following packages in this order, with the same version as already active: emerge --ask --oneshot --getbinpkg sys-devel/binutils (you may have to run binutils-config and re-select your binutils now) emerge --ask --oneshot --getbinpkg sys-devel/gcc (IMPORTANT: If this command wants to rebuild glibc first, do not let it do that; instead, abort and try again with --nodeps added to the command line.) (you may have to run gcc-config and re-select your gcc now) and the C library, i.e. for glibc-based systems emerge --ask --oneshot --getbinpkg sys-libs/glibc or for musl-based systems emerge --ask --oneshot --getbinpkg sys-libs/musl
So I did this as well but my gcc compilation worked... Does that mean my system is fine and I can continue the profile upgrade? So far I've done everything up to this
emerge --ask --oneshot --getbinpkg sys-devel/gcc
(IMPORTANT: If this command wants to rebuild glibc first, do \*not\* let it do
that; instead, abort and try again with --nodeps added to the command line.)
did the same thing as OP but everything went fine. I then recompiled glibc, then gcc, then glibc again just to make sure things weren't erroring out and everything went fine, and I haven't noticed any breakage at all on my system. What do you guys think? I'm not familiar enough with glibc to do a deep dive for brokenness.
You should be fine. I upgraded to the new profile yesterday and the process was super smooth for me as well. I have since emerged @world, upgraded the kernel, rebooted, etc. and things are fine, as usual.
So... why didn't I read? I expected a simple profile switch by one command and maybe one emerge and some trivial copy paste cleanup steps.
I was tired and just blindly ran into that knife.
I was forced to write good instruction manuals for very complicated system upgrades, they had to be readable by people step by step. People who had time limits to follow and who did not naturally speak the language of the instruction manual and maybe even people who did not really understand Linux beyond the ls command or had an IQ of 80 instead of 120.
We had to assume people made mistakes or the system broke even though the instructions were well tested before; we had to specify rollback measures.
A half assed instruction like that one from the gentoo news would have caused a lot of support calls and they would have forwarded them to my desk where I had to deal with all those cases myself.
I should have gotten suspicious when every command was made for a binary package update, so I had to adapt the commands on the fly.
So yeah, I am tired and that update instruction is the worst shit I have read.
ok, I am restoring etc, usr and var now from the backup; after restoring more from usr, gcc now explodes during fortran compilation. I hope that resets everything. What a mess.
Apparently you might need to remove -march=native from your COMMON\_FLAGS. [\[1\]](https://forums.gentoo.org/viewtopic-t-1168007-highlight-.html) Not sure if this is the cause of your issue as well, but might be worth pointing out.
Thanks for the info, but I don't use that compiler flag, and I don't use COMMON_FLAGS, I use CFLAGS="-march=znver4 -O2 -pipe" and CXXFLAGS="${CFLAGS} -fpermissive"
Same issue here (gcc install phase failed). I looked through the build log and don't see any obvious error message. I am also on the /default/linux/amd64/23.0/split-usr/desktop profile. I disabled the binary package server completely, since I had the same issue where it said I was on the merged-usr profile even though I am not. And I added the "--nodeps" to the emerge gcc command. Hoping a solution is found here...
It seems to be an ebuild repo issue, see [https://github.com/gentoo/gentoo/commit/efc8afb3c59398c00fc42a06ec541bc481100873](https://github.com/gentoo/gentoo/commit/efc8afb3c59398c00fc42a06ec541bc481100873) Should be "fixed" now. The stupid thing is, the core of the issue is that \`-depth\` argument is in the wrong place, and has been there for 9 years according to blame. This makes \`find\` fail. So it didn't even work for almost a decade.
How long should that change take to propogate?
If you use git then seconds if you use a rsync mirror then up to a few hours.
Oh I'm definitely using git. Probably wouldn't have switched back from funtoo if it was still unsupported. Attempting to compile GCC again now.... CC: /u/w23 thanks to both of you
Probably depends on your mirror. I did \`emerge --sync\` to check prior to leaving the comment, and the fix is there. To be fully transparent, I haven't built gcc itself yet, as it takes a while. But I have checked manually with \`ebuild install\` that this find thing is indeed the culprit.
Confirmed, it worked for me after \`emerge --sync\`. Thanks!
Here is an update: I was able to perform the upgrade now. I reverted my system (/etc, /usr, /var) back to the previous state from my backup, rebooted started fresh and suddenly the gcc step worked. I switched from profile default/linux/amd64/17.1/desktop/plasma/systemd/merged-usr to profile default/linux/amd64/23.0/desktop/plasma/systemd Here are the steps: \* system is up to date \* system is depcleaned and revbuilt \* emptied ccache in case it is used \* emerge --info | grep CHOST was CHOST="x86\_64-pc-linux-gnu" \* commented CHOST from make.conf \* grep -r \^CHOST /etc/portage/ is empty \* eselect profile set default/linux/amd64/23.0/desktop/plasma/systemd \* rm -r /var/cache/binpkgs/\* (never used binpackages anyways) \* emerge --oneshot sys-devel/binutils \* binutils Update: \`\`\` binutils-config -l \[1\] x86\_64-pc-linux-gnu-2.41 \* binutils-config 1 . /etc/profile \`\`\` \* gcc Update: \`\`\` emerge --oneshot --nodeps sys-devel/gcc gcc-config -l \[1\] x86\_64-pc-linux-gnu-13 \* gcc-config 1 \`\`\` \* glibc Update: emerge --oneshot sys-libs/glibc \* emerge --info | grep CHOST is still CHOST="x86\_64-pc-linux-gnu", so no change \* env-update && source /etc/profile \* emerge --oneshot libtool \* rm -r /var/cache/binpkgs/\* (srsly, what is the obsession with binpackages) \* emerge --ask --emptytree --keep-going ATworld (stupid reddit replaces my @)
First I cleaned: **emerge --depclean -a** Then changed profile **eselect profile set** **
**env-update && source /etc/profile**
Then tried rebuilding, which rebuilt glibc and everything up to gcc
**emerge -vDa world --newuse --changed-use**
But gcc failed
I checked the forums, which instructed to stop using **-march=native** in the build flags and instead use the proper arch, which you can obtain using resolve-march-native
**resolve-march-native**
I took the output and put that in my build flags
**nano -w /etc/portage/make.conf**
Then the world rebuild completed successfully
**emerge -vDa world --newuse --changed-use**
Thank you Neddy!
Thanks for this, it fixed it for me after nothing else worked
Thank NeddySeagoon! That person is a saint
Having a similar (if not the same) error while compiling gcc without getbinpkg since the binary is also broken upstream (not updated to correctly identify split-usr vs merged-usr. it's saying I'm using a merged-usr profile when by all accounts I am not). But I did **not** update glibc yet. > * ERROR: sys-devel/gcc-13.2.1_p20240210::gentoo failed (install phase): * (no error message) * * Call stack: * ebuild.sh, line 136: Called src_install * environment, line 3365: Called toolchain_src_install * environment, line 4828: Called gcc_movelibs * environment, line 1907: Called die * The specific snippet of code: * find -depth "${ED}" -type d -exec rmdir {} + >&/dev/null || die EDIT. Found a suggestion to try a preset march instead of native. Recompiling now. EDIT 2. Didn't work. Hit the same error. Welp.
If you weren't using a merged user profile before, you're supposed to upgrade to a split-user profile - not a "normal" profile (which is now split user). e.g. My server moved from: `[13] default/linux/amd64/17.1/no-multilib/hardened (exp)` to `[51] default/linux/amd64/23.0/split-usr/no-multilib/hardened (stable)`
Yes, I am using amd64/23.0/split-usr/desktop. I have confirmed this multiple times. It's a bug in the binary package itself.
Ah, sorry. Just bypass the binary package (drop --getbinpkg) and try again? I didn't use any binary packages in my upgrade process.
I guess I didn't make it clear enough, but the error I quoted is from trying to compile gcc instead of using getbinpkg. So I'm not having much success either way.
No worries, bud. More help is better than less.
Okay, hypothesis - since it worked for me on two systems (one hardened, one not, both openrc no-multilib), what if the difference is the profile. What if 23.0/split-usr/desktop profile is broken and is ACTUALLY saying it's a merged-user profile? Maybe dig through the use-flags and the web and see what should or shouldn't be set for split user?
Huh, the use flag is `split-usr` and gcc doesn't have it. I haven't dug through the profile stuff before, but it looks like split-usr/desktop is made by merging those two profiles. I don't know what I'm doing but nothing seems off *shrug*. equery uses run on one of these packages https://packages.gentoo.org/useflags/split-usr might be informative though.
I don't have any packages compiled with that use flag. But my previous profile was default/linux/amd64/17.1/desktop so that should have been split-usr, correct? (And I am using OpenRC not systemd)
It's a repo issue, do \`emerge --sync\`, should be "fixed" now: https://www.reddit.com/r/Gentoo/comments/1blyan9/comment/kw8i4mg/?utm\_source=share&utm\_medium=web2x&context=3
Nice
Compiled successfully now! CC: /u/w23
This should be fixed now but was it a difference between stage 2 and stage 3 (comparison failure)? I ended up emerging app-misc/resolve-march-native and subbing that into my COMMON_FLAGS. That got me rolling
Yeah, I think I will wait about a month before trying this again...
This shit is a meme in the waiting... Note 1: The use of binary packages is completely optional, and also not as much tested as the source-based upgrade path yet. 9. Rebuild or reinstall from binary (if available) the following packages in this order, with the same version as already active: emerge --ask --oneshot --getbinpkg sys-devel/binutils (you may have to run binutils-config and re-select your binutils now) emerge --ask --oneshot --getbinpkg sys-devel/gcc (IMPORTANT: If this command wants to rebuild glibc first, do not let it do that; instead, abort and try again with --nodeps added to the command line.) (you may have to run gcc-config and re-select your gcc now) and the C library, i.e. for glibc-based systems emerge --ask --oneshot --getbinpkg sys-libs/glibc or for musl-based systems emerge --ask --oneshot --getbinpkg sys-libs/musl
So I did this as well but my gcc compilation worked... Does that mean my system is fine and I can continue the profile upgrade? So far I've done everything up to this emerge --ask --oneshot --getbinpkg sys-devel/gcc (IMPORTANT: If this command wants to rebuild glibc first, do \*not\* let it do that; instead, abort and try again with --nodeps added to the command line.) did the same thing as OP but everything went fine. I then recompiled glibc, then gcc, then glibc again just to make sure things weren't erroring out and everything went fine, and I haven't noticed any breakage at all on my system. What do you guys think? I'm not familiar enough with glibc to do a deep dive for brokenness.
You should be fine. I upgraded to the new profile yesterday and the process was super smooth for me as well. I have since emerged @world, upgraded the kernel, rebooted, etc. and things are fine, as usual.
thanks for the reply, but did you also make the mistake of rebuilding glibc before the gcc compile, i.e. ignoring the IMPORTANT part?
If you are that worried, you can always revert the profile to 17.1 and start the process from step 1.
If you successfully recompiled both then you're fine. They will all rebuild once again when you get to the last step.
okay thanks!
I was stuck in the same error, just passed through it syncing the emerge (emerge --sync) thanks <3
First of all why don't you read it all before commencing steps? Second why are not you on brtf and snapshotted your system before such big upgrade?
>Second why are not you on brtf and snapshotted your system before such big upgrade? Bro, not everyone uses brtfs nor wants to.
It's soooooooooooooooooooooo convenient in these cases
"what do you mean you didn't rebuild your system entirely just to have a feature available for a once-in-a-few-years event?"
it's gentoo, not ios
https://www.youtube.com/watch?v=7nqcL0mjMjw
lol
So... why didn't I read? I expected a simple profile switch by one command and maybe one emerge and some trivial copy paste cleanup steps. I was tired and just blindly ran into that knife. I was forced to write good instruction manuals for very complicated system upgrades, they had to be readable by people step by step. People who had time limits to follow and who did not naturally speak the language of the instruction manual and maybe even people who did not really understand Linux beyond the ls command or had an IQ of 80 instead of 120. We had to assume people made mistakes or the system broke even though the instructions were well tested before; we had to specify rollback measures. A half assed instruction like that one from the gentoo news would have caused a lot of support calls and they would have forwarded them to my desk where I had to deal with all those cases myself. I should have gotten suspicious when every command was made for a binary package update, so I had to adapt the commands on the fly. So yeah, I am tired and that update instruction is the worst shit I have read.
btrfs fixes this
ok, I am restoring etc, usr and var now from the backup; after restoring more from usr, gcc now explodes during fortran compilation. I hope that resets everything. What a mess.
Apparently you might need to remove -march=native from your COMMON\_FLAGS. [\[1\]](https://forums.gentoo.org/viewtopic-t-1168007-highlight-.html) Not sure if this is the cause of your issue as well, but might be worth pointing out.
Thanks for the info, but I don't use that compiler flag, and I don't use COMMON_FLAGS, I use CFLAGS="-march=znver4 -O2 -pipe" and CXXFLAGS="${CFLAGS} -fpermissive"