Bug 834127 - Review Request: VirtualGL - A toolkit for displaying OpenGL applications to thin clients
Summary: Review Request: VirtualGL - A toolkit for displaying OpenGL applications to t...
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Orion Poplawski
QA Contact: Fedora Extras Quality Assurance
Depends On: 839060
Blocks: 827167
TreeView+ depends on / blocked
Reported: 2012-06-20 22:34 UTC by Gary Gatling
Modified: 2013-11-04 12:42 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-02-05 02:58:53 UTC
Type: ---
orion: fedora-review+

Attachments (Terms of Use)
Updated .spec - fixes vglrun for 32-bit binaries on 64-bit OS (5.25 KB, text/x-rpm-spec)
2012-10-23 18:50 UTC, starfall
no flags Details
Updated vglrun script (10.02 KB, application/octet-stream)
2012-10-24 00:07 UTC, starfall
no flags Details
Updated vglrun script - fixed lib64 test (10.01 KB, application/octet-stream)
2012-10-24 10:18 UTC, starfall
no flags Details

Description Gary Gatling 2012-06-20 22:34:26 UTC
Spec URL: http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora17/spec/1/VirtualGL.spec
SRPM URL: http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora17/SRPMS/VirtualGL-2.3-2.fc17.src.rpm
Description: VirtualGL is a toolkit that allows most Unix/Linux OpenGL applications to be
remotely displayed with hardware 3D acceleration to thin clients, regardless
of whether the clients have 3D capabilities, and regardless of the size of the
3D data being rendered or the speed of the network.

Using the vglrun script, the VirtualGL "faker" is loaded into an OpenGL
application at run time.  The faker then intercepts a handful of GLX calls,
which it reroutes to the server's X display (the "3D X Server", which
presumably has a 3D accelerator attached.)  The GLX commands are also
dynamically modified such that all rendering is redirected into a Pbuffer
instead of a window.  As each frame is rendered by the application, the faker
reads back the pixels from the 3D accelerator and sends them to the
"2D X Server" for compositing into the appropriate X Window.

VirtualGL can be used to give hardware-accelerated 3D capabilities to VNC or
other X proxies that either lack OpenGL support or provide it through software
rendering.  In a LAN environment, VGL can also be used with its built-in
high-performance image transport, which sends the rendered 3D images to a
remote client (vglclient) for compositing on a remote X server.  VirtualGL
also supports image transport plugins, allowing the rendered 3D images to be
sent or captured using other mechanisms.

VirtualGL is based upon ideas presented in various academic papers on
this topic, including "A Generic Solution for Hardware-Accelerated Remote
Visualization" (Stegmaier, Magallon, Ertl 2002) and "A Framework for
Interactive Hardware Accelerated Remote 3D-Visualization" (Engel, Sommer,
Ertl 2000.)

Fedora Account System Username: gsgatlin@eos.ncsu.edu

Comment 1 Gary Gatling 2012-06-20 22:37:58 UTC
Hello. This package was actually created by Robin Lee. It is a dependency for 


This is one of the first packages I have submitted and I need a sponsor.

Comment 2 Orion Poplawski 2012-07-03 18:36:29 UTC
Couple initial comments:

- Please update to 2.3.1
- Blank lines between changelog entries
- mesa-libGLU-devel will bring in libX11-devel, libXext-devel, and mesa-libGL-devel, so no need to list them.
- The -devel Requires need %{?_isa} added
- You need to use %cmake28 in EPEL6
- I would change the cmake conditional to:

%if 0%{?rhel} == 6
BuildRequires: cmake28
BuildRequires: cmake


%if 0%{?rhel} == 6
%cmake28 -DTJPEG_INCLUDE_DIR=%{_includedir} \
%cmake -DTJPEG_INCLUDE_DIR=%{_includedir} \

As that is the exceptional condition.

- I recommend doing out of tree builds for cmake, but this isn't necessary.


VirtualGL.x86_64: E: invalid-soname /usr/lib64/libdlfaker.so libdlfaker.so
VirtualGL.x86_64: E: invalid-soname /usr/lib64/librrfaker.so librrfaker.so
VirtualGL.x86_64: E: invalid-soname /usr/lib64/libgefaker.so libgefaker.so

These get preloaded via the vglrun wrapper script.  I think they should go into %{_libdir}/VirtualGL.

VirtualGL.x86_64: W: shared-lib-calls-exit /usr/lib64/librrfaker.so exit@GLIBC_2.2.5

can be ignored

VirtualGL.x86_64: E: incorrect-fsf-address /usr/share/doc/VirtualGL-2.3/LGPL.txt

contact upstream and tell them to fix that.

Comment 3 Gary Gatling 2012-07-06 17:38:48 UTC
Your comment was:

    Ok. It seems there are problems....

    Atrtempt #2 which is currently broken and unuseable. :(



    [gsgatlin@nom0047567 ~]$ optirun glxgears
    ERROR: ld.so: object 'libdlfaker.so' from LD_PRELOAD cannot be preloaded: ignored.
    ERROR: ld.so: object 'librrfaker.so' from LD_PRELOAD cannot be preloaded: ignored.
    Running synchronized to the vertical refresh.  The framerate should be
    approximately the same as the monitor refresh rate.
    341 frames in 5.0 seconds = 67.903 FPS

    runs like crap. Admitedly I did not try rebooting yet.

    So moving libdlfaker.so, at least in the way I did broke it. So I am guessing It must be changed back in order to fix the app. ? How can I do this in terms a noob would understand please. (If cmake puts it in the wrong place how can I put it in the right place without "mv" in the specfile? since mv breaks the app)


    %if 0%{?rhel} == 6
    %cmake28 -DTJPEG_INCLUDE_DIR=%{_includedir} \
             -DTJPEG_LIBRARY=%{_libdir}/libturbojpeg.so \
             -DVGL_USESSL=ON -DVGL_LIBDIR=%{_libdir} \
             -DVGL_DOCDIR=%{_docdir}/%{name}-%{version}/ \
             -DVGL_FAKELIBDIR=%{_libdir}/fakelib/ .
    %cmake -DTJPEG_INCLUDE_DIR=%{_includedir} \
           -DTJPEG_LIBRARY=%{_libdir}/libturbojpeg.so \
           -DVGL_USESSL=ON -DVGL_LIBDIR=%{_libdir} \
           -DVGL_DOCDIR=%{_docdir}/%{name}-%{version}/ \
           -DVGL_FAKELIBDIR=%{_libdir}/fakelib/ .
    make %{?_smp_mflags}

    results in this on rhel 6...

    [gsgatlin@localhost specs]$ rpmbuild -ba VirtualGL.spec 
    Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.PIMqn5
    + umask 022
    + cd /home/gsgatlin/redhat/BUILD
    + LANG=C
    + export LANG
    + unset DISPLAY
    + cd /home/gsgatlin/redhat/BUILD
    + rm -rf VirtualGL-2.3.1
    + /bin/tar -xf -
    + /usr/bin/gzip -dc /home/gsgatlin/redhat/SOURCES/VirtualGL-2.3.1.tar.gz
    + STATUS=0
    + '[' 0 -ne 0 ']'
    + cd VirtualGL-2.3.1
    + /bin/chmod -Rf a+rX,u+w,g-w,o-w .
    + exit 0
    Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.ekgvFk
    + umask 022
    + cd /home/gsgatlin/redhat/BUILD
    + cd VirtualGL-2.3.1
    + LANG=C
    + export LANG
    + unset DISPLAY
    + %cmake28 -DTJPEG_INCLUDE_DIR=/usr/include -DTJPEG_LIBRARY=/usr/lib64/libturbojpeg.so -DVGL_USESSL=ON -DVGL_LIBDIR=/usr/lib64 -DVGL_DOCDIR=/usr/share/doc/VirtualGL-2.3.1/ -DVGL_FAKELIBDIR=/usr/lib64/fakelib/ .
    /var/tmp/rpm-tmp.ekgvFk: line 33: fg: no job control
    error: Bad exit status from /var/tmp/rpm-tmp.ekgvFk (%build)

    RPM build errors:
        Bad exit status from /var/tmp/rpm-tmp.ekgvFk (%build)

    So I changed that back for RHEL 6.

    Any advice appriciated.

