Run-time problem with VirtualBox on RHEL 6.7

Discussions related to using the OSE version of VirtualBox.
Post Reply
RicV
Posts: 96
Joined: 25. Aug 2015, 17:58
Primary OS: Ubuntu other
VBox Version: OSE self-compiled
Guest OSses: Linux *.*, Win*
Location: Lake Tahoe, California

Run-time problem with VirtualBox on RHEL 6.7

Post by RicV »

I have been happily building and using VirtualBox OSE for some time now — on an Ubuntu 14 host. However, my end user needs to run it on RHEL 6.7, and that has been giving me a lot of trouble.

I was able to set up a VirtualBox 5.0.36 build environment on RHEL67, though not with standard Qt48 packages (from RPM files, since I have not found a standard 4.8 package in any repo). Instead, I had to build Qt 4.8.5 myself, but having done so (and resolving a few other package dependencies), I am now able to build the VirtualBox installer. First I do kmk all, then I use the attached script to make the installer (.run file). This is necessary because I had to make a couple of patches in VBox (DevPciIch9.cpp) for his use case. So far, so good.

What I have not been able to achieve is to run this build in a normal way on RHEL67. Somehow, it is not finding my Qt48 libraries, presumably because the /usr/lib64 links still point to the 4.6 package. This manifests as a missing symbol in the Qt library.

More on that below, but first: this same user was able run VirtualBox 5.0.14 (from an RPM installation), on the same server, despite not having Qt 4.8 installed. I presume, therefore, that the VirtualBox installer within the RPM file includes its own copy of Qt48 and maybe other things.

Is this assumption correct? And if so, is there a way to make my own installer with all requisite libraries bundled like the RPM installer has?

Otherwise, I am hoping for some help sorting out my run-time issue.

Now, if I log in as root and set LD_LIBRARY_PATH to point to either the Qt 4.8.5 libraries that I built, or to the Qt48 which I installed from RPM files (at /opt/rh/qt48/root/usr/lib64), then I can run the VirtualBox GUI. I realize that running VirtualBox as root is never a good idea, but it proves that resolving the library location solves my problem.

However, when I run VBox as a regular user, LD_LIBRARY_PATH does NOT redirect the search as it does when logged in as root. I presume this is because VirtualBox runs as a root process, even when launched from a user account, and LD_LIBRARY_PATH is not being passed to that root process. See attachment.

I have spent some time trying to get LD_LIBRARY_PATH setup in the environment, and now when I log in as root it is correctly set. But that does not solve my problem when running VirtualBox from a user account. I presume this is because the spawned root process does not have a shell of any sort, and therefore does not set up the shell environment.

So my second question is whether there is some other clever way to deal with the library location problem? Of course, I could go change the links in /usr/lib64 but I worry that might cause harm to the desktop or other graphical applications.

Any advice would be most appreciated.
Attachments
vbox_LD_LIBRARY_PATH.txt
(975 Bytes) Downloaded 44 times
configure.log
(27.07 KiB) Downloaded 64 times
Perryg
Site Moderator
Posts: 34369
Joined: 6. Sep 2008, 22:55
Primary OS: Linux other
VBox Version: OSE self-compiled
Guest OSses: *NIX

Re: Run-time problem with VirtualBox on RHEL 6.7

Post by Perryg »

Define the right qt in your ./configure statement. See example below

Code: Select all

./configure --with-qt-dir=/opt/qt56
RicV
Posts: 96
Joined: 25. Aug 2015, 17:58
Primary OS: Ubuntu other
VBox Version: OSE self-compiled
Guest OSses: Linux *.*, Win*
Location: Lake Tahoe, California

Re: Run-time problem with VirtualBox on RHEL 6.7

Post by RicV »

Thanks, Perry. I did indeed do that on the build machine, as evidenced by the configure.log that I had attached. That's how I got it built in the first place. My problem is on the test machine where I installed VirtualBox, and now want to run it. There the VirtualBox GUI can't run because it can't find the right Qt libraries.
Perryg
Site Moderator
Posts: 34369
Joined: 6. Sep 2008, 22:55
Primary OS: Linux other
VBox Version: OSE self-compiled
Guest OSses: *NIX

