Bug 4617

Created attachment 1825 [details]
0002-vgdrvLinuxIOCtl-Always-return-standard-Linux-errno-v.patch

Created attachment 1826 [details]
vbox-rpmfusion-fix.patch

"While working on the virtualbox guest kernel drivers I hit a problem
yesterday which took me most of the day to figure out.

The problem is that the VBoxOGL.so and VBoxEGL.so libs as built by
the rpmfusion package are broken.

This is caused by 2 broken patches, the attached patch removes
on 1 patch and fixes the other.

It also adds 2 patches which will be necessary to deal with some
kernel API changes which I plan to do as part of the upstreaming
process (guest-additions build with these changes will still work
with the old kernel drivers). I will submit these changes
upstream soon (I've limited internet access atm).

Note that these patches only fixes the VBoxOGL.so and VBoxEGL.so libs
these are libGL.so.1 and libEGL.so.0 replacement libs and as
such should NOT be installed directly in libdir they should
be in libdir/virtualbox or some-such and then a startup service
should detect if 3d-passthru is active and then add / remove
symlinks to those 2 libs to /var/lib/virtualbox and run ldconfig
(combined with an ld.so.conf.d file pointing to /var/lib/virtualbox)
as the official virtualbox guest additions are doing. This currently
too is broken in the rpmfusion pkgs and the attached patches do
not fix this. "

Ah I have to fix this problem ...

Due the remove of VirtualBox-5.0.22-guest_soname.patch , first I'm
building here [1] 

[1]
https://copr.fedorainfracloud.org/coprs/sergiomb/vboxfor23/builds/

From my understanding, extracting the VirtualBox-guest-additions-5.1.20-2.fc26.x86_64.rpm from the copr repo shows:

readelf -a VBoxEGL.so |grep SONAME
 0x000000000000000e (SONAME)             Library soname: [VBoxEGL.so]
readelf -a VBoxOGL.so |grep SONAME
 0x000000000000000e (SONAME)             Library soname: [VBoxOGL.so]

So it will not conflict with normal libGL.so.1 and libEGL.so.1 in the RPM dependency process (which the removed patch was originally attempting to fix). But as Hans said, they should not be installed in the system path (%{_libdir}), but as %{_libdir}/virtualbox.
This would be a step to have the package fixed.

@Hans, can you help Sergio to sort the libraries that would need to be in %{_libdir}/virtualbox
The next step is probably to make them libglvnd compliant if possible... Use LD_LIBRARY_PATH as appropriate or ldconfig as you pointed out.

Hi,

Right as mentioned in my email my patches are incomplete! They just fix the VBoxOGL.so build
to generate a proper, working libGL.so.1 replacement you still need to move it to a subdir under libdir and restore the startup-script from upstream which detects if 3D passthrough is active and then puts them it in the ld.so.conf path.

I'm still working on the kernel driver and as such I don't have time to do this myself atm (that should change in a week or 2).

Both VBoxOGL.so and VBoxEGL.so conflict with the standard libs, as such they should be moved to a subdir under libdir and not be directly under libdir.

Note that the latest upstream additions only patch VBoxOGL.so into the library path VBoxEGL.so is known to be broken so they never use it (as such we might just as well not ship it).

Upstream does the ldconfig magic by dropping a "00vboxvideo.conf" file in /etc/ld.so.conf.d which contains:

[hans@localhost ~]$ cat /etc/ld.so.conf.d/00vboxvideo.conf 
/var/lib/VBoxGuestAdditions/lib

And they execute /opt/VBoxGuestAdditions-5.1.24/init/vboxadd add boot which calls "/usr/bin/VBoxClient --check3d" and if that succeeds it adds a symlink to VBoxOGL.so to /var/lib/VBoxGuestAdditions/lib resp. if it fails removes the symlink and if any changes were made it runs ldconfig after adding / removing the symlink.

We should probably do something similar as we don't want to run ldconfig every boot, so using the symlink to remember the previous state is useful and by mimicking upstream here (although I would not use the entire vboxadd sysv init script) we make it easier for upstream to debug things when they get bug-reports for people using our packages.

TL;DR: besides my patches, you also need to move libOGL.so out of libdir and add some systemd unit to add / remove a symlink to it to /var/lib/VBoxGuestAdditions/lib (and run ldconfig if things have changed).

Regards,

Hans

p.s.

I see that vbox-rpmfusion-fix.patch still comments out the removal of the X / GL headers I don't think that is necessary anymore that is from an earlier attempt at fixing VBoxOGL.so where I completely dropped
VirtualBox-5.0.18-xserver_guest.patch instead of fixing it, removing the headers _should_ be fine.

A quick update on this, upstream vbox has nacked my approach to return a standard errno from the ioctl, so the 0001-... and 0002-... patches should be dropped.

The fixes in the last patch to VirtualBox-5.0.18-xserver_guest.patch to keep VBOX_NO_NATIVEGL and dropping the soname patch are still necessary to build a proper VBoxOGL.so, and this still needs the discussed work.

(In reply to Hans de Goede from comment #5)
> Hi,
> 
> Right as mentioned in my email my patches are incomplete! They just fix the
> VBoxOGL.so build
> to generate a proper, working libGL.so.1 replacement you still need to move
> it to a subdir under libdir and restore the startup-script from upstream
> which detects if 3D passthrough is active and then puts them it in the
> ld.so.conf path.
> 
> I'm still working on the kernel driver and as such I don't have time to do
> this myself atm (that should change in a week or 2).
> 
> Both VBoxOGL.so and VBoxEGL.so conflict with the standard libs, as such they
> should be moved to a subdir under libdir and not be directly under libdir.
> 
> Note that the latest upstream additions only patch VBoxOGL.so into the
> library path VBoxEGL.so is known to be broken so they never use it (as such
> we might just as well not ship it).
> 
> Upstream does the ldconfig magic by dropping a "00vboxvideo.conf" file in
> /etc/ld.so.conf.d which contains:
> 
> [hans@localhost ~]$ cat /etc/ld.so.conf.d/00vboxvideo.conf 
> /var/lib/VBoxGuestAdditions/lib
> 
> And they execute /opt/VBoxGuestAdditions-5.1.24/init/vboxadd add boot which
> calls "/usr/bin/VBoxClient --check3d" and if that succeeds it adds a symlink
> to VBoxOGL.so to /var/lib/VBoxGuestAdditions/lib resp. if it fails removes
> the symlink and if any changes were made it runs ldconfig after adding /
> removing the symlink.
>

Hello, First just to inform I'm in holidays so I'm a little less responsive ... and also if you want, you may modify the package.
 
Finally, Thanks. Now I understand this change and what should I do. BTW this happens in vbox around 5.0.22 and I think other distros also doesn't deal with GL.so(s) correctly   
 

 
> We should probably do something similar as we don't want to run ldconfig
> every boot, so using the symlink to remember the previous state is useful
> and by mimicking upstream here (although I would not use the entire vboxadd
> sysv init script) we make it easier for upstream to debug things when they
> get bug-reports for people using our packages.
> 
> TL;DR: besides my patches, you also need to move libOGL.so out of libdir and
> add some systemd unit to add / remove a symlink to it to
> /var/lib/VBoxGuestAdditions/lib (and run ldconfig if things have changed).
> 
> Regards,
> 
> Hans

Hi,

So I've just finished packaging the vbox guest-additions for Fedora proper:

https://bugzilla.redhat.com/show_bug.cgi?id=1481630

I've solved the OpenGL issue there by putting all libs under %{_libdir}/VBoxGuestAdditions and
offering a script to run apps through OpenGL passthru like this:

VBoxOGLRun glxgears

I've opted to go this route rather then auto-enable at boot since OpenGL passthru has some issues with some apps (and does not work when using gnome-shell + other opengl apps on top).

With this fix, the ldconfig calls can be moved from the %post scripts, I've also removed VirtualBox-guest.modules and the restart of modules-load.service since all guest modules will properly autoload so this is not necessary.

Feel free to pick up these changes for the rpmfusion pkgs :)

Regards,

Hans

moved to  

https://bugzilla.redhat.com/show_bug.cgi?id=1481630