Comment 4 Orion Poplawski 2012-07-06 17:47:30 UTC
You need to patch the vglrun script to point to the correct location of the libraries when setting LD_PRELOAD.

Comment 5 Gary Gatling 2012-07-06 18:18:47 UTC
Sorry. Thank you for your help.

I am trying to wrap my head around this vglrun script. I tried to make this edit:


This is the original script:


With my dumb edits, I get this error:

gsgatlin@nom0047567 gsgatlin]$ optirun glxgears
ERROR: ld.so: object 'VirtualGL/libdlfaker.so' from LD_PRELOAD cannot be preloaded: ignored.
ERROR: ld.so: object 'VirtualGL/librrfaker.so' from LD_PRELOAD cannot be preloaded: ignored.
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
341 frames in 5.0 seconds = 67.934 FPS
300 frames in 5.0 seconds = 59.704 FPS
300 frames in 5.0 seconds = 59.703 FPS

Do I need absolute paths? Should I be setting LD_PRELOAD earlier at the beginning of the script? Should I make massive edits to get rid of the /opt stuff and instead relace with /usr/lib64/VirtualGL/blah.so and /usr/lib/VirtualGL/blah.so ? I aplogize if these are stupid questions. I know I how to make a patch if I can get the script working... But I am unsure how to proceed on the vglrun script itself.

Thanks again for any ideas anyone might have?

Comment 6 Orion Poplawski 2012-07-06 18:23:28 UTC
You need full paths.  You don't need to do it any earlier.  It might be easier to just write a new version from scratch that drops all of the /opt crap.

Comment 7 Gary Gatling 2012-07-06 20:00:54 UTC

Attempt #3 with paths patch added.



Further question...


the address listed is:

 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA

What should I ask the VirtualGL developers to change that to? Or was some other address mentioned such as an email address? (I do not see one in the file) I did not see that in the output when I ran rpmlint.

Thank you. Please let me know if further changes are required to meet packaging guidelines?

Comment 8 Orion Poplawski 2012-07-06 20:44:18 UTC
Looks like they updated the address from 2.3->2.3.1 so that is all set.

Comment 9 Orion Poplawski 2012-07-06 20:58:32 UTC
I think you need use the output of uname -i to determine architecture instead of existence of /usr/lib64.  I actually have a /usr/lib64 on my 32-bit machine from rubygems (although that may be a packaging error).  Or perhaps test for /usr/lib64/VirtualGL.

Comment 10 Gary Gatling 2012-07-07 21:52:12 UTC

Here is attempt #4.



I did find that I had to use the %cmake28 macro on rhel 6 with cmake28 from epel. So thanks for helping with that. If fixed that in this latest version.

Since I eat my own dog food, last night I have identified a problem in a game called minecraft I am somewhat addicted to. With VirtualGL 2.3 if you press "Quit" on the splash screen the minecraft application quits normally and the window closes. If you upgrade to VirtualGL 2.3.1, when you hit the quit button the window turns black, locks up, and this error occurs on the console output:


SoundSystem shutting down...
    Author: Paul Lamb, www.paulscode.com

Exception in thread "Minecraft main thread" org.lwjgl.LWJGLException: X Error - disp: 0x7fdea400f760 serial: 2678 error: BadWindow (invalid Window parameter) request_code: 15 minor_code: 0
	at org.lwjgl.opengl.LinuxDisplay.globalErrorHandler(LinuxDisplay.java:268)
	at org.lwjgl.opengl.LinuxDisplay.nDestroyWindow(Native Method)
	at org.lwjgl.opengl.LinuxDisplay.destroyWindow(LinuxDisplay.java:484)
	at org.lwjgl.opengl.Display.destroyWindow(Display.java:352)
	at org.lwjgl.opengl.Display.destroy(Display.java:967)
	at net.minecraft.client.Minecraft.d(SourceFile:527)
	at net.minecraft.client.Minecraft.run(SourceFile:688)
	at java.lang.Thread.run(Thread.java:662)

If the app is windowed you can close the window by left clicking the close widget, at least in GNOME 3. (And GNOME 2 in RHEL 6)

I belive this error also occours with "Stella" a Atari 2600 emulator. It is worse there because it is harder to exit full screen mode without rebooting. I am going to test that after hitting submit on this bugzilla comment.

Both of these problems happen when using the integrated intel display with both programs but bumblebee/virtualGL had worked around the issue for me. It is troubling to see it come back with the new VirtualGL. But perhaps other people won't care?

After some tests is for sure something in VirtualGL 2.3.1 and not something I am doing like moving libraries or changing wrappers. However, I see nothing obvious. In the changelog for version 2.3.1 it mentions that:

VirtualGL now properly handles implicit deletion of windows/subwindows via
XCloseDisplay(), implicit deletion of subwindows via XDestroyWindow(), and
explicit deletion of subwindows via XDestroySubwindows().  This specifically
addresses BadDrawable errors that occurred when running certain applications
in WINE 1.3.34 and later.

But perhaps this fix has actually made things worse for me? I can always run an old version myself but I wonder if this will mess other people up? I am not sure if I am clever enough to figure out what is going on here.

hmnn... I will give it some more thought over the next few days. Perhaps I could use strace or something to figure out why this is hapenning.

Comment 11 Gary Gatling 2012-07-07 21:57:08 UTC
Update, stella is not affected. Bug seems to only affect minecraft so far. :)

