sci-mathematics/pari-2.8_pre20160616 ../src/kernel/ix86/asm0.h:114:4: error: 'asm' operand has impossible constraints

[sedimentation-fault]

pari-2.8_pre20160616 breaks compilation with error:

i686-pc-linux-gnu-gcc  -c -I. -I../src/headers -fPIC -O2 -march=pentium4 -pipe -fno-strict-aliasing -DGCC_INLINE -fPIC -o alglin1.o ../src/basemath/alglin1.c
In file included from ../src/headers/pari.h:50:0,
                 from ../src/basemath/alglin1.c:20:
../src/basemath/alglin1.c: In function '_Fl_addmul':
../src/kernel/ix86/asm0.h:114:4: error: 'asm' operand has impossible constraints
    __asm__ ("mull %4 ; addl %5,%0 ; adcl %6,%1" \
    ^
../src/kernel/none/level1.h:917:8: note: in expansion of macro 'addmul'
   l0 = addmul(x0, x1); h0 = hiremainder;
        ^
i686-pc-linux-gnu-gcc  -c -I. -I../src/headers -fPIC -O2 -march=pentium4 -pipe -fno-strict-aliasing -DGCC_INLINE -fPIC -o alglin2.o ../src/basemath/alglin2.c
Makefile:1022: recipe for target 'alglin1.o' failed
make: *** [alglin1.o] Error 1

Some info:

Portage 2.2.28 (python 3.4.3-final-0, hardened/linux/x86, gcc-4.9.3, glibc-2.21-r1, 3.16.5-gentoo i686)
=================================================================
System uname: Linux-3.16.5-gentoo-i686-Intel-R-_Pentium-R-_4_CPU_3.40GHz-with-gentoo-2.2
KiB Mem:     XXX total,    199124 free
KiB Swap:    YYY total,   1201816 free
Timestamp of repository gentoo: Tue, 30 Aug 2016 23:15:01 +0000
sh bash 4.3_p42-r1
ld GNU ld (Gentoo 2.25.1 p1.1) 2.25.1
app-shells/bash:          4.3_p42-r1::gentoo
dev-java/java-config:     2.2.0-r3::gentoo
dev-lang/perl:            5.20.2::gentoo
dev-lang/python:          2.7.10-r1::gentoo, 3.4.3-r1::gentoo
dev-util/cmake:           3.5.2-r1::gentoo
dev-util/pkgconfig:       0.28-r2::gentoo
sys-apps/baselayout:      2.2::gentoo
sys-apps/openrc:          0.19.1::gentoo
sys-apps/sandbox:         2.10-r2::gentoo
sys-devel/autoconf:       2.13::gentoo, 2.69::gentoo
sys-devel/automake:       1.10.3-r1::gentoo, 1.11.6-r1::gentoo, 1.12.6::gentoo, 1.13.4::gentoo, 1.14.1::gentoo, 1.15::gentoo
sys-devel/binutils:       2.25.1-r1::gentoo
sys-devel/gcc:            4.3.6-r1::gentoo, 4.4.7::gentoo, 4.8.3::gentoo, 4.9.3::gentoo
sys-devel/gcc-config:     1.7.3::gentoo
sys-devel/libtool:        2.4.6::gentoo
sys-devel/make:           4.1-r1::gentoo
sys-kernel/linux-headers: 3.16::XXX (virtual/os-headers)
sys-libs/glibc:           2.21-r1::gentoo

[sedimentation-fault]

This seems to be related to my hardened profile. I tried a workaround found in bug #499996 (it was for xine libraries) that suggested to put the following at the start of the src_configure() function of the ebuild:

    # Workaraound to "asm operand has impossible constraints" as suggested in bug #499996.
    use x86 && append-cflags $(test-flags-CC -fno-stack-check)

but it did not help me much, as I now keep getting:

The ebuild phase 'unpack' has been killed by signal 7

, no matter whether I try to emerge normally, or to prepend FEATURES='-sandbox' to the emerge command. Any ideas?

[kiwifb]

OK, the last bit is weird. I think you have done good detective work and I'd say you have done something else accidentally to get the unpack phase to pack up.

[sedimentation-fault]

You are right. The error

The ebuild phase 'unpack' has been killed by signal 7

is unrelated - but a very nasty one, because it persists and does not let you emerge anymore. Plus: even with '--debug' you don't get anything helpful! You tap in the dark! To anybody who stumbles upon this, here is the solution for the first time (there is absolutely nothing on the Internet about this yet!):

YOUR DISK IS FULL AND YOU DIDN'T TAKE NOTICE BECAUSE YOU DIDN'T DO 'df -i'! Wow... Now, back to our intial problem: Indeed, after deleting a few thousand files, I was able to compile sci-mathematics/pari-2.8_pre20160616 sucessfully! :-)

So the solution is: The src_configure() function of the ebuild should begin like this:

src_configure() {

    # Workaraound to "asm operand has impossible constraints" as suggested in bug #499996.
    use x86 && append-cflags $(test-flags-CC -fno-stack-check)

    tc-export CC
    export CPLUSPLUS=$(tc-getCXX)

As far as I am concerned, you can mark this as resolved, but please communicate the solution to 'upstream'. :-)

