Emerge hangs after successful compilation of anything

[404468]

I've played around with compilation flags a little; now, when I emerge anything (f.e. gcc), it never finishes the install.
Looking at the --verbose build log, compilation is successful, so this probably doesn't have anything to do with my current make.conf. This conclusion is supported by the fact that I've commented out all the changes I did to the make.conf (basically reverting it to the defaults) which still resulted in the same behavior.
The last build output I get from the log is:

Code: Select all

>>> Completed installing sys-devel/gcc-10.2.0-r1 into /var/tmp/portage/sys-devel/gcc-10.2.0-r1/image

 * Final size of build directory: 2052720 KiB (  1.9 GiB)
 * Final size of installed tree:   420204 KiB (410.3 MiB)

After which it just sits idle (I terminated emerge after a couple hours).
The --debug flag gives a better insight into what portage/emerge is doing. The debug output after the 'Completed installing' step is so long that I can't attach it here, but this is the last debug output after which emerge comes to a halt:

Code: Select all

++ f=
++ for dir in "${forbidden_dirs[@]}"
++ read l
+++ echo '/var/tmp/portage/sys-devel/gcc-10.2.0-r1/image/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/plugin/libcc1plugin.so.0.0.0:/usr/lib/../lib64
/var/tmp/portage/sys-devel/gcc-10.2.0-r1/image/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/plugin/libcp1plugin.so.0.0.0:/usr/lib/../lib64
/var/tmp/portage/sys-devel/gcc-10.2.0-r1/image/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/32/libasan.so.6.0.0:/usr/lib/../lib
/var/tmp/portage/sys-devel/gcc-10.2.0-r1/image/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/32/libubsan.so.1.0.0:/usr/lib/../lib
/var/tmp/portage/sys-devel/gcc-10.2.0-r1/image/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/libcc1.so.0.0.0:/usr/lib/../lib64
/var/tmp/portage/sys-devel/gcc-10.2.0-r1/image/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/liblsan.so.0.0.0:/usr/lib/../lib64
/var/tmp/portage/sys-devel/gcc-10.2.0-r1/image/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/libasan.so.6.0.0:/usr/lib/../lib64
/var/tmp/portage/sys-devel/gcc-10.2.0-r1/image/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/libubsan.so.1.0.0:/usr/lib/../lib64
/var/tmp/portage/sys-devel/gcc-10.2.0-r1/image/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/libtsan.so.0.0.0:/usr/lib/../lib64'
+++ grep -F -e :/var/tmp/portage/sys-devel/gcc-10.2.0-r1 -e :: -e ': '
+++ find /var/tmp/portage/sys-devel/gcc-10.2.0-r1/image -type f '(' -perm -u+s -o -perm -g+s ')' -exec scanelf -qyRF '%r %p' '{}' +
+++ grep '$ORIGIN'

Apparently the find call is taking potentially days to complete, which I don't fully understand. Also, many flags passed to find from the debug output don't make sense (for example, what is `-qyRF` supposed to mean? It's definitely not a part of the GNU find utility).
I'm a little confused and very frustrated, this being the second gentoo stage3 install within a few days where I encountered the same issue. I'd really like to use Gentoo on my system, but I won't start over again for the third time and I'm not sure how I'm supposed to use this distribution if either I or the computer can't do the most basic things.
This is running on the hardened profile with pretty much default compilation flags (`-O2 -march=native`), however I've added the lto, pgo and graphite USE flags for gcc. Has anyone here ran into the same issue before and could assist me?

[avdb]

I didn't run in the same issue myself, but I pretty much avoid optimizations like LTO because I think that they'll do more bad than good. Try it again without third-party optimizations I'd say.

[404468]

I didn't run in the same issue myself, but I pretty much avoid optimizations like LTO because I think that they'll do more bad than good. Try it again without third-party optimizations I'd say.

The thing is that I've disabled all my optimizations/compilation flags and I even just tried it without my use flags and I'm still experiencing the same issue, so it can't be that.


Side Note: I forgot to mention that this is running on a 8 core/16 thread cpu, it should be reasonably fast enough to emerge gcc within a couple of hours xD

[pjp]

The thing is that I've disabled all my optimizations/compilation flags and I even just tried it without my use flags and I'm still experiencing the same issue, so it can't be that.

Disabling them doesn't fix something that was broken by being compiled with them.

flags passed to find from the debug output don't make sense (for example, what is `-qyRF` supposed to mean? It's definitely not a part of the GNU find utility).