Comment 12 Gary Gatling 2012-07-07 22:02:16 UTC
Sorry, don't mean to spam but perhaps this isn't as bad as I first thought. It seems to only affect minecraft in windowed mode. So I don't see it crashing a display like stella did with intel. Let me know if further changes are needed.

Comment 13 Orion Poplawski 2012-07-10 17:01:17 UTC
Gary - You're going to need to work with upstream I think to resolve your runtime issues.  

Starting to look further, looks like we have some bundled libraries:


You'll want to remove these in %prep and see what you need to do to build with the system versions.

glxdemos - this is tricky as they add and install glxspheres{.c}.  But the other files are part of the glx package.  Need to try to build glxsperes with the system glx stuff.

Comment 14 Orion Poplawski 2012-07-10 17:29:22 UTC
Here is my attempt to use system fltk and glx headers


Comment 15 Orion Poplawski 2012-07-10 17:38:12 UTC
I would just not ship glxinfo at all.

Comment 16 Orion Poplawski 2012-07-10 17:50:01 UTC
So, if that didn't break anything (test it out and let me know), that should take care of the bundling.

Comment 17 Orion Poplawski 2012-07-10 18:20:56 UTC
Package Review

- = N/A
x = Pass
! = Fail
? = Not evaluated

==== C/C++ ====
[x]: MUST Header files in -devel subpackage, if present.
[x]: MUST Package does not contain any libtool archives (.la)
[x]: MUST Package does not contain kernel modules.
[x]: MUST Package contains no static executables.
[x]: MUST Rpath absent or only used for internal libs.
[x]: MUST Package is not relocatable.
[!]: MUST Development (unversioned) .so files in -devel subpackage, if
     Note: VirtualGL-2.3.1-2.fc17.i686.rpm : /usr/lib/VirtualGL/libdlfaker.so
     VirtualGL-2.3.1-2.fc17.i686.rpm : /usr/lib/VirtualGL/libgefaker.so
     VirtualGL-2.3.1-2.fc17.i686.rpm : /usr/lib/VirtualGL/librrfaker.so
     VirtualGL-2.3.1-2.fc17.i686.rpm : /usr/lib/fakelib/libGL.so

These are okay.

==== Generic ====
[x]: EXTRA Rpmlint is run on all installed packages.
     Note: There are rpmlint messages (see attachment).
[x]: EXTRA Spec file according to URL is the same as in SRPM.
[X]: MUST Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging

Assuming the removing of bundling is okay, this is all set.

[x]: MUST Package successfully compiles and builds into binary rpms on at
     least one supported primary architecture.
     Note: Using prebuilt rpms
[x]: MUST %build honors applicable compiler flags or justifies otherwise.
[x]: MUST All build dependencies are listed in BuildRequires, except for any
     that are listed in the exceptions section of Packaging Guidelines.
     Note: Using prebuilt rpms.
[x]: MUST Buildroot is not present
     Note: Unless packager wants to package for EPEL5 this is fine
[x]: MUST Package contains no bundled libraries.
[x]: MUST Changelog in prescribed format.

I added blank lines between entries...

[x]: MUST Package has no %clean section with rm -rf %{buildroot} (or
     Note: Clean would be needed if support for EPEL is required
[x]: MUST Sources contain only permissible code or content.
[x]: MUST Each %files section contains %defattr if rpm < 4.4
     Note: Note: defattr macros not found. They would be needed for EPEL5
[ ]: MUST Macros in Summary, %description expandable at SRPM build time.
[ ]: MUST Package contains desktop file if it is a GUI application.
[x]: MUST Package requires other packages for directories it uses.

I fixed owning %{_libdir}/VirtualGL/

[ ]: MUST Package uses nothing in %doc for runtime.
[ ]: MUST Package is not known to require ExcludeArch.
[x]: MUST Permissions on files are set properly.
[x]: MUST Package does not contain duplicates in %files.
[x]: MUST Fully versioned dependency in subpackages, if present.
[x]: MUST Package complies to the Packaging Guidelines
[!]: MUST Spec file lacks Packager, Vendor, PreReq tags.
     Note: Found : Vendor: The VirtualGL Project
[x]: MUST Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
     Note: rm -rf would be needed if support for EPEL5 is required
[ ]: MUST Large documentation files are in a -doc subpackage, if required.
[!]: MUST If (and only if) the source package includes the text of the
     license(s) in its own file, then that file, containing the text of the
     license(s) for the package is included in %doc.
[x]: MUST License field in the package spec file matches the actual license.
     Note: Checking original sources for licenses Licenses found: "LGPL (v2 or
     later)", "LGPL (v2 or later) GENERATED FILE", "*No copyright* UNKNOWN",
     "UNKNOWN", "*No copyright* Public domain", "MIT/X11 (BSD like)" For
     detailed output of licensecheck see file:
