When configured with --enable-plugins option, Bochs compilation emits lots of warnings like this:
*** Warning: linker path does not have real file for library -lXpm.
*** 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 libXpm and none of the candidates passed a file format test
*** using a file magic. Last file checked: /usr/lib/x86_64-linux-gnu//libXpm.so.4.11.0
As a result, I fail to run Bochs because plugin like unmapped can't be found (it's a static lib). This appears due to failure to match output of file on the shared libraries. aclocal.m4 has this pattern:
lt_cv_deplibs_check_method='file_magic ELF [0-9][0-9]*-bit [LM]SB (shared object|dynamic lib )' ;;
But file actually prints this:
/lib/x86_64-linux-gnu//libgcc_s.so.1: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=17e0ff730623cbf6945960fdfc702975b9ce182a, stripped
Notice the extra space after LSB. After the following change compilation succeeds without these warnings, and Bochs runs normally:
--- ../bochs-svn.old/configure 2017-09-07 12:44:03.733610415 +0300
+++ configure 2017-09-07 12:39:56.158213451 +0300
@@ -5061,7 +5061,7 @@
lt_cv_deplibs_check_method=pass_all ;;
*)
# glibc up to 2.1.1 does not perform some relocations on ARM
- lt_cv_deplibs_check_method='file_magic ELF [0-9][0-9]*-bit [LM]SB (shared object|dynamic lib )' ;;
+ lt_cv_deplibs_check_method='file_magic ELF [0-9][0-9]*-bit [LM]SB +(shared object|dynamic lib )' ;;
esac
lt_cv_file_magic_test_file=`echo /lib/libc.so* /lib/libc-*.so`
;;
This configure script hack cannot be accepted since we generate it with autoconf.
Please try to do this on your host platform let us know if this issue is fixed then.
I don't quite understand what I should try to do. To apply this same change? But I already did this right before reporting this.
Anyway, the generation by autoconf shouldn't be a problem: I see this chunk present in
aclocal.m4, which seems to be one of the sources forconfigurescript.It seems though my original patch is not quite correct: the correct fix seems to be to add
x86_64to thecase $host_cpu in alpha* | hppa*...list. Judging by the comment, thatfile_magicpart should be used only for ARM, while it appears to be also for x86_64.I would like to confirm this issue with Fedora 28 (and soon 29), that, regardless what we do, that plugins will always be build as static .a files.
Excursion:
I use Bochs for Software development purposes and recently ran into an issue that plugins were missing under Fedora.
After digging through Redhat's Bugzilla, I found this bugreport that I asked to get reopened again.
https://bugzilla.redhat.com/show_bug.cgi?id=1283069
I was offered a rebuild of the SRPM and tried the RPMs that contained the final builds. Again the plugins were missing.
Diving through the SPEC files I discovered that there are some packaging issues and structural issues within that SPEC file (from Fedora). I made them aware of that situation by commenting further on that bugreport.
Later on (because I had to solve my own development stuff) I ended up compiling bochs from source using these command line arguments:
./configure \
--disable-static \
--enable-shared \
--prefix=/usr \
--enable-ne2000 \
--enable-pci \
--enable-all-optimizations \
--enable-clgd54xx \
--enable-sb16=linux \
--enable-3dnow \
--with-x11 \
--with-nogui \
--with-term \
--with-rfb \
--with-sdl2 \
--without-wx \
--enable-cpu-level=6 \
--enable-disasm \
--enable-e1000 \
--enable-x86-64 \
--enable-smp \
--enable-x86-debugger \
--enable-debugger \
--enable-plugins
So basicly it's a subset of the compile options used in Fedoras spec file. No matter what I do, I end up getting static linked plugins. Even enforcing --disable-static and --enable-shared didn't change anything. I commented on this at Bugzilla.
https://bugzilla.redhat.com/show_bug.cgi?id=1283069#c13
I then found this bugreport here and tried the patch provided here... This sadly doesn't do anything here. The plugins remain getting build as static files.
Fedora 28 / 29 (soon to be) x86_64 here.
It would be nice, if this issue can be addressed somehow.
Does this bug still exist?
It certainly still exists. I've just run Xubuntu 19.04 Live image in QEMU, downloaded bochs-20191112, and the problem still exists, unless I add x86_64 to the list of expected "good" host CPUs. Like here, but I'm not sure whether this will work completely because I keep getting "autoheader failed with exit status 1" from
autoreconf -firegardless of whether I apply this patch:Please try again with latest Bochs sources from Github.
No response, closing this item.