Menu

#1391 Plugins aren't compiled as shared objects on Kubuntu 14.04 x86-64

can't_reproduce
closed
None
1
2024-07-01
2017-09-07
No

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`
   ;;

Discussion

  • Volker Ruppert

    Volker Ruppert - 2018-02-11

    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.

     
    • Ruslan Kabatsayev

      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 for configure script.
      It seems though my original patch is not quite correct: the correct fix seems to be to add x86_64 to the case $host_cpu in alpha* | hppa*... list. Judging by the comment, that file_magic part should be used only for ARM, while it appears to be also for x86_64.

       
  • Ali Akcaagac

    Ali Akcaagac - 2018-09-06

    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.

     
  • Volker Ruppert

    Volker Ruppert - 2019-11-11

    Does this bug still exist?

     
  • Ruslan Kabatsayev

    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 -fi regardless of whether I apply this patch:

    --- aclocal.m4.orig 2019-11-14 06:16:06.239601367 +0000
    +++ aclocal.m4  2019-11-14 06:16:08.767637675 +0000
    @@ -2279,7 +2279,7 @@
     # This must be Linux ELF.
     linux*)
       case $host_cpu in
    
    -  alpha* | hppa* | i*86 | ia64* | m68* | mips* | powerpc* | sparc* | s390* | sh*)
    +  alpha* | hppa* | i*86 | x86_64 | ia64* | m68* | mips* | powerpc* | sparc* | s390* | sh*)
         lt_cv_deplibs_check_method=pass_all ;;
       *)
         # glibc up to 2.1.1 does not perform some relocations on ARM
    
     
  • Volker Ruppert

    Volker Ruppert - 2024-05-30

    Please try again with latest Bochs sources from Github.

     
  • Volker Ruppert

    Volker Ruppert - 2024-07-01
    • status: open --> closed
    • assigned_to: Volker Ruppert
     
  • Volker Ruppert

    Volker Ruppert - 2024-07-01

    No response, closing this item.

     

Log in to post a comment.

MongoDB Logo MongoDB