[x]: MUST License file installed when any subpackage combination is installed.
[ ]: MUST Package consistently uses macros (instead of hard-coded directory
[x]: MUST Package is named using only allowed ascii characters.
[x]: MUST Package is named according to the Package Naming Guidelines.
[x]: MUST Package does not generate any conflict.
[x]: MUST Package obeys FHS, except libexecdir and /usr/target.
[x]: MUST Package must own all directories that it creates.
[x]: MUST Package does not own files or directories owned by other packages.
[x]: MUST Package installs properly.
     Note: Using prebuilt rpms
[x]: MUST Requires correct, justified where necessary.
[x]: MUST Rpmlint is run on all rpms the build produces.
     Note: There are rpmlint messages (see attachment).
[x]: MUST Sources used to build the package match the upstream source, as
     provided in the spec URL.
[ ]: MUST Spec file is legible and written in American English.
[x]: MUST Spec file name must match the spec package %{name}, in the format
[ ]: MUST Package contains systemd file(s) if in need.
[x]: MUST File names are valid UTF-8.
[x]: MUST Useful -debuginfo package or justification otherwise.
[x]: SHOULD Reviewer should test that the package builds in mock.
[ ]: SHOULD If the source package does not include license text(s) as a
     separate file from upstream, the packager SHOULD query upstream to
     include it.
[x]: SHOULD Dist tag is present.
[x]: SHOULD No file requires outside of /etc, /bin, /sbin, /usr/bin,
[x]: SHOULD Final provides and requires are sane (rpm -q --provides and rpm -q
[x]: SHOULD Package functions as described.
[x]: SHOULD Latest version is packaged.
[x]: SHOULD Package does not include license text files separate from
[ ]: SHOULD Patches link to upstream bugs/comments/lists or are otherwise
[ ]: SHOULD Scriptlets must be sane, if used.
[!]: SHOULD SourceX / PatchY prefixed with %{name}.
     Note: Source0:
     (VirtualGL-%{version}.tar.gz) Patch0:
     (VirtualGL-2.3.1-redhatpathsfix.patch) Patch1: VirtualGL-fltk.patch
     (VirtualGL-fltk.patch) Patch2: VirtualGL-glx.patch (VirtualGL-glx.patch)

I don't like using %{name} for patches.  Up to you for this.

[x]: SHOULD SourceX is a working URL.
[ ]: SHOULD Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[ ]: SHOULD Package should compile and build into binary rpms on all supported
[ ]: SHOULD %check is present and all tests pass.
[ ]: SHOULD Packages should try to preserve timestamps of original installed
[x]: SHOULD Spec use %global instead of %define.

[!]: MUST Spec file lacks Packager, Vendor, PreReq tags.
     Note: Found : Vendor: The VirtualGL Project

This needs to get removed.

[!]: MUST If (and only if) the source package includes the text of the
     license(s) in its own file, then that file, containing the text of the
     license(s) for the package is included in %doc.
See: http://fedoraproject.org/wiki/Packaging/LicensingGuidelines#License_Text

This is okay, license is installed in %docdir.

[!]: MUST Development (unversioned) .so files in -devel subpackage, if
     Note: VirtualGL-2.3.1-2.fc17.i686.rpm : /usr/lib/VirtualGL/libdlfaker.so
     VirtualGL-2.3.1-2.fc17.i686.rpm : /usr/lib/VirtualGL/libgefaker.so
     VirtualGL-2.3.1-2.fc17.i686.rpm : /usr/lib/VirtualGL/librrfaker.so
     VirtualGL-2.3.1-2.fc17.i686.rpm : /usr/lib/fakelib/libGL.so
See: http://fedoraproject.org/wiki/Packaging/Guidelines#DevelPackages

False positive, these are okay.

Checking: VirtualGL-2.3.1-2.fc17.i686.rpm
VirtualGL.i686: W: spelling-error %description -l en_US compositing -> composting, com positing, com-positing
VirtualGL.i686: W: no-manual-page-for-binary vglconfig
VirtualGL.i686: W: no-manual-page-for-binary nettest
VirtualGL.i686: W: no-manual-page-for-binary vglrun
VirtualGL.i686: W: no-manual-page-for-binary glxspheres
VirtualGL.i686: W: no-manual-page-for-binary vglclient
VirtualGL.i686: W: no-manual-page-for-binary vgllogin
VirtualGL.i686: W: no-manual-page-for-binary vglxinfo
VirtualGL.i686: W: no-manual-page-for-binary cpustat
VirtualGL.i686: W: no-manual-page-for-binary vglgenkey
VirtualGL.i686: W: no-manual-page-for-binary vglserver_config
VirtualGL.i686: W: no-manual-page-for-binary tcbench
VirtualGL.i686: W: no-manual-page-for-binary vglconnect
VirtualGL.src: W: spelling-error %description -l en_US vglrun 
VirtualGL.src: W: spelling-error %description -l en_US compositing -> composting, com positing, com-positing
VirtualGL.src: W: spelling-error %description -l en_US vglclient -> clientele
3 packages and 0 specfiles checked; 0 errors, 16 warnings.

VirtualGL-2.3.1-2.fc17.i686.rpm (rpmlib, GLIBC filtered):

VirtualGL-debuginfo-2.3.1-2.fc17.i686.rpm (rpmlib, GLIBC filtered):

    VirtualGL = 2.3.1-2.fc17
    VirtualGL(x86-32) = 2.3.1-2.fc17

    VirtualGL-debuginfo = 2.3.1-2.fc17
    VirtualGL-debuginfo(x86-32) = 2.3.1-2.fc17

MD5-sum check
/export/home/orion/redhat/VirtualGL-2.3.1/VirtualGL/upstream/VirtualGL-2.3.1.tar.gz :
  MD5SUM this package     : 6c7dcfce0541df7f5bd8a07d4c480fb1
  MD5SUM upstream package : 6c7dcfce0541df7f5bd8a07d4c480fb1

Generated by fedora-review 0.2.0git
External plugins:

Comment 18 Gary Gatling 2012-07-10 21:08:05 UTC
Greetings, Attempt #5. Thanks so much for your help Orion.



So far this version seems to work fine with the system libraries instead of the bundled libraries. I will test further this evening with more apps.

Comment 19 Orion Poplawski 2012-07-10 21:17:56 UTC
Okay, with the final change this package is approved and I will sponsor you.

One more change you could make, you can do:

%if 0%{?rhel} == 6
%cmake28 \
%cmake \
         -DTJPEG_INCLUDE_DIR=%{_includedir} \

If you'd rather.  Keeps a single set of options.

Comment 20 Orion Poplawski 2012-07-10 21:22:19 UTC
What is your FAS account name?

Comment 21 Orion Poplawski 2012-07-10 21:24:30 UTC
Nevermind, found it )gsgatlin) and sponsored you.

Comment 22 Gary Gatling 2012-07-12 18:03:10 UTC

Here was a final edit before submission.



This contains the change to the cmake macro.

One thing that may be a problem that I didn't think about is that the turbojpeg dependency is missing from epel. I had been using a turbojpeg-1.1.1-3 rebuilt from fedora and it seemed to work ok on rhel 6. But I can go ahead and begin submitting this for fedora. 

Hmnn, it seems I cannot build in koji from scratch. I get:

[gsgatlin@y470 virtualgl]$ koji build --scratch f17 /home/gsgatlin/virtualgl/VirtualGL-2.3.1-5.fc17.src.rpm
Uploading srpm: /home/gsgatlin/virtualgl/VirtualGL-2.3.1-5.fc17.src.rpm
[====================================] 100% 00:00:06   2.62 MiB 426.90 KiB/sec
Created task: 4237130
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=4237130
Watching tasks (this may be safely interrupted)...
4237130 build (f17, VirtualGL-2.3.1-5.fc17.src.rpm): free
4237130 build (f17, VirtualGL-2.3.1-5.fc17.src.rpm): free -> open (x86-01.phx2.fedoraproject.org)
  4237132 buildArch (VirtualGL-2.3.1-5.fc17.src.rpm, i686): free
  4237131 buildArch (VirtualGL-2.3.1-5.fc17.src.rpm, x86_64): free
  4237131 buildArch (VirtualGL-2.3.1-5.fc17.src.rpm, x86_64): free -> open (x86-05.phx2.fedoraproject.org)
  4237132 buildArch (VirtualGL-2.3.1-5.fc17.src.rpm, i686): free -> open (x86-06.phx2.fedoraproject.org)
  4237132 buildArch (VirtualGL-2.3.1-5.fc17.src.rpm, i686): open (x86-06.phx2.fedoraproject.org) -> closed
  0 free  2 open  1 done  0 failed
  4237131 buildArch (VirtualGL-2.3.1-5.fc17.src.rpm, x86_64): open (x86-05.phx2.fedoraproject.org) -> closed
  0 free  1 open  2 done  0 failed