Re: Run-time problem with VirtualBox on RHEL 6.7

Post by Perryg »

Look at the results of the following to see if you are having an issue with compatibility to the qt package.

Code: Select all

ldd /usr/lib/VirtualBox/VirtualBox.so
Usually it happens if you install more than one qt package ( different versions ) or the location is not standard.

Your install may not have the caps in the VirtualBox name. Adjust as needed.
Martin
Volunteer
Posts: 2560
Joined: 30. May 2007, 18:05
Primary OS: Fedora other
VBox Version: PUEL
Guest OSses: XP, Win7, Win10, Linux, OS/2

Re: Run-time problem with VirtualBox on RHEL 6.7

Post by Martin »

Why did you try 5.0.36? The latest versioin is currently is 5.1.22 (and 5.0.40 in the no longer supported 5.0 branch)
RicV
Posts: 96
Joined: 25. Aug 2015, 17:58
Primary OS: Ubuntu other
VBox Version: OSE self-compiled
Guest OSses: Linux *.*, Win*
Location: Lake Tahoe, California

Re: Run-time problem with VirtualBox on RHEL 6.7

Post by RicV »

I have been out sick for a few days, and just getting back to work now.
Perryg wrote:Look at the results of the following to see if you are having an issue with compatibility to the qt package.

Code: Select all

ldd /usr/lib/VirtualBox/VirtualBox.so
Usually it happens if you install more than one qt package ( different versions ) or the location is not standard.

Your install may not have the caps in the VirtualBox name. Adjust as needed.
I had done this before I started the thread, and is how I came to the conclusion that there is a Qt compatibility issue. By default, it was picking up Qt 4.6 from the system, so I set LD_LIBRARY_PATH to point to the Qt48 (either installed from RPM or built by myself).

When logged in as root, ldd shows Qt48, the VirtualBox GUI runs (despite the warning shown below), and I can even start a VM. However, when logged in as a normal user, ldd still shows Qt48, but the VirtualBox GUI is still picking up the old Qt.

Code: Select all

bash-4.1$ ldd /opt/VirtualBox/VirtualBox.so | grep libQt
	libQtCore.so.4 => /usr/lib64/libQtCore.so.4 (0x00007f37ab35f000)
	libQtGui.so.4 => /usr/lib64/libQtGui.so.4 (0x00007f37aa736000)
	libQtOpenGL.so.4 => /usr/lib64/libQtOpenGL.so.4 (0x00007f37aa472000)
bash-4.1$ export LD_LIBRARY_PATH=/opt/rh/qt48/root/usr/lib64/
bash-4.1$ ldd /opt/VirtualBox/VirtualBox.so | grep libQt
	libQtCore.so.4 => /opt/rh/qt48/root/usr/lib64/libQtCore.so.4 (0x00007fde66b90000)
	libQtGui.so.4 => /opt/rh/qt48/root/usr/lib64/libQtGui.so.4 (0x00007fde65edd000)
	libQtOpenGL.so.4 => /opt/rh/qt48/root/usr/lib64/libQtOpenGL.so.4 (0x00007fde65be3000)
bash-4.1$ VirtualBox
VirtualBox: supR3HardenedMainGetTrustedMain: dlopen("/opt/VirtualBox/VirtualBox.so",) failed: /opt/VirtualBox/VirtualBox.so: undefined symbol: _ZN15QSplitterHandle11resizeEventEP12QResizeEvent
bash-4.1$ su
Password: 
[root@mnm-med-r730e VirtualBox]# ldd /opt/VirtualBox/VirtualBox.so | grep libQt
	libQtCore.so.4 => /usr/lib64/libQtCore.so.4 (0x00007fcef7ae4000)
	libQtGui.so.4 => /usr/lib64/libQtGui.so.4 (0x00007fcef6ebb000)
	libQtOpenGL.so.4 => /usr/lib64/libQtOpenGL.so.4 (0x00007fcef6bf7000)