[kiwifb]

Good old running out of space! You learn to check for that in the face of unexplainable failure.

[sedimentation-fault]

For the sake of completeness, let me add this, even if actually OT: The 'killed by signal 7' error is still there, even after purging a million or so unnecessary files! Therefore, the true cause of this is still not found! :-( But at least, having space and inodes enables emerge to continue its work if I do immediately after the error: emerge --resume --nodeps

[kiwifb]

Feels like hardware errors. Is your disk dying?

[sedimentation-fault]

No, absolutely not! No error messages in /var/log/messages, nothing at all! syslog-ng is absolutely quiet. All programs run fine - dozens of them. Three browser windows with 50 tabs each. Two hyperthreading CPUs running at 100% (well, most of the time, due to compilation ;-)). All OK, the usual insanity. :-)

This f...ine error has happened to me again some time in the past. It seems to be related to upgrades - I've read somewhere: binutils upgrades! Somebody suggested to reboot after a binutils upgrade. I am reluctant to reboot, unless there are compelling reasons.

The thing that drives me mad is that, even with the '--debug' option, I do not get anything when it occurs, the log file shows:

+ __ebuild_phase post_pkg_setup
+ declare -F post_pkg_setup
+ set +x
^[[31;01m * ^[[39;49;00mThe ebuild phase 'unpack' has been killed by signal 7.

All those '+' lines come from the debug output. Obviously, '--debug' is not enough to catch this. :-(

I have run python-updater but I am out of ideas for this. Why would it continue flawlessly (given there is enough space/inodes, of course ;-)), as it is doing right now, compiling 217 packages with '--resume --nodeps'? The '--nodeps' IS essential: as soon as I drop it, I get the dreaded 'killed by signal 7' error.

So now have to do: emerge --deep --with-bdeps=y --verbose --verbose-conflicts --newuse --backtrack=30 -uta @world then I answer with 'Yes' when I'm asked if I want to merge those 200+ packages, then it breaks with

The ebuild phase 'unpack' has been killed by signal 7

at the first package it tries to unpack. And then I just do emerge --resume --nodeps and all is well! That's not normal! I can imagine it's either the new binutils (I've already done 'env-update && source /etc/profile', just in case...), or the fact that I have a tail -f /var/log/emerge-fetch.log in another terminal, or some other crazy condition...

I am sorry that now this thread is hijacked by this unrelated, silly error. I probably shouldn't have mentioned it at all - but at that time I thought it was some eclass spitting it due to my ebuild change for Pari...

[kiwifb]

signal 7 aka SIGEMT. Fairly unusual but related to emulation of instructions apparently: http://www.delorie.com/gnu/docs/glibc/libc_472.html Anything in dmesg?

[sedimentation-fault]

No, nothing in dmesg. The last lines are from some sysctl calls I tried yesterday (playing around with scheduling policies, I tried to set a lower time slice for real-time processes with sysctl -w kernel.sched_rt_runtime_us=666666 , to which I got a "Device or resource busy" greeting and a sysctl: The scan_unevictable_pages sysctl/node-interface has been disabled for lack of a legitimate use case in dmesg), but they are really unrelated, as they occurred once and not at each one of the numerous times I tried to emerge. Oh, and besides a [sched_delayed] sched: RT throttling activated, which looks harmless to me. Unless...unless the 'unpack' phase is run in some real-time scheduling policy, which is throttled and throws a 'signal 7' - very wild speculation of mine here...

No, my RT experimentations are unrelated to this. Reading the word 'emulation' in the link you gave, I strongly suspect sandbox. But even with FEATURES='-sandbox' emerge..., this still happened. I am not sure if I tried FEATURES='-sandbox -usersandbox' emerge... though...anyway, as I am emerging as root, I would guess that -usersandbox is irrelevant...

What seems to trigger it for sure is the calculation of dependencies. The error goes away as soon as I use '--nodeps' OR I merge one package ONLY with emerge -1 =some-package-x.y.z.

Is there a way to increase verbosity of debugging, so that the cause of a SIGEMT can be caught and displayed?

Ah, before I forget: all my emerge jobs run in the SCHED_BATCH scheduling policy AND with a nice (read: dynamic) priority of 19 (lowest), due to the following two commands running in cron every minute:

pgrep emerge | tail -n 1 | xargs chrt -b -p 0 >/dev/n
ull 2>&1
pgrep emerge | tail -n 1 | xargs renice -n 19 >/dev/n
ull 2>&1

Don't tell me it's because of this...

[kiwifb]

I am far from my comfort zone here so I won't tell you it is related to your cron settings. However instead of renicing in cron, I would suggest reading the make.conf man page for an alternative "nicer" way to do it

       PORTAGE_NICENESS = [number]
              The value of this variable will be added to the current nice level that emerge is running at.  In other words, this will not set  the  nice
              level, it will increment it.  For more information about nice levels and what are acceptable ranges, see nice(1).