4237130 build (f17, VirtualGL-2.3.1-5.fc17.src.rpm): open (x86-01.phx2.fedoraproject.org) -> FAILED: BuildError: mismatch when analyzing VirtualGL-devel-2.3.1-5.fc17.noarch.rpm, rpmdiff output was:
removed     REQUIRES VirtualGL(x86-64) = 2.3.1-5.fc17
removed     REQUIRES libXv-devel(x86-64)  
removed     REQUIRES mesa-libGLU-devel(x86-64)  
removed     REQUIRES openssl-devel(x86-64)  
removed     REQUIRES turbojpeg-devel(x86-64)  
added       REQUIRES VirtualGL(x86-32) = 2.3.1-5.fc17
added       REQUIRES libXv-devel(x86-32)  
added       REQUIRES mesa-libGLU-devel(x86-32)  
added       REQUIRES openssl-devel(x86-32)  
added       REQUIRES turbojpeg-devel(x86-32)
  0 free  0 open  2 done  1 failed

4237130 build (f17, VirtualGL-2.3.1-5.fc17.src.rpm) failed

Trying to figure out how to look at the build.log in the koji cli because I cannot access the koji web site even after importing the ~/fedora-browser-cert.p12 file. Seems to be some kind of problem in the "devel" rpm with 64bit vs 32 bit. But the devel rpm package is actually noarch. hmnn.

Comment 23 Orion Poplawski 2012-07-12 18:14:51 UTC
Don't make -devel noarch, that should fix this.

Comment 24 Gary Gatling 2012-07-12 20:48:58 UTC



Ok. taking out the -devel being noarch fixed things with koji scratch builds for fedora 17 and fedora 16. I did think it was kind of odd the devel was noarch but I didn't give it much thought.

I think I am doing epel correctly, but it fails. It seems there were different values for epel dist-6E-epel-testing-candidate and dist-6E-epel

This is from mock from the web interface to koji:

Getting requirements for VirtualGL-2.3.1-6.el6.src
 --> cmake28-2.8.8-4.el6.i686
 --> fltk-devel-1.1.10-1.el6.i686
 --> openssl-devel-1.0.0-20.el6_2.5.i686
Error: No Package found for turbojpeg-devel

So I guess my question is can I submit my New Package SCM Request with el6 in it even if it fails in koji ? I know it is failing becuase of the  BuildRequires:  turbojpeg-devel where turbojpeg-devel is in fedora but I think turbojpeg-devel and turbojpeg are missing in epel at this time. So I guess I need to request that turbojpeg be added to epel first? Sorry about this process being so new to me. I was hoping this could be made availible through epel as well as fedora?

It also seems to fail with f18 but not sure why. It gets to the 53% mark and goes and craps out:

[ 53%] Built target sharedtex_mt
Linking CXX executable ../bin/fakerut
cd /builddir/build/BUILD/VirtualGL-2.3.1/server && /usr/bin/cmake -E cmake_link_script CMakeFiles/fakerut.dir/link.txt --verbose=1
/usr/bin/c++   -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4  -m64 -mtune=generic  -O3 -DNDEBUG   -Wl,-z,relro  -L/builddir/build/BUILD/VirtualGL-2.3.1/staticlib -static-libgcc CMakeFiles/fakerut.dir/fakerut.cpp.o  -o ../bin/fakerut -rdynamic -z now /usr/lib64/libGL.so -lGLU -z now /usr/lib64/libX11.so -ldl -lpthread 
make[2]: Leaving directory `/builddir/build/BUILD/VirtualGL-2.3.1'
/usr/bin/cmake -E cmake_progress_report /builddir/build/BUILD/VirtualGL-2.3.1/CMakeFiles  5
[ 53%] Built target fakerut
make[1]: Leaving directory `/builddir/build/BUILD/VirtualGL-2.3.1'
make: *** [all] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.RxFZsk (%build)
RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.RxFZsk (%build)
Child returncode was: 1
EXCEPTION: Command failed. See logs for output.
 # ['bash', '--login', '-c', 'rpmbuild -bb --target x86_64 --nodeps builddir/build/SPECS/VirtualGL.spec']
Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/mockbuild/trace_decorator.py", line 70, in trace
    result = func(*args, **kw)
  File "/usr/lib/python2.6/site-packages/mockbuild/util.py", line 352, in do
    raise mockbuild.exception.Error, ("Command failed. See logs for output.\n # %s" % (command,), child.returncode)
Error: Command failed. See logs for output.
 # ['bash', '--login', '-c', 'rpmbuild -bb --target x86_64 --nodeps builddir/build/SPECS/VirtualGL.spec']

Pretty weird. Is that a show stopper if it fails in koji scratch build for f18?

Comment 25 Orion Poplawski 2012-07-12 21:29:59 UTC
Yeah, we'll need to get turbojpeg into EPEL 6 before you can build there, but go ahead and request an el6 branch.

You're not capturing the real error message for the rawhide build above.  We can probably sort that out easier after you check it in and are doing real builds.

Comment 26 Gary Gatling 2012-07-13 14:59:23 UTC
New Package SCM Request
Package Name: VirtualGL
Short Description: A toolkit for displaying OpenGL applications to thin clients
Owners: gsgatlin
Branches: f16 f17 el6

Comment 27 Jason Tibbitts 2012-07-13 23:53:51 UTC
Git done (by process-git-requests).

Comment 28 Gary Gatling 2012-07-14 14:52:46 UTC
Things seem to go bad around here in rawhide with fedpkg build command.