[root@mnm-med-r730e VirtualBox]# export LD_LIBRARY_PATH=/opt/rh/qt48/root/usr/lib64/
[root@mnm-med-r730e VirtualBox]# ldd /opt/VirtualBox/VirtualBox.so | grep libQt
	libQtCore.so.4 => /opt/rh/qt48/root/usr/lib64/libQtCore.so.4 (0x00007fce4ea2b000)
	libQtGui.so.4 => /opt/rh/qt48/root/usr/lib64/libQtGui.so.4 (0x00007fce4dd78000)
	libQtOpenGL.so.4 => /opt/rh/qt48/root/usr/lib64/libQtOpenGL.so.4 (0x00007fce4da7e000)
[root@mnm-med-r730e VirtualBox]# VirtualBox
Qt WARNING: QGtkStyle was unable to detect the current GTK+ theme.
Qt WARNING: Qt: Session management error: None of the authentication protocols specified are supported
I believe the reason is that VirtualBox is actually a link, which points to a script, which runs the actual VirtualBox GUI. Because the actual program that's run has the 's' flag set, it runs as root despite having been launched by a user, and LD_LIBRARY_PATH is not being passed from the user env to the root process env.

Code: Select all

bash-4.1$ which VirtualBox
/usr/bin/VirtualBox
bash-4.1$ ls -la /usr/bin/VirtualBox
lrwxrwxrwx 1 root root 23 Jun 10 11:39 /usr/bin/VirtualBox -> /opt/VirtualBox/VBox.sh
bash-4.1$ ls -la /opt/VirtualBox/VirtualBox
-r-s--x--x 1 root root 35280 May 30 14:58 /opt/VirtualBox/VirtualBox
bash-4.1$ 
Furthermore, since the root process does not have a shell of any sort, setting LD_LIBRARY_PATH in the shell initialization does not help.

I have confirmed that installing VirtualBox from an RPM file does work from a user account, despite the system having Qt46 rather than Qt48. This supports my assumption that the RPM file includes Qt48 and it's not relying on the system environment for that.

If I could find a way to build the installer with Qt48 bundled, as in the RPM file, that would be ideal. But I am certainly open to other ideas.
RicV
Posts: 96
Joined: 25. Aug 2015, 17:58
Primary OS: Ubuntu other
VBox Version: OSE self-compiled
Guest OSses: Linux *.*, Win*
Location: Lake Tahoe, California

Re: Run-time problem with VirtualBox on RHEL 6.7

Post by RicV »

Martin wrote:Why did you try 5.0.36? The latest versioin is currently is 5.1.22 (and 5.0.40 in the no longer supported 5.0 branch)
Short answer, it's not my decision. My end user is already using 5.0.36 for numerous verification activities across a large team, and they are not yet prepared to cut over the 5.1 at this point in their project. I need to fit my solution into their existing environment for now until they are ready to make the switch.
RicV
Posts: 96
Joined: 25. Aug 2015, 17:58
Primary OS: Ubuntu other
VBox Version: OSE self-compiled
Guest OSses: Linux *.*, Win*
Location: Lake Tahoe, California

Re: Run-time problem with VirtualBox on RHEL 6.7

Post by RicV »

Just to close the loop, in case someone else stumbles across this thread some day...

I declared defeat in attempting to run my own build of VirtualBox 5.0.x OSE on RH6 once I found that it just plain worked on RH7. I was able to build a proper installer on RH6.7, and then run that installer on a RH7.3 server (two different ones, in fact), and everything seems to be working fine.

I do know someone who is able to build and run VirtualBox 5.0.x OSE on RH6. One key difference is that they are building an unhardened version, which AFAIK is OK since they do not distribute it outside of their immediate working group. I, on the other hand, may need to distribute my installer to end users in other organizations, so I always build a hardened version. I do not know if that is the only difference, but I find it plausible to explain the difference.
Post Reply