LinuxQuestions.org - [SOLVED] VirtualBox Install Script Fails On 32bit Slackware Current

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - VirtualBox Install Script Fails On 32bit Slackware Current (https://www.linuxquestions.org/questions/slackware-14/virtualbox-install-script-fails-on-32bit-slackware-current-4175606494/)

VirtualBox Install Script Fails On 32bit Slackware Current

I have a 32bit Slackware box that I keep on current. After some recent updates I can no longer use the VirtualBox .run script to install. I raised a bug report with VirtualBox but they think it is a problem with libgcc in Slackware.

To reproduce:
1. Install slackware current 32bit.
2. Download VirtualBox-5.1.22-115126-Linux_x86.run (Linux All Distributions i386)
3. Execute VirtualBox-5.1.22-115126-Linux_x86.run as root.

Installation will fail:

Code:

Verifying archive integrity... All good.

Uncompressing VirtualBox for Linux installation.............

VirtualBox Version 5.1.22 r115126 (2017-04-28T15:48:48Z) installer

Installing VirtualBox to /opt/VirtualBox

Python found: python, installing bindings...

vboxdrv.sh: failed: modprobe vboxdrv failed. Please use 'dmesg' to find out why.



There were problems setting up VirtualBox.  To re-start the set-up process, run

  /sbin/vboxconfig

as root.

vboxdrv.sh: failed: modprobe vboxdrv failed. Please use 'dmesg' to find out why.

Checking dmesg there are the following errors:

Code:

[ 1864.907681] vboxdrv: Unknown symbol __udivmoddi4 (err 0)

[ 1914.540632] vboxdrv: Unknown symbol __udivmoddi4 (err 0)

[ 1914.843340] vboxdrv: Unknown symbol __udivmoddi4 (err 0)

[ 1964.479924] vboxdrv: Unknown symbol __udivmoddi4 (err 0)

Using the amd64 version on Slackware64 current works perfectly.

Spent some time digging and there are differences in the libgcc.a library between 32bit and 64bit possibly pointing to undefined reference but I don't know enough to take this further at the moment.

On Slackware current 32 bit

Code:

root@slack-current:~# readelf -Ws /usr/lib/gcc/i586-slackware-linux/7.1.0/libgcc.a | grep udiv

File: /usr/lib/gcc/i586-slackware-linux/7.1.0/libgcc.a(_udivdi3.o)

    7: 00000000  290 FUNC    GLOBAL HIDDEN    1 __udivdi3

File: /usr/lib/gcc/i586-slackware-linux/7.1.0/libgcc.a(_udivmoddi4.o)

    7: 00000000  523 FUNC    GLOBAL HIDDEN    1 __udivmoddi4

File: /usr/lib/gcc/i586-slackware-linux/7.1.0/libgcc.a(_udiv_w_sdiv.o)

    7: 00000000    3 FUNC    GLOBAL HIDDEN    1 __udiv_w_sdiv

    20: 00000000    0 NOTYPE  GLOBAL DEFAULT  UND __udivmoddi4

    32: 00000000    0 NOTYPE  GLOBAL DEFAULT  UND __udivmoddi4

and on Slackware current 64bit

Code:

root@slack64-current:~# readelf -Ws /usr/lib64/gcc/x86_64-slackware-linux/7.1.0/libgcc.a | grep udiv

File: /usr/lib64/gcc/x86_64-slackware-linux/7.1.0/libgcc.a(_udivdi3.o)

    7: 0000000000000000  255 FUNC    GLOBAL HIDDEN    1 __udivti3

File: /usr/lib64/gcc/x86_64-slackware-linux/7.1.0/libgcc.a(_udivmoddi4.o)

    7: 0000000000000000  454 FUNC    GLOBAL HIDDEN    1 __udivmodti4

File: /usr/lib64/gcc/x86_64-slackware-linux/7.1.0/libgcc.a(_udiv_w_sdiv.o)

    7: 0000000000000000    3 FUNC    GLOBAL HIDDEN    1 __udiv_w_sdiv

So on 32bit is this indicating some undefined references to __udivmoddi4? I don't know if this is the problem or a red herring though.

Anyone have any ideas?

Not that I can help here, but I'm linking to your bug report and a forum post about this issue... just to consolidate things and hopefully make it easier to find a resolution for 32bit users.

We noticed this in an earlier thread:

http://www.linuxquestions.org/questi...9/#post5707211

No solution so far, except to switch to a 64-bit VM.

A dirty little patch, workaround until a better solution appears:

Code:

File: /usr/src/vboxhost-5.1.22/vboxdrv/linux/SUPDrv-linux.c

Code:

--- SUPDrv-linux.c.orig    2016-08-17 11:35:33.000000000 +0300

+++ SUPDrv-linux.c    2017-05-24 15:11:58.376631464 +0300

@@ -1409,6 +1409,9 @@

    return fFlags;

 }

 

+void __udivmoddi4(void)

+{

+}

 

 module_init(VBoxDrvLinuxInit);

 module_exit(VBoxDrvLinuxUnload);

I am not sure why this stub is needed, maybe because __udivmoddi4 from libgcc is inline function. I tested in a guest Slackware-current 32-bit VM (the host is Slackware64-current)

Code:

Linux vbox 4.9.29-smp #2 SMP Sun May 21 01:13:37 CDT 2017 i686

Now I am installing Slackware-current in the guest 32-bit VM, slow but seems to work.

I can confirm that this patch works on my venerable HP desktop running Slackware 32 bit. Virtuals up and running again. Thanks ppencho.

So does VirtualBox not really need __udivmoddi4? Looks like my suspicions about libgcc on 32bit could be correct? I've been trying to build gcc using gcc.Slackbuild myself to dig deeper and hopefully come up with a fix there but the build fails. I'm currently hunting through the build log to find out why. I don't have much time to spend on this so could be a while.

Maybe the VirtualBox kernel module uses __udivmoddi4 (libgcc) as an inline function (this is my speculation). And for some reason it expects __udivmoddi4 as an external dependency but it does not need that function to run. My stub does not shadow the original libgcc __udivmoddi4, it has different prototype (no parameters and return value).

The latest version of VirtualBox 5.1.24 has a fix for this problem. Now installs without issue on 32bit Slackware.