Created attachment 360776 [details] /var/tmp/portage/app-emulation/virtualbox-4.2.18/work/VirtualBox-4.2.18/configure.log 'emerge -v1 virtaulbox' fails with: ... Checking for compiler.h: compiler.h not found, OK. Checking for 32-bit support: Cannot execute 32-bit applications! Either enable 32-bit support in the kernel configuration or use --disable-vmmraw to disable 32-bit guests. Check /var/tmp/portage/app-emulation/virtualbox-4.2.18/work/VirtualBox-4.2.18/configure.log for details * ERROR: app-emulation/virtualbox-4.2.18::gentoo failed (configure phase): * configure failed But I think, that I have 32-bit support in the kernel: root@condor:/root(9)# zgrep x32 /proc/config.gz root@condor:/root(10)# ll /usr/src/linux lrwxrwxrwx 1 root root 12 Oct 13 12:17 /usr/src/linux -> linux-3.11.4/ root@condor:/root(11)# grep X32 /usr/src/linux/.config CONFIG_X86_X32=y
(In reply to Juergen Rose from comment #0) > Checking for compiler.h: compiler.h not found, OK. > Checking for 32-bit support: > Cannot execute 32-bit applications! Either enable 32-bit support in the > kernel configuration or use --disable-vmmraw to disable 32-bit guests. > But I think, that I have 32-bit support in the kernel: This is about the compiler, not the kernel. It's likely that it fails like this: x86_64-pc-linux-gnu-gcc -m32 -O -Wall -o test.out test.c In file included from /usr/include/features.h:382:0, from /usr/include/stdint.h:26, from /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/include/stdint.h:3, from test.c:1: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory compilation terminated. You could compile and run the test program listed in the configure.log manually to find out (since sadly the compiler output is tossed out). > > root@condor:/root(9)# zgrep x32 /proc/config.gz You should probably check for CONFIG_IA32_EMULATION, not CONFIG_X86_X32. Also, zgrep returned nothing? > root@condor:/root(10)# ll /usr/src/linux > lrwxrwxrwx 1 root root 12 Oct 13 12:17 /usr/src/linux -> linux-3.11.4/ > root@condor:/root(11)# grep X32 /usr/src/linux/.config > CONFIG_X86_X32=y Now, is that even the same kernel?
(In reply to Jeroen Roovers from comment #1) > (In reply to Juergen Rose from comment #0) > > Checking for compiler.h: compiler.h not found, OK. > > Checking for 32-bit support: > > Cannot execute 32-bit applications! Either enable 32-bit support in the > > kernel configuration or use --disable-vmmraw to disable 32-bit guests. > > > But I think, that I have 32-bit support in the kernel: > > This is about the compiler, not the kernel. It's likely that it fails like > this: > > x86_64-pc-linux-gnu-gcc -m32 -O -Wall -o test.out test.c > In file included from /usr/include/features.h:382:0, > from /usr/include/stdint.h:26, > from > /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/include/stdint.h:3, > from test.c:1: > /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or > directory > compilation terminated. > > You could compile and run the test program listed in the configure.log > manually to find out (since sadly the compiler output is tossed out). OK, I created a test file .tmp_src.c: root@condor:/var/tmp/portage/app-emulation/virtualbox-4.2.18(17)# cat .tmp_src.c #include <stdint.h> int main(void) { return 0; } I compiled the file: root@condor:/var/tmp/portage/app-emulation/virtualbox-4.2.18(18)# x86_64-pc-linux-gnu-gcc -m32 -O -Wall -o .tmp_out .tmp_src.c root@condor:/var/tmp/portage/app-emulation/virtualbox-4.2.18(19)# ll .tmp_out -rwxr-xr-x 1 root root 6890 Oct 13 18:06 .tmp_out* root@condor:/var/tmp/portage/app-emulation/virtualbox-4.2.18(20)# file .tmp_out .tmp_out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, not stripped And I tried to execute it: root@condor:/var/tmp/portage/app-emulation/virtualbox-4.2.18(21)# ./.tmp_out -bash: ./.tmp_out: No such file or directory I.e., the kernel does not recognize .tmp_out as a executable file. > > root@condor:/root(9)# zgrep x32 /proc/config.gz > > You should probably check for CONFIG_IA32_EMULATION, not CONFIG_X86_X32. > Also, zgrep returned nothing? root@condor:/var/tmp/portage/app-emulation/virtualbox-4.2.18(23)# zgrep IA32 /proc/config.gz CONFIG_IA32_EMULATION=y # CONFIG_IA32_AOUT is not set > > root@condor:/root(10)# ll /usr/src/linux > > lrwxrwxrwx 1 root root 12 Oct 13 12:17 /usr/src/linux -> linux-3.11.4/ > > root@condor:/root(11)# grep X32 /usr/src/linux/.config > > CONFIG_X86_X32=y > > Now, is that even the same kernel? No, they are different, but I wanted to test both: root@condor:/var/tmp/portage/app-emulation/virtualbox-4.2.18(24)# uname -a Linux condor 3.11.0-gentoo #1 SMP Mon Sep 9 15:58:52 CEST 2013 x86_64 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz GenuineIntel GNU/Linux
(In reply to Juergen Rose from comment #2) > OK, I created a test file .tmp_src.c: > > root@condor:/var/tmp/portage/app-emulation/virtualbox-4.2.18(17)# cat > .tmp_src.c > #include <stdint.h> > int main(void) > { > return 0; > } > > > I compiled the file: > > root@condor:/var/tmp/portage/app-emulation/virtualbox-4.2.18(18)# > x86_64-pc-linux-gnu-gcc -m32 -O -Wall -o .tmp_out .tmp_src.c > root@condor:/var/tmp/portage/app-emulation/virtualbox-4.2.18(19)# ll .tmp_out > -rwxr-xr-x 1 root root 6890 Oct 13 18:06 .tmp_out* > root@condor:/var/tmp/portage/app-emulation/virtualbox-4.2.18(20)# file > .tmp_out > .tmp_out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), > dynamically linked (uses shared libs), for GNU/Linux 2.6.16, not stripped > > And I tried to execute it: > > root@condor:/var/tmp/portage/app-emulation/virtualbox-4.2.18(21)# ./.tmp_out > -bash: ./.tmp_out: No such file or directory > > > I.e., the kernel does not recognize .tmp_out as a executable file. No, it appears that it cannot find an appropriate libc.so to dynamically link against... Try compiling it with an added -static to find out. Maybe you are using the wrong sys-libs/glibc?
Please post your `emerge --info' output in a comment, too.
This bug is a duplicate of Bug https://bugs.gentoo.org/show_bug.cgi?id=487936. Any way /lib/ld-linux.so.2 disappeared. After creating the link /lib/ld-linux.so.2 manually the issue disappeared/
*** This bug has been marked as a duplicate of bug 487936 ***
