+++ This bug was initially created as a clone of Bug #1092192 +++ NOTE: Issue still there even in F23 with the latest bochs-debugger.x86_64 2.6.2-9.fc23 rpm Description of problem: bochs-debugger fails on launch, due to a missing plugin module: Version-Release number of selected component (if applicable): bochs-debugger-2.6.2-5.fc20.x86_64 How reproducible: 100% Steps to Reproduce: 1. Run bochs-debugger Actual results: ======================================================================== Bochs x86 Emulator 2.6.2 Built from SVN snapshot on May 26, 2013 Compiled on Aug 14 2013 at 13:53:31 ======================================================================== 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 0x7fe9019dae10 00000000000i[PLGIN] loaded plugin libbx_unmapped.so 00000000000i[ ] lt_dlhandle is 0x7fe9019db960 00000000000i[PLGIN] loaded plugin libbx_biosdev.so 00000000000i[ ] lt_dlhandle is 0x7fe9019dc390 00000000000i[PLGIN] loaded plugin libbx_speaker.so 00000000000i[ ] lt_dlhandle is 0x7fe9019dcc60 00000000000i[PLGIN] loaded plugin libbx_extfpuirq.so 00000000000i[ ] lt_dlhandle is 0x7fe9019dd4b0 00000000000i[PLGIN] loaded plugin libbx_parallel.so 00000000000i[ ] lt_dlhandle is 0x7fe9019df070 00000000000i[PLGIN] loaded plugin libbx_serial.so 00000000000i[ ] lt_dlhandle is (nil) 00000000000p[ ] >>PANIC<< dlopen failed for module 'iodebug': file not found Expected results: libbx_iodebug.so should have been loaded Additional info: --- Additional comment from Fedora End Of Life on 2015-05-29 07:42:05 EDT --- This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. --- Additional comment from Fedora End Of Life on 2015-06-29 16:20:34 EDT --- Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
I have cross checked by compiling the latest svn version. And what I feel is that bochs-debugger was build with --enable-plugins and inturn iodebug shared library was not included in the package. So either compile without --enable-plugins so that iodebug is part of the bochs-debugger internally or if compiling with --enable-plugins then please include iodebug shared library in the rpm of bochs-debugger. ELSE, bochs and bochs-debugger rpms have been compiled with different settings wrt --enable-plugins, and the binary compiled without --enable-plugins is wrongly checking for plugins because of some entry in conf file Just my casual thoughts, I haven't looked into things in detail. ????
(In reply to hanishkvc from comment #1) > I have cross checked by compiling the latest svn version. And what I feel is > > that bochs-debugger was build with --enable-plugins and inturn iodebug > shared library was not included in the package. > > So either compile without --enable-plugins so that iodebug is part of the > bochs-debugger internally or if compiling with --enable-plugins then please > include iodebug shared library in the rpm of bochs-debugger. > > ELSE, bochs and bochs-debugger rpms have been compiled with different > settings wrt --enable-plugins, and the binary compiled without > --enable-plugins is wrongly checking for plugins because of some entry in > conf file > > Just my casual thoughts, I haven't looked into things in detail. > > ???? Rather I was able to get bochs working with builtin debugger in both of below cases with latest svn release. ./configure --enable-debugger --enable-disasm --with-all-libs --enable-e1000 --enable-sb16 --enable-plugins ./configure --enable-debugger --enable-disasm --with-all-libs --enable-e1000 --enable-sb16
Rather, as I was in the middle of some other debugging, I didn't notice the problem which was right in front of me, that's why I gave a alternate possible problem also. But now that I had a relook at the actual error. The issue is that bochs-debugger was compiled with --enable-plugins so iodebug is built has a shared library. But the bochs-debugger.rpm doesn't contain the same. Please either include the iodebug.so file or else build bochs-debugger without --enable-plugins. And that will fix this problem. Not sure why for all this time it has not been done. Please fix this. Also maybe while in the middle of it, also upgrade to the latest version of bochs i.e 2.6.8 (instead of this old 2.6.2 version).
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Can this bug get reopened ? The issue still exists in Fedora 28/29
Please test the build here and let me know if it works for you: https://fedorapeople.org/~limb/bochs/ If you need something other than f28 x86_64, I can provide that. :)
It would be nice, if you could provide f29 (29) version of x86_64 rpms since I don't run f28 anymore :) I will test it and report back, once I can get hold of it...
I just recompiled from the provided f28 source. rpmbuild -rb bochs-2.6.9-10.fc28.src.rpm and received a similar issue: ======================================================================== Bochs x86 Emulator 2.6.9 Built from SVN snapshot on April 9, 2017 Compiled on Sep 5 2018 at 10:35:15 ======================================================================== 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 (nil) 00000000000p[ ] >>PANIC<< dlopen failed for module 'unmapped' (libbx_unmapped.so): file not found 00000000000e[SIM ] notify called, but no bxevent_callback function is registered 00000000000e[SIM ] notify called, but no bxevent_callback function is registered ======================================================================== Bochs is exiting with the following message: [ ] dlopen failed for module 'unmapped' (libbx_unmapped.so): file not found ======================================================================== 00000000000i[SIM ] quit_sim called with exit code 1
Ok here the interesting part: 1) I just extracted the tar.gz from the src.rpm and extracted it. 2) I ran ./configure --prefix=/tmp/ssss --enable-plugins ; make ; make install 3) A /tmp/sss/lib/bochs/plugins directory was created during installation, that included *all* plugins. This type of /lib{64}/bochs/plugins directory is entitrely missing when compiled using rpmbuild -rb *.src.rpm Conclusion: The spec file might contain some errors regarding the handling of plugins. I belive the problem is somewhere here: %files %doc _installed-docs/* README-* %{_bindir}/bochs %{_bindir}/bximage %{_bindir}/bxhub # Note: must include *.la in %%{_libdir}/bochs/plugins/ #%{_libdir}/bochs/ %{_mandir}/man1/bochs.1* %{_mandir}/man1/bximage.1* %{_mandir}/man5/bochsrc.5* %dir %{_datadir}/bochs/ %{_datadir}/bochs/keymaps/ Must not include *.la in... plugins dir... And why is the entire plugins dir commented out then ? This is not the correct approach. I'd better have the obsolete *.la files rather than *no* plugins at all... I am going to test this...
I think I figured it out (after some trial and error and some time to understand this spec). As it looks like, the comment of the line: #%{_libdir}/bochs/ Is indeed right (must be some historical reasons and bochs might got split up at some time). The spec builds different rpm's during different processes. The main bochs has no plugins enabled, therefore the above line (if uncommented) will complain about the missing path and aborts creating an rpm file. Later on within the spec, the bochs-debugger will be created by applying --enable-plugins to the configure script ... *BUT* ... only the bindir is put into the rpm (but the plugins got build at that stage too and get abandoned). Missing the libdir/bochs in the spec. That means we need to make sure that the plugins are put into the bochs-debugger rpm package. Adjustments: %files debugger %{_bindir}/bochs-debugger %{_libdir}/bochs/ <--- add this one The last line libdir/bochs has to be added. This ensures that during the bochs-debugger stage, that the plugins are all put into the rpm and be available during runtime. *There is another bigger issue* 1) The bochs-debugger is build. The binary moves from bochs to bochs-devel. Then a make distclean is initiated. The previously build plugins directory and all its plugins get removed. You build them, then you remove them by make dist-clean. 2) The bochs-gdb gets build. The binary moves from bochs to bochs-gdb. Then a make distclean is initiated. No plugins build here because it's not part of the configure options. 3) The bochs itsel is build. No plugins build here because it's not part of the configure options. The make dist-clean in 1) is wrong. It will remove the entire plugins directory that is necessary to bundle bochs-debugger. Also the libdir mentioned above is missing. Looks like the spec file has some *critical* issues... So what happens here is this: 1) You build bochs-debugger... You enable the plugins that get compiled... You move the bochs exe to bochs-debugger and then abandon the plugins via make dist-clean. The sequence for this part is incomplete because the debugger relies on the plugins. 2) You use the same sources to build the bochs-gdb. Without plugins (because they are not necessary here). Once the binary is build you rename the bochs.exe to bochs-gdb, which resides side by side with the previously build bochs-debugger. 3) You use the same sources to build the bochs. Without plugins... You get side by side the bochs, bochs-gdb, bochs-debugger... Then it comes to packaging. The libdir/bochs got commented because the spec file complains about missing lib/bochs lib64/bochs. Everything works! Spec file is happy! bochs get packaged in a couple of set of rpm files... bins are there, bios are there, docs are there... only the plugins for the debugger are abandoned entirely. I am not sure, howto solve this rather than compiling bochs from sources atm. Somehow this spec file might have worked in the past... until the demands and requirements of Fedora changed. At one particular point someone changed the spec file to a degree where the error (of skipping the plugins) slipped in (unnoticed) until someone opened the bug and later, where I ran into the same issues, commented on this bug. Is there any way to fix this ?
Another issue found within the spec: --enable-clgd54xx \ --enable-sb16=linux \ --enable-3dnow --with-x11 \ --with-nogui \ The configure option --enable-3dnow has no line-break at the end, so the other options alltogether get abandoned... This may affect that the plugins are skipped because the --enable-plugins follows after the main block with configure options...
Coming back to the plugins thing. It seems that bochs always builds the plugins as static library (.a) plugins, while the runtime expects shared library (.so) plugins. No matter if you enforce options like --disable-static --enable-shared, bochs always builds them staticly. This seem to be a bochs configure issue.
https://fedorapeople.org/~limb/bochs/ Try the newest version uploaded here. The f29 build. :)
This bug appears to have been reported against 'rawhide' during the Fedora 30 development cycle. Changing version to '30.
bochs-2.6.9-12.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-641ebacbde
bochs-2.6.9-12.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-9e6ca8592f
bochs-2.6.9-12.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-641ebacbde
bochs-2.6.9-12.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-9e6ca8592f
bochs-2.6.9-12.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.
bochs-2.6.9-12.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.