Created attachment 742173 [details] build.log app-emulation/bochs-2.6.10::gentoo was built with the following: USE="X ncurses readline sdl smp x86-64 -3dnow -avx -debugger -doc -gdb (-svga) -vnc" ABI_X86="(64)" See attachment for the build log. I was able to reproduce this error on two different machines (amd64). Unlike with #646098, building from SVN using the live ebuild does *not* solve the issue. Here's the full runtime log: cs@gentoobox ~ $ bochs ======================================================================== Bochs x86 Emulator 2.6.10 Built from SVN snapshot on December 1, 2019 Compiled on Sep 30 2021 at 11:24:21 ======================================================================== 00000000000i[ ] LTDL_LIBRARY_PATH not set. using compile time default '/usr/lib64/bochs/plugins' 00000000000i[ ] BXSHARE not set. using compile time default '/usr/share/bochs' 00000000000i[ ] lt_dlhandle is 0x55ada59a8640 00000000000i[PLUGIN] loaded plugin libbx_unmapped.so 00000000000i[ ] lt_dlhandle is 0x55ada59a9660 00000000000i[PLUGIN] loaded plugin libbx_biosdev.so 00000000000i[ ] lt_dlhandle is 0x55ada59a9fe0 00000000000i[PLUGIN] loaded plugin libbx_speaker.so 00000000000i[ ] lt_dlhandle is 0x55ada59ae190 00000000000i[PLUGIN] loaded plugin libbx_extfpuirq.so 00000000000i[ ] lt_dlhandle is 0x55ada59aea10 00000000000i[PLUGIN] loaded plugin libbx_parallel.so 00000000000i[ ] lt_dlhandle is 0x55ada59b0640 00000000000i[PLUGIN] loaded plugin libbx_serial.so 00000000000i[ ] lt_dlhandle is 0x55ada59b4aa0 00000000000i[PLUGIN] loaded plugin libbx_gameport.so ------------------------------ Bochs Configuration: Main Menu ------------------------------ This is the Bochs Configuration Interface, where you can describe the machine that you want to simulate. Bochs has already searched for a configuration file (typically called bochsrc.txt) and loaded it if it could be found. When you are satisfied with the configuration, go ahead and start the simulation. You can also start bochs with the -q option to skip these menus. 1. Restore factory default configuration 2. Read options from... 3. Edit options 4. Save options to... 5. Restore the Bochs state from... 6. Begin simulation 7. Quit now Please choose one: [2] 6 00000000000i[ ] lt_dlhandle is (nil) 00000000000p[ ] >>PANIC<< dlopen failed for module 'x' (libbx_x.so): file not found ======================================================================== Event type: PANIC Device: [ ] Message: dlopen failed for module 'x' (libbx_x.so): file not found A PANIC has occurred. Do you want to: cont - continue execution alwayscont - continue execution, and don't ask again. This affects only PANIC events from device [ ] die - stop execution now abort - dump core Choose one of the actions above: [die] ======================================================================== Bochs is exiting with the following message: [ ] dlopen failed for module 'x' (libbx_x.so): file not found ======================================================================== 00000000000i[SIM ] quit_sim called with exit code 1
Created attachment 742176 [details, diff] Patch to fix linking issues Adding to this, the problem is related to the file format test performed by libtool: *** Warning: linker path does not have real file for library -lX11. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libX11 and none of the candidates passed a file format test *** using a file magic. Last file checked: /usr/lib/../lib64//libX11.so.6.4.0 The .so file(s) mentioned in these warnings are present on the system and other applications link against them just fine. However, the files don't seem to pass the file magic test as defined in the configure script, which is why libtool creates (static) libbx_x.a instead of libbx_x.so: *** Warning: libtool could not satisfy all declared inter-library *** dependencies of module libbx_x. Therefore, libtool will create *** a static module, that should work as long as the dlopening *** application is linked with the -dlopen flag. One possible (though potentially not-so-elegant) solution is mentioned on this old upstream bug: https://sourceforge.net/p/bochs/bugs/1391/ It involves patching the configure script to include x86_64 in the list of expected host architectures. I'm attaching a patch that does just that. Surprisingly, though, bochs compiles and links fine when I build it manually in my home directory using the same source tarball and the same commands/options used by the ebuild. Perhaps some Portage expert has an idea of what might be going wrong here.
Thanks for the report! For completeness, please could you also attach the output of 'emerge --info'?
Created attachment 742215 [details] emerge --info output (In reply to Matt Smith from comment #2) > Thanks for the report! For completeness, please could you also attach the > output of 'emerge --info'? Sure!
I have the same issue, and I debugged it one step further. In two words, it looks like some incompatibility between sys-apps/file[seccomp] and portage's sandbox. A quick workaround is to recompile sys-apps/file with USE=-seccomp. For the proper fix, I believe either portage or sys-apps/file has to be fixed, not bochs. The patch mentioned in comment #1 (and attached here) is not a proper fix, but a hack. -- When bochs is built, the following command runs: file -L /usr/lib/../lib64//libXpm.so.4.11.0 and the expected output looks like this: /usr/lib/../lib64//libXpm.so.4.11.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped However, when sys-apps/file is compiled with USE=seccomp, and when it's called inside portage's sandbox, it crashes (due to seccomp violation?) and produces no output. The empty string obviously doesn't pass the filter, and libtool decides to create a static library instead of a shared object (as mentioned in comment #1), so we end up without libbx_x_gui.so. > Surprisingly, though, bochs compiles and links fine when I build it manually It's enough to take the src_compile stage out of the sandbox to make the build succeed, for example, if you run: ebuild /usr/portage/app-emulation/bochs/bochs-2.7.ebuild configure cd /var/tmp/portage/app-emulation/bochs-2.7/work/bochs-2.7 make make DESTDIR=/tmp/somewhere install you'll find libbx_x_gui.so under /tmp/somewhere, because the make command was called outside of the sandbox. Alternatively, if sys-apps/file is built with USE=-seccomp, it just works from under portage. -- I'll attach the strace of `file -L /usr/lib/../lib64//libXpm.so.4.11.0` when it runs from inside the sandbox and from the outside (file compiled with USE=seccomp).
Created attachment 758377 [details] strace of the file command (under portage's sandbox) This is how I collected this log: ebuild /usr/portage/app-emulation/bochs/bochs-2.7.ebuild configure cd /var/tmp/portage/app-emulation/bochs-2.7/work/bochs-2.7 Add this line to the beginning of Makefile: $(info $(shell strace file -L /usr/lib/../lib64//libXpm.so.4.11.0 2> /tmp/strace.log)) Run: ebuild /usr/portage/app-emulation/bochs/bochs-2.7.ebuild compile
Created attachment 758378 [details] strace of the file command (no sandbox, as root) This is how I collected this log: ebuild /usr/portage/app-emulation/bochs/bochs-2.7.ebuild configure cd /var/tmp/portage/app-emulation/bochs-2.7/work/bochs-2.7 Add this line to the beginning of Makefile: $(info $(shell strace file -L /usr/lib/../lib64//libXpm.so.4.11.0 2> /tmp/strace.log)) Run: make
Created attachment 758379 [details] strace of the file command (no sandbox, as portage) This is how I collected this log: ebuild /usr/portage/app-emulation/bochs/bochs-2.7.ebuild configure cd /var/tmp/portage/app-emulation/bochs-2.7/work/bochs-2.7 Add this line to the beginning of Makefile: $(info $(shell strace file -L /usr/lib/../lib64//libXpm.so.4.11.0 2> /tmp/strace.log)) Run: runuser -u portage -- make