[ 17%] Building CXX object server/CMakeFiles/fakerut.dir/fakerut.cpp.o
cd /builddir/build/BUILD/VirtualGL-2.3.1/server && /usr/bin/c++   -D__VERSION=\"2.3.1\" -D__BUILD=\"20120714\" -D__APPNAME=\"VirtualGL\" -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DUSESSL -DUSEXV -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4  -m64 -mtune=generic  -O3 -DNDEBUG -I/builddir/build/BUILD/VirtualGL-2.3.1/include -I/builddir/build/BUILD/VirtualGL-2.3.1/server -I/builddir/build/BUILD/VirtualGL-2.3.1/server/../common    -static-libgcc -fPIC -o CMakeFiles/fakerut.dir/fakerut.cpp.o -c /builddir/build/BUILD/VirtualGL-2.3.1/server/fakerut.cpp
/usr/bin/ld: /lib64/libglapi.so.0: undefined reference to symbol 'pthread_once@@GLIBC_2.2.5'
/usr/bin/ld: note: 'pthread_once@@GLIBC_2.2.5' is defined in DSO /lib64/libpthread.so.0 so try adding it to the linker command line
/lib64/libpthread.so.0: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
make[2]: Leaving directory `/builddir/build/BUILD/VirtualGL-2.3.1'
make[2]: *** [bin/glreadtest] Error 1
make[1]: *** [util/CMakeFiles/glreadtest.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
Linking CXX static library ../lib/librrglframe.a
cd /builddir/build/BUILD/VirtualGL-2.3.1/client && /usr/bin/cmake -P CMakeFiles/rrglframe.dir/cmake_clean_target.cmake
cd /builddir/build/BUILD/VirtualGL-2.3.1/client && /usr/bin/cmake -E cmake_link_script CMakeFiles/rrglframe.dir/link.txt --verbose=1
/usr/bin/ar cr ../lib/librrglframe.a  CMakeFiles/rrglframe.dir/rrglframe.cpp.o
/usr/bin/ranlib ../lib/librrglframe.a
make[2]: Leaving directory `/builddir/build/BUILD/VirtualGL-2.3.1'
/usr/bin/cmake -E cmake_progress_report /builddir/build/BUILD/VirtualGL-2.3.1/CMakeFiles  47
[ 17%] Built target rrglframe
Linking C executable ../bin/dlfakerut
cd /builddir/build/BUILD/VirtualGL-2.3.1/server && /usr/bin/cmake -E cmake_link_script CMakeFiles/dlfakerut.dir/link.txt --verbose=1
/usr/bin/gcc  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4  -m64 -mtune=generic  -O3 -DNDEBUG   -Wl,-z,relro  -L/builddir/build/BUILD/VirtualGL-2.3.1/staticlib -static-libgcc CMakeFiles/dlfakerut.dir/dlfakerut.c.o  -o ../bin/dlfakerut -rdynamic -lX11 -ldl 
make[2]: Leaving directory `/builddir/build/BUILD/VirtualGL-2.3.1'
/usr/bin/cmake -E cmake_progress_report /builddir/build/BUILD/VirtualGL-2.3.1/CMakeFiles  4
[ 17%] Built target dlfakerut
/builddir/build/BUILD/VirtualGL-2.3.1/server/fakerut.cpp: In function 'int mttest(int)':
/builddir/build/BUILD/VirtualGL-2.3.1/server/fakerut.cpp:1550:6: warning: variable 'dpyw' set but not used [-Wunused-but-set-variable]
/builddir/build/BUILD/VirtualGL-2.3.1/server/fakerut.cpp:1550:12: warning: variable 'dpyh' set but not used [-Wunused-but-set-variable]
Linking CXX executable ../bin/fakerut
cd /builddir/build/BUILD/VirtualGL-2.3.1/server && /usr/bin/cmake -E cmake_link_script CMakeFiles/fakerut.dir/link.txt --verbose=1
/usr/bin/c++   -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4  -m64 -mtune=generic  -O3 -DNDEBUG   -Wl,-z,relro  -L/builddir/build/BUILD/VirtualGL-2.3.1/staticlib -static-libgcc CMakeFiles/fakerut.dir/fakerut.cpp.o  -o ../bin/fakerut -rdynamic -z now /usr/lib64/libGL.so -lGLU -z now /usr/lib64/libX11.so -ldl -lpthread 
make[2]: Leaving directory `/builddir/build/BUILD/VirtualGL-2.3.1'
/usr/bin/cmake -E cmake_progress_report /builddir/build/BUILD/VirtualGL-2.3.1/CMakeFiles  5
[ 17%] Built target fakerut
make[1]: Leaving directory `/builddir/build/BUILD/VirtualGL-2.3.1'
make: *** [all] Error 2
RPM build errors:
error: Bad exit status from /var/tmp/rpm-tmp.6TPOwr (%build)
    Bad exit status from /var/tmp/rpm-tmp.6TPOwr (%build)
Child return code was: 1
EXCEPTION: Command failed. See logs for output.
 # ['bash', '--login', '-c', 'rpmbuild -bb --target x86_64 --nodeps builddir/build/SPECS/VirtualGL.spec']
Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/mockbuild/trace_decorator.py", line 70, in trace
    result = func(*args, **kw)
  File "/usr/lib/python2.6/site-packages/mockbuild/util.py", line 352, in do
    raise mockbuild.exception.Error, ("Command failed. See logs for output.\n # %s" % (command,), child.returncode)
Error: Command failed. See logs for output.
 # ['bash', '--login', '-c', 'rpmbuild -bb --target x86_64 --nodeps builddir/build/SPECS/VirtualGL.spec']

This bit right here is what I think is a issue:

/usr/bin/ld: /lib64/libglapi.so.0: undefined reference to symbol 'pthread_once@@GLIBC_2.2.5'
/usr/bin/ld: note: 'pthread_once@@GLIBC_2.2.5' is defined in DSO /lib64/libpthread.so.0 so try adding it to the linker command line
/lib64/libpthread.so.0: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status

Perhaps it will help if I make a rawhide kvm vm to test this in? I will work on that today.

So far, I only have development vms for 32 bit and 64 bit rhel 6, fedora 16, and fedora 17.

Not really sure how to fix adding "it" to the  linker command line. Any ideas appriciated. I will look into it further once I can get rawhide kvm vms installed and fully updated if I can duplicate locally.

Comment 29 Gary Gatling 2012-07-15 01:07:04 UTC
Tried adding BuildRequires:  mxml-devel based on some googling:


Did not help. Had no success building a rawhide vm today. (there are too many broken dependencies trying to yum update from fedora 17 to rawhide) I will try to create a rawhide vm on Monday using some other new method if possible if there is time. Sorry this isn't turing out to be too easy to figure out.

Comment 30 Orion Poplawski 2012-07-16 04:42:23 UTC
I filed bug 839060 against mesa for this issue.

Comment 31 Orion Poplawski 2012-10-17 03:05:09 UTC
Looks like this has been built.  Have you added it to comps?  After that we can close this I think.

Comment 32 Gary Gatling 2012-10-18 15:42:34 UTC
Hello. I'm sorry. I did not push out an update via Bodhi. I hesitated to do that before due to the upstream developer wanting me to do some things I cannot do.


But upstream also wanted some changes for multilib support that maybe I can do...

However, since he mentions that his rpms will overwrite ours, I am cool with pushing out an update via Bodhi if you think its ok to do that?

Sorry I didn't do anything about this until now. But I had to have surgery on my rear and back and I couldn't sit down until recently which is why I've been pretty out of it. But I've started back working now and can work on a computer again.

Do you know what group VirtualGL should go in in comps? Thanks a lot.

Comment 33 Orion Poplawski 2012-10-18 16:07:15 UTC
Sorry you had to have surgery, hope you recover quickly.  Anyway, while it is somewhat disappointing that upstream has taken a bit of an adversarial position to use packaging it, it meets our guidelines and should be shipped.

As for comps, I'm not sure, there doesn't seem to be a great fit.  Perhaps just system-tools (which is where the vnc client is).

Comment 34 Fedora Update System 2012-10-18 23:25:32 UTC
VirtualGL-2.3.1-8.fc18 has been submitted as an update for Fedora 18.

Comment 35 Fedora Update System 2012-10-18 23:31:39 UTC
VirtualGL-2.3.1-8.fc17 has been submitted as an update for Fedora 17.

Comment 36 Fedora Update System 2012-10-18 23:33:55 UTC
VirtualGL-2.3.1-8.fc16 has been submitted as an update for Fedora 16.

Comment 37 Fedora Update System 2012-10-19 15:40:49 UTC
VirtualGL-2.3.1-8.fc18 has been pushed to the Fedora 18 testing repository.

Comment 38 starfall 2012-10-23 17:07:47 UTC
VirtualGL-redhatpathsfix.patch is breaking multiarch.

In the standard VirtualGL rpm, the LD_PRELOAD for librrfaker.so and friends searches automatically in LD_LIBRARY_PATH which contains both 32-bit and 64-bit libraries.

In this RPM, the patch predetermines which libraries to load depending on uname and the result is that the patch is breaking 32-bit programs running on 64-bit systems.

32-bit Wine, for example, is completely broken for me using this RPM as I am running on a 64-bit OS.

I recommend that librrfaker.so and others be placed back in /usr/lib and /usr/lib64, and that VirtualGL-redhatpathsfix.patch be removed.

Comment 39 Gary Gatling 2012-10-23 18:38:58 UTC
I have a proposed fix for this problem that requires re-doing the patch. Here is the fixed up script:


Unfortunately, it causes some error messages if you have both 32 and 64 bit packages installed.

Running 64 bit openGL app:

[gsgatlin@y470b ~]$ optirun glxgears
ERROR: ld.so: object '/usr/lib/VirtualGL/libdlfaker.so' from LD_PRELOAD cannot be preloaded: ignored.
ERROR: ld.so: object '/usr/lib/VirtualGL/librrfaker.so' from LD_PRELOAD cannot be preloaded: ignored.

Running 32 bit app:

 optirun ./Shatter.bin.x86
ERROR: ld.so: object '/usr/lib64/VirtualGL/libdlfaker.so' from LD_PRELOAD cannot be preloaded: ignored.
ERROR: ld.so: object '/usr/lib64/VirtualGL/librrfaker.so' from LD_PRELOAD cannot be preloaded: ignored.

Notice how whichever one isn't being used is being warned about...

Orion, Do you think these error messages would be a problem? Or could we ignore them and consider this a fix for this bug? Evidently wine is a 32 bit app which is why this is coming up.

Comment 40 starfall 2012-10-23 18:50:08 UTC
Created attachment 632299 [details]
Updated .spec - fixes vglrun for 32-bit binaries on 64-bit OS

Comment 41 Gary Gatling 2012-10-23 19:00:08 UTC
Moving the lib*faker libraries back will cause rpmlint to give errors. I believe having those in libdir is going against fedora packaging guidelines.


So we weren't just doing that for fun. ;)

Comment 42 starfall 2012-10-23 19:13:33 UTC
Thanks for your hard work Gary.. I've been using your Bumblebee RPMs for the last few months and they are great.

Took a looked at your patched script. Have you thought about using adding /usr/lib/VirtualGL and /usr/lib64/VirtualGL in the LD_LIBRARY_PATH immediately before the LD_PRELOAD? Then you don't need to specify the full path of each  libXXfaker.so and no preload errors would appear.

Comment 43 Gary Gatling 2012-10-23 19:55:22 UTC
Thank you. I tried this one:


But I get errors and it doesn't seem to ever open a window...

optirun ./Shatter.bin.x86
       : ======================= LOG INITIALISED =======================
       : Name : Shatter ( SH )
       : Build: 12091801 ( pc )
       : MabCore v1.0 Initialised. ( $Id: MabCoreLib.h 108864 2011-12-01 01:07:59Z rgreen $ )
Error: signal: 11

[gsgatlin@nom0060038 ~]$ optirun glxgears
Error: couldn't get an RGB, Double-buffered visual

But perhaps I did not understand what you were suggesting correctly and so my script is wrong. Please let me know if there is anything I could change to get it working. If we do end up having to go with the first script I think the messages are mostly harmless...

Comment 44 starfall 2012-10-24 00:07:25 UTC
Created attachment 632470 [details]
Updated vglrun script

Comment 45 starfall 2012-10-24 00:07:57 UTC
I think there was a typo in the LD_LIBRARY_PATH lines in that one. A simplified one that works for me is attached. I did a little testing and no error messages as far as I can see in 32 or 64-bit binaries.

Comment 46 Gary Gatling 2012-10-24 01:04:50 UTC
Yup. That works! Thanks so much Andy. That makes it super easy.



I'll be pushing these out asap.

The new patch is called VirtualGL-redhatpathsmultilibfix.patch

Comment 47 starfall 2012-10-24 10:18:18 UTC
Created attachment 632679 [details]
Updated vglrun script - fixed lib64 test

This is an updated version of the script that does the lib and lib64 detection separately and should be more correct.

Comment 48 starfall 2012-10-24 10:22:35 UTC
Sorry Gary, I made a mistake in the script and added /usr/lib64/VirtualGL into the library path even when the 64-bit directory is not detected. It still works but the code isn't right.

I've just uploaded an new version of the script that does the lib and lib64 detection separately and should be more correct, which you can include in your next version of the package. Many thanks.

Comment 49 moondrake 2013-01-16 18:09:12 UTC
Current fedora rpms did not work very  for 32 bit apps. The rpms from the site above (comment 46) work fine (though the bumblebee rpm there could use some better configuration (location of nvidia libs, xorg modules and a screen section in xorg.conf files).

Hope we can see an update of virtualgl for fedora 18.

Comment 50 Gary Gatling 2013-01-16 19:05:58 UTC
Sorry. Will try to push 2.3.2 to testing either late tonight or tomorrow.

Comment 51 Fedora Update System 2013-01-17 22:29:42 UTC
VirtualGL-2.3.2-2.fc16 has been submitted as an update for Fedora 16.

Comment 52 Fedora Update System 2013-01-17 22:45:24 UTC
VirtualGL-2.3.2-2.fc17 has been submitted as an update for Fedora 17.

Comment 53 Fedora Update System 2013-01-17 23:00:18 UTC
VirtualGL-2.3.2-2.fc18 has been submitted as an update for Fedora 18.

Comment 54 Andrej 2013-01-19 15:14:41 UTC
This problem remains for me in 2.3.2-2. Tested with wine and games from HIBs (32 and 64bits).

ERROR: ld.so: object 'libdlfaker.so' from LD_PRELOAD cannot be preloaded: ignored.
ERROR: ld.so: object 'librrfaker.so' from LD_PRELOAD cannot be preloaded: ignored.

Comment 55 Gary Gatling 2013-01-19 15:28:35 UTC
If I edit the file, /etc/yum.repos.d/fedora-updates-testing.repo and change all the lines 

enabled=0 to enabled=1

and do a yum install VirtualGL on a freshly installed fedora 18 box I get

No package VirtualGL available.
Error: Nothing to do

I can test the version I personally built but I am not sure how to test the one in the build system that you are possibly looking at Andrej. Anyone have any ideas what I am doing wrong? Thanks a lot.

Comment 56 Andrej 2013-01-19 15:52:04 UTC
Gary, I think it's still not pushed in testing because status is still "pending" [1].

"PENDING - Your update has not yet been pushed to the testing or stable repositories." [2]

But never the less, it's not working for me for 32-bit apps.

[1] https://admin.fedoraproject.org/updates/VirtualGL
[2] http://fedoraproject.org/wiki/Bodhi#Pending

Comment 57 Gary Gatling 2013-01-19 18:42:35 UTC
I am unable to duplicate this bug on fedora 18 with the package I built myself in my private yum repository. I am able to run:

optirun ./glxgears32-f18

Where glxgears32-f18 is a glxgears executable which has been scp'ed from a fedora 18 kvm i686 virtual machine running inside of my centOS 6 box.

I have been using this very rpm on my CentOS 6 box for a couple of days and I can play 32 and 64 bit games. (The main 32 bit game I play is "shatter" from the humble indie bundles which seems to lock up my intel card for some reason so I run it through optirun to get around that problem)

[gsgatlin@y470 ~]$ file ./glxgears32-f18
./glxgears32-f18: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0xeb1d904956a38a266aa710c2103615efc9bc2daa, stripped

On fedora 18, this only works for me when using kernel 3.6.10-4.fc18.x86_64. When using the latest kernel, I cannot load certain third party out of tree kernel modules that are required for me to test bumblebee/VirtualGL. I understand these third party kernel modules are bad/evil/wrong and I cannot expect to get help from the fedora community in trying to troubleshoot that particular issue... So I am on my own. :(

So I'm not sure what  to do next. I will work on figuring out how to push these from "pending" to "testing," but I gather perhaps from item #3 on this page"


That I must wait for a Release Engineer to approve that... I don't see anything obvious on how to change that in the web interface. I'll keep looking tonight when I have more time.

If people want to see what I am trying to do with hybrid graphics on fedora / red hat you can look at the somewhat epic thread at:


I have not had much luck with fedora 18 so far with the latest kernel and I am not sure what to do. Maybe I should take them down in a week or so if I can't get this to work like it worked with older fedoras... I'm going to keep working on this all weekend so I haven't given up yet.

I have copied a vglrun script from VirtualGL-2.3.2-2.el6.x86_64 to a place on the web.


Is this one different than the one you installed? How did you download this  VirtualGL-2.3.2-2 rpm? What version of fedora are you using? (If fedora 17/16 I can re-install my spare laptop with that distro so we are on the same page)


Comment 58 Gary Gatling 2013-01-19 19:22:06 UTC
One other thing I though of while in the shower...

If you downloaded these from my private testing repo, make sure you did:

yum install VirtualGL.i686

to get the 32 bit package. If you are experimenting with primus, you also need to install the 32 bit version for 32 bit apps:

yum install primus.i686

If you got VirtualGL from the build system, just make sure you install the 32 bit rpm package also. Let me know what you find out.

Comment 59 Andrej 2013-01-19 19:55:10 UTC
I downloaded VirtualGL from Koji (your package which is on "pending").

I'm using Fedora 18 with lateset kernel: 3.7.2-201.fc18.x86_64, and Optimus hardware is HD4000 and GeForce 620M:

01:00.0 3D controller: NVIDIA Corporation Device 1140 (rev ff)
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)

Bumblebee is working (i can use both graphics cards), but problem is with 32-bit apps.

I did try with 32-bit glxgears taken from here [1] but still can't get it working on NVIDIA:
$ optirun ./glxgears-x86 
ERROR: ld.so: object 'libdlfaker.so' from LD_PRELOAD cannot be preloaded: ignored.
ERROR: ld.so: object 'librrfaker.so' from LD_PRELOAD cannot be preloaded: ignored.

Diff between yours and mine vglrun is zero.

Installing both VirtualGL arch doesn't make sanse because files will overlap so I don't understand how can you install/run both...

I don't use primus for now...

[1] http://mirror.aarnet.edu.au/pub/fedora/linux/releases/18/Everything/i386/os/Packages/g/glx-utils-7.10-8.20101028.fc18.i686.rpm

Comment 60 Gary Gatling 2013-01-19 19:59:02 UTC
I'm sorry. You have to have the 32 bit package also installed. That is Where the 


files live.


VirtualGL.x86_64 has:


and VirtualGL.i686 has:


Hope that helps. 


Comment 61 Gary Gatling 2013-01-19 20:01:36 UTC
Sorry, so the command would be:

rm -ivh /path/to/VirtualGL-2.3.2-2.fcXX.i686.rpm /path/to/VirtualGL-2.3.2-2.fcXX.x86_64.rpm

Where fcxx is your version of fedora.

Comment 62 Gary Gatling 2013-01-19 20:06:27 UTC
Sorry, one more comment.
If you use the rpm command, I think VirtualGL depends on a jpeg package. turbojpeg. So you will need to install it and all its 32 bit dependencies. Do a yum install turbojpeg.i686 first I think. Let me know if that works for you?

Comment 63 Andrej 2013-01-20 16:13:26 UTC
I can confirm it's working now when I used yours RPMs for bbswitch, bumblebee and bumblebee-nvidia. I can run on NVIDIA both, 32bits and 64bits.

Comment 64 Gary Gatling 2013-01-21 00:52:05 UTC
I have verified that the VirtualGL.x86_64 and VirtualGL.i686 work correctly from koji and fedora-updates-testing on fedora 18. The nature of my test, glxgears from a 32 bit vm, required installing 

libGLEW.i686 and mesa-dri-drivers.i686

on a 64 bit OS. I installed VirtualGL (64 bit) and VirtualGL.i686 via yum so it handled all the dependencies for itself.

Comment 65 Fedora Update System 2013-02-05 02:58:57 UTC
VirtualGL-2.3.2-2.fc17 has been pushed to the Fedora 17 stable repository.

Comment 66 Fedora Update System 2013-02-05 03:01:40 UTC
VirtualGL-2.3.2-2.fc18 has been pushed to the Fedora 18 stable repository.

Comment 67 Fedora Update System 2013-02-05 03:04:01 UTC
VirtualGL-2.3.2-2.fc16 has been pushed to the Fedora 16 stable repository.

Comment 68 Gary Gatling 2013-11-02 22:01:26 UTC
Package Change Request
Package Name: VirtualGL
New Branches: el6
Owners: gsgatlin

Would like this software to be availible in EPEL el6.

Comment 69 Gwyn Ciesla 2013-11-04 12:42:32 UTC
Branch for EL-6 already exists.

Note You need to log in before you can comment on or make changes to this bug.