Go back and look more closely at the output. -qyRF are not options passed to find. They are options passed to 'scanelf' which is run using find's -exec option. On my system, find shows that %p is the file name, but I don't have an option for %r. Otherwise find is searching for files with either the setuid or setgid bits enabled. If it finds any, it sends them to scanelf.

If the problem is related to bad binaries due to the prior compilation flags, you might be able to fix it by booting with your installation media and recompiling the entire system. I've not tried to recover a system that way, so I'd wait for other expertise to provide better guidance, but I believe you'd need to extract the stage3, enter the chroot (and other related steps as mentioned in the install guide) then I would "Rebuild Everything".

I'm a little confused and very frustrated, this being the second gentoo stage3 install within a few days where I encountered the same issue. I'd really like to use Gentoo on my system, but I won't start over again for the third time and I'm not sure how I'm supposed to use this distribution if either I or the computer can't do the most basic things.
This is running on the hardened profile with pretty much default compilation flags (`-O2 -march=native`), however I've added the lto, pgo and graphite USE flags for gcc.

I missed the part about hardened profile the first time I read the post. That may also be part of the problem.

If this is your first install, I recommend doing the basics until you are more comfortable with Gentoo. It is unlikely that correctly functioning hardware "can't do the most basic things." That said, compiling can reveal hardware problems, and compiling under a hardened profile can reveal hardware problems that are more rarely encountered. Example: I had a system that compiled just fine. I decided to try switching to the hardened profile, and at a certain step in the migration (consistently the same step), the computer would reboot. I believe that had exposed a faulty memory channel on the motherboard.

My recommendation would be to start over and follow the guide and "do basic things" that way you don't end up with an outlier potentially due to choices with unpredictable results.

Gentoo allows you to make a mess, because "you're in charge." But it also expects you to have the mop and vacuum to clean up afterward. Since my original install in 2002, I've had no critical problems that I recall. But I've almost exclusively used recommend safe / basic settings. Perhaps unsurprisingly, neither do I walk on a tightrope between tall buildings.

[Hu]

Looking at the --verbose build log, compilation is successful, so this probably doesn't have anything to do with my current make.conf. This conclusion is supported by the fact that I've commented out all the changes I did to the make.conf (basically reverting it to the defaults) which still resulted in the same behavior.

Maybe. If your prior settings built a broken program, and you have not recompiled that program with good settings, then your prior settings could still be causing you an issue now.

Code: Select all

+++ find /var/tmp/portage/sys-devel/gcc-10.2.0-r1/image -type f '(' -perm -u+s -o -perm -g+s ')' -exec scanelf -qyRF '%r %p' '{}' +

Apparently the find call is taking potentially days to complete, which I don't fully understand.

Is any CPU time used? If no, then one of the programs is blocked. If yes, then one of the programs is spinning without making forward progress.

Also, many flags passed to find from the debug output don't make sense (for example, what is `-qyRF` supposed to mean? It's definitely not a part of the GNU find utility).

It does not need to be, because it is not an option to find. It is part of the command that find will -exec on matching objects, so it is a parameter to scanelf. See man scanelf for valid flags.

[404468]

Disabling them doesn't fix something that was broken by being compiled with them.

Yes, but the problem persists when re-emerging gcc. Are you suggesting I could've permanently bricked my compiler by applying some use flags?

If the problem is related to bad binaries due to the prior compilation flags, you might be able to fix it by booting with your installation media and recompiling the entire system. I've not tried to recover a system that way, so I'd wait for other expertise to provide better guidance, but I believe you'd need to extract the stage3, enter the chroot (and other related steps as mentioned in the install guide) then I would "Rebuild Everything".

I am currently typing this on a USB stick running Arch Linux, with a terminal emulator in the background chrooted into my gentoo installation. In fact, I've never booted into the gentoo install itself because I haven't configured my bootloader yet. I have already tried rebuilding the entire system, and it didn't work out the same way that emerging gcc didn't work out from the build logs I attached at the top of this question: It wouldn't finish the install after the 'Completed installing to <tmp directory>' step.

If this is your first install, I recommend doing the basics until you are more comfortable with Gentoo.

Yes, this is basically my first gentoo install, but I have gathered some experience with GNU/Linux over the years (multiple debian systems, occasional fedora usage, just recently switched to Arch Linux a couple of months ago). I love hacking stuff and I saw Gentoo as very appealing to me because it offered even lower-level control than Arch over things like kernel configuration and compiler options, so after looking into the gentooLTO project (https://github.com/InBetweenNames/gentooLTO/) and GCC optimization I just went ahead and tried it out after configuring my kernel (from pf-sources). I just think its odd that I'm encountering these issues now, considering nobody else (even gentoolto users) have them.

I had a system that compiled just fine. I decided to try switching to the hardened profile, and at a certain step in the migration (consistently the same step), the computer would reboot. I believe that had exposed a faulty memory channel on the motherboard.

I'm a programmer, but I don't know much about C, yet I am still interested in the hardened profile. Security is important and if others have done the effort of providing sandboxing options etc. during compilation, I'll take it. If the project is known to be unstable, why is that not pointed out in the wiki? I have expected some applications to break because of the hardened toolchain, but me not being able to re-emerge @world which basically only includes everything that was already included in the hardened stage3? That's just strange. I hope this has nothing to do with my hardware.

My recommendation would be to start over and follow the guide and "do basic things" that way you don't end up with an outlier potentially due to choices with unpredictable results.

I've mostly followed the handbook and then configured/customized Gentoo the same way I would try out other distributions: changing the options exposed to me, partly knowing what I'm doing and partly learning by doing. Obviously I've messed something up, but I can't imagine that me applying compilation options I've seen countless other people use after going through the related gcc documentation could lead to an unfixable problem.

[pjp]

Are you suggesting I could've permanently bricked my compiler by applying some use flags?

I'm suggesting it is possible something was bricked. Perhaps the compiler, perhaps something else.

I have already tried rebuilding the entire system, and it didn't work out the same way that emerging gcc didn't work out from the build logs I attached at the top of this question: It wouldn't finish the install after the 'Completed installing to <tmp directory>' step.

I'm not a developer, but this suggests a misconfiguration, too aggressive compiler or other related options, or maybe a hardware issue.

I love hacking stuff and I saw Gentoo as very appealing to me because it offered even lower-level control than Arch over things like kernel configuration and compiler options, so after looking into the gentooLTO project (https://github.com/InBetweenNames/gentooLTO/) and GCC optimization I just went ahead and tried it out after configuring my kernel (from pf-sources). I just think its odd that I'm encountering these issues now, considering nobody else (even gentoolto users) have them.

Previously you wrote:

I'd really like to use Gentoo on my system, but I won't start over again for the third time and I'm not sure how I'm supposed to use this distribution if either I or the computer can't do the most basic things.

I suggested using the the most basic things Gentoo offers until you get more comfortable with how it works. There is no reason you can't and unless you have faulty or particularly old hardware, there's no reason it can't. Given that you are experiencing issues that no one else is experiencing, it seems most reasonable to reasess your approach. Since you love hacking but don't want to start over or try a different approach, I'm not sure what else to suggest.

If the project is known to be unstable, why is that not pointed out in the wiki? I have expected some applications to break because of the hardened toolchain, but me not being able to re-emerge @world which basically only includes everything that was already included in the hardened stage3? That's just strange. I hope this has nothing to do with my hardware.

To my knowledge, the project is stable other than as you mentioned, the expectation that some applications will break.

I know that PGO and or LTO have caused problems for some users. I have no idea if any of them involved hardened. But as they can cause problems, it seems reasonable to consider that it could be the problem.

I've mostly followed the handbook and then configured/customized Gentoo the same way I would try out other distributions: changing the options exposed to me, partly knowing what I'm doing and partly learning by doing. Obviously I've messed something up, but I can't imagine that me applying compilation options I've seen countless other people use after going through the related gcc documentation could lead to an unfixable problem.

It may very well be fixable. But as you mentioned, no one else seems to be having these issues, which makes identifying the fix more challenging.

Given the capabilities of your CPU, it doesn't seem like it would be too much of an imposition to test with a non-hardened profile without LTO and PGO and any other non-default settings. You don't even need to build a complete system. Just the basics, you wouldn't even have to build the kernel.

If _that_ fails in a similar manner, then it would seem to be some mistakes during the install, or a hardware problem. Basic installs aren't that problematic, though they might sometimes appear daunting. I'm not sure what kind of mistake could be made that would produce results you're experiencing, so that would appear to reduce the scope of what could be causing the problems.

If you are able to build the basic non-hardened environment, then you could try a hardened profile without non-default settings (don't enable LTO, PGO or other stuff). Success or failure there would seem to add another data point on what could be or have been the issue.

If other people have successfully combined hardened with LTO, PGO, etc., then maybe it there is a hardware issue. memtest may help, but passing all of its extended tests doesn't guarantee there are no hardware problems. I think I had to let my previously mentioned system run for more than 24 hours before it indicated a problem, yet compiling with a hardened profile did it every time and it didn't take that long.

[Phoenix591]

Personally I do use lto with the hardened profile, but the workarounds and exceptions provided by the lto overlay's configs have been invaluable, many things get broken by it that need it disabled or other workarounds applied. I don't use pgo since it increases compilation time dramatically ( build executable with instrumentation, run it to generate data, use data to rebuild executable better)

[404468]

The problem here is that I’m not getting a compilation error, it just never finishes the install after successful compilation.

[Hu]

Yes, that makes this harder to debug. As I see it, you have two options:

• Find the specific programs that are not making forward progress correctly. Debug them to understand why.
• Set aside this install and use a working environment to build a new install that you incrementally make more like the non-working install until you find the tipping point.

We saw above that some combination of the find and scanelf command is where it becomes stuck. Please answer my question from before: is it spinning or stalled? If it is spinning, which program is spinning, and in what part of its code? If it is stalled, where is it blocked?

[kryglik]

Hi. Having exactly the same problem. After emerging any package, the process finishes compilation and installation to the /var/tmp folder. Then it hangs.

According to debug, this is where it freezes:

Code: Select all

+ /usr/lib/portage/python3.6/estrip --queue /
+ /usr/lib/portage/python3.6/estrip --ignore
+ /usr/lib/portage/python3.6/estrip --dequeue

What does help is adding "nostrip" to the FEATURES. But it is not a solution, but merely a workaround. Any ideas would be appreciated...

[Hu]

estrip is a shell script that runs many other commands, so my first idea would be that you should attempt to answer the questions I originally posted to Hyperspace above: determine whether the hang is a spin or a stall, and in either case, what specific statement is stuck. From there, we can determine why it is stuck.

You may want to start by adding set -x to the top of estrip, then reproducing the problem and posting the resulting output.

[404468]

I have decided to restart from the base stage3 and reapply my changes one by one on top of them.
It took me less than a couple of hours to run into a new issue, see here https://forums.gentoo.org/viewtopic-p-8495810.html.
Thank you for your responses.

[kryglik]

estrip is a shell script that runs many other commands, so my first idea would be that you should attempt to answer the questions I originally posted to Hyperspace above: determine whether the hang is a spin or a stall, and in either case, what specific statement is stuck. From there, we can determine why it is stuck.

You may want to start by adding set -x to the top of estrip, then reproducing the problem and posting the resulting output.

Thanks for the reply!

Seems the emerge freezes on "mkfifo".

Code: Select all

+ mkfifo -m 600 /var/tmp/portage/sys-apps/file-5.39-r2/temp/multijob.rz0ep7

If I try manualy create pipe using mkfifo it freezes on the command as well. Not sure what to about it (system is in commercial virtualisation).


Strace:

Code: Select all

...
close(3)                                = 0
umask(000)                              = 022
umask(022)                              = 000
mknod("testing.pipe", S_IFIFO|0600)     = 0
openat(AT_FDCWD, "testing.pipe", O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_PATH

[kryglik]

This bug can be found here: https://bugs.gentoo.org/712136

Downgrading coreutils works for me (mkfifo no longer hangs).

Before the downgrade, mkfifo hangs only when using -m 600, otherwise works OK.

[Hu]

That bug is filed by someone using an ancient kernel under Gentoo Prefix. Does that describe your situation as well? Your strace output shows that mknod tried to use O_PATH, which is new in Linux v2.6.39 (released May 2011), so I am not surprised mknod might use it unconditionally. Based on a quick reading in man open about what O_PATH does, I could believe that using it on a FIFO, and having it ignored by the kernel, would cause a hang until something writes to the other end of the FIFO.

[kryglik]

That bug is filed by someone using an ancient kernel under Gentoo Prefix. Does that describe your situation as well? Your strace output shows that mknod tried to use O_PATH, which is new in Linux v2.6.39 (released May 2011), so I am not surprised mknod might use it unconditionally. Based on a quick reading in man open about what O_PATH does, I could believe that using it on a FIFO, and having it ignored by the kernel, would cause a hang until something writes to the other end of the FIFO.

What works is downgrading coreutils (as mentioned in the bug discussion) to =coreutils-8.30. After that the mkfifo works for all cases.

Strace is different though, there is no openat:

Code: Select all

brk(0x556d20723000)                     = 0x556d20723000
openat(AT_FDCWD, "/usr/lib64/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=7152544, ...}) = 0
mmap(NULL, 7152544, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fdcae391000
close(3)                                = 0
umask(000)                              = 022
umask(022)                              = 000
mknod("/tmp/fifo.test2", S_IFIFO|0600)  = 0
chmod("/tmp/fifo.test2", 0600)          = 0
close(1)                                = 0
close(2)                                = 0
exit_group(0)                           = ?
+++ exited with 0 +++

[Hu]

In the successful case in the bug report, there is also no use of openat. Downgrading is a workaround, since eventually you will need a newer coreutils for something.

[404468]

I'm back at the same problem again. I don't have strace installed and since I can't emerge anything the best I can do is post a debug log. I also wasn't able to downgrade to coreutils-8.30 for the same reason. Here's the full debug log from emerging coreutils-8.30 (as an example) starting at the last message reported by emerge ('Completed installing to <tmp dir>'): https://bin.snopyta.org/?911e70ef4dfae6 ... wnaSGWb3yA . Note that all the sandboxing-related feature flags have been added by my hardened profile. I'm also attaching a slightly stripped output of

Code: Select all

emerge --info

here in case that helps. I haven't added any features on my own, however the *flags have all been added by me in my make.conf.

Code: Select all

Portage 3.0.4 (python 3.7.8-final-0, default/linux/amd64/17.1/hardened, gcc-10.2.0, glibc-2.31-r6, 5.8.5-arch1-1 x86_64)
=================================================================
System uname: Linux-5.8.5-arch1-1-x86_64-AMD_Ryzen_7_2700X_Eight-Core_Processor-with-gentoo-2.7
KiB Mem:    32893756 total,  28350204 free
KiB Swap:    4095996 total,   4095996 free
# <... timestamps ...>
sh bash 5.0_p18
ld GNU gold (Gentoo 2.33.1 p2 2.33.1) 1.16
ccache version 3.7.11 [disabled]
app-shells/bash:          5.0_p18::gentoo
dev-lang/perl:            5.30.3::gentoo
dev-lang/python:          2.7.18-r100::lto-overlay, 3.7.8-r2::gentoo, 3.8.5::gentoo
dev-util/ccache:          3.7.11::gentoo
sys-apps/baselayout:      2.7::gentoo
sys-apps/openrc:          0.42.1::gentoo
sys-apps/sandbox:         2.18::gentoo
sys-devel/autoconf:       2.69-r4::gentoo
sys-devel/automake:       1.16.1-r1::gentoo
sys-devel/binutils:       2.33.1-r1::gentoo
sys-devel/gcc:            9.3.0-r1::gentoo, 10.2.0-r1::gentoo
sys-devel/gcc-config:     2.3.1::gentoo
sys-devel/libtool:        2.4.6-r6::gentoo
sys-devel/make:           4.2.1-r4::gentoo
sys-kernel/linux-headers: 5.4-r1::gentoo (virtual/os-headers)
sys-libs/glibc:           2.31-r6::gentoo
Repositories:

gentoo <... defaults ...>

lto-overlay
    location: /var/db/repos/lto-overlay
    sync-type: git
    sync-uri: https://github.com/gentoo-mirror/lto-overlay.git
    masters: gentoo mv

mv
    location: /var/db/repos/mv
    sync-type: git
    sync-uri: https://github.com/gentoo-mirror/mv.git
    masters: gentoo

ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="@FREE"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O3 -march=znver1 -fomit-frame-pointer -m3dnow -msse3 -mmmx -pipe -fno-semantic-interposition -malign-data=cacheline -fcommon -fopenmp -ftree-parallelize-loops=16 -pthread -ftree-vectorize -flto=16 -flto-compression-level=9 -fuse-linker-plugin -fdevirtualize-at-ltrans -fdevirtualize-speculatively -fgraphite-identity -floop-nest-optimize -fipa-pta -fno-math-errno -fno-trapping-math -fuse-ld=gold -fira-region=mixed -fira-algorithm=CB -fira-hoist-pressure -fira-loop-pressure"
EMERGE_DEFAULT_OPTS="--jobs 16 --load-average 14"
ENV_UNSET="CARGO_HOME DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN GOPATH PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR"
FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
< ... left out identical *FLAGS and junk ...>
GENTOO_MIRRORS="<MIRROR>"
LANG="en_US.UTF-8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu"
MAKEOPTS="-j16"
PKGDIR="/var/cache/binpkgs"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git"
PORTAGE_TMPDIR="/var/tmp"
USE="acl alsa amd64 bzip2 crypt dhclient git gnupg gnutls gpg gzip hardened iconv ipv6 libglvnd libressl libtirpc lzma lzo multilib ncurses networkmanager nls nptl openmp openresolv pam pcre pie pulseaudio readline resolvconf seccomp split-usr ssl ssp threads udev unicode wifi xattr xtpax zlib zstd"
< ... junk ... >
PYTHON_SINGLE_TARGET="python3_7"
PYTHON_TARGETS="python2_7 python3_7 python3_8"
USERLAND="GNU"
Unset:  CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, LC_ALL, LINGUAS, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS

Is any CPU time used? If no, then one of the programs is blocked. If yes, then one of the programs is spinning without making forward progress.

`top` shows that the idle emerge is almost never using any cpu time (every couple seconds it will go from 0% cpu usage to 0.4%) and reports that emerge is in a sleeping state.

You may want to start by adding set -x

I did a `set -x` before emerging and it didn't change anything.

I just switched to the vanilla profile and I'm still running into the same issue with a very similar debug output.
Thanks for your help.

[psycho_driver]

FYI I just had this start happening to me on a system rebuild and it was from a newly rebuilt bash with -floop-parallelize-all -ftree-parallelize-loops=3 graphite flags added. I also had PYTHONPATH set to "$PYTHONPATH:/usr/local/blah blah" due to having some locally compiled python packages. Unfortunately that was just breaking down to ":/usr/local/blah blah" since PYTHONPATH wasn't set elsewhere. I actually think it was emerging bash with the latter that caused the breakage because I re-emerged with the new opt flags in place and it's working fine.

Fortunately I was watching the build and saw that bash was the last successfully completed emerge before the hang. I had another machine with the same architecture that I was able to borrow a bash from. Also FYI you can rm /bin/bash and replace it without your system breaking (just do it right away, from the same shell).

[Dominique_71]

Yes, this is basically my first gentoo install,

Why not begun with safe CFLAGS as recommanded into the handbook... And when done, use a free partition to make another gentoo installation and experiment with the non recommanded flags. I done it in the past with a basic installation (no X, only the ttys), the most time consuming part was to read the gcc documentation and set safe cflags according to that gcc doc. An update later, I got a boot panic at reboot and after messing with the grub prompt, I succeeded to boot into a tty and to login, but almost everything was resulting into system panic and freeze.

If you really want to do it, profiling the CFLAGS is best done on a per package basis, which can be really time consuming.

[sam_]

Please do file bugs if a package misbehaves with flags which don't break conformance (e.g. -ffast-math, don't bother with bug reports for those).

[RayOfLight]

Coming from another post, have you tried using FEATURES="-network-sandbox"? I think it helped on my case.

[Hu]

Based on the reports above, network-sandbox is unlikely to be relevant here. If it is relevant, that is a bug, too. You should never need to explicitly disable that from the command line.