Popping the stack on this after a year...
The (imminent) VirtualGL 2.3.3 release contains a reworked vglrun that
will allow launching VirtualGL if the faker libraries are in a
non-system library directory. It does this by looking for two scripts
called .vglrun.vars32 and .vglrun.vars64 in the same directory as
vglrun. Those scripts are generated by the build system when performing
a 32-bit or 64-bit build, respectively. Each script has the value of
the CMake VGL_LIBDIR variable hard-coded into it. The idea is that, if
you are installing both 32-bit and 64-bit packages for VirtualGL, both
scripts would be installed in the same directory as vglrun, but if you
are only installing a 64-bit package, then only .vglrun.vars64 would be
installed, and similarly, if you are only installing a 32-bit package,
only .vglrun.vars32 would be installed. This allows vglrun to launch
both 32-bit and 64-bit binaries, even if the faker libraries are in a
non-system location. Otherwise, if your packages install the faker
libraries in a system library directory, then you can simply omit
.vglrun.vars*, and vglrun will continue to behave as it always has.
Any feedback on this approach would be appreciated (you can try it out
by checking out the code in the subversion trunk.)
The issue I discovered with putting the fakers in a non-system directory
is that you can no longer launch setuid root binaries in VGL-- and yes,
I know, that's horribly insecure and no one should ever do it, but
that's the only way you can run VirtualBox or VMWare in VirtualGL (for
the purposes of running Windows 3D apps remotely.) Thus, for our
purposes, I'm going to have to continue to package VirtualGL with the
fakers in the system library directory on Linux. They aren't packaged
there on Fedora, which I assume means that you simply aren't able to
launch setuid root binaries in VirtualGL on that platform.
On 9/7/12 3:30 PM, DRC wrote:
> On 8/30/12 11:09 AM, Gary Gatling wrote:
>> -- Probably the best solution to your problem regarding installing
>> the
>> fakers in a non-system directory (I would suggest
>> /usr/lib[64]/VirtualGL
>> and also would suggest putting the libGL.so symlink in that same
>> directory, for simplicity) would be for me to modify the build system
>> such that vglrun is dynamically generated with the appropriate
>> prefix.
>>
>>
>>
>> Which is what we did. A new vglrun would be great if it doesn't break
>> other distros or users, etc. We use the %{_libdir} macro which will put
>> the faker libraries in either /usr/lib64/VirtualGL/
>> or /usr/lib/VirtualGL/ depanding on which platform the rpm package is
>> built for. (Fedora is really big on these macros in the spec file
>> because it makes things easier as the distro gets upgraded, changes are
>> made, etc.) The vglrun is currently being patched for this by patch0.
>> (.redhatpathsfix)
>
> I would definitely suggest that, since you are already using a
> non-system library path (/usr/lib[64]/VirtualGL) to store the faker
> libraries, it makes more sense to also put the libGL.so symlinks there
> instead of in a separate directory.
>
> The question becomes how best to make vglrun find the faker libraries if
> they are in a non-system path. After pondering the issue for a while, I
> see a major hurdle, which is that the same vglrun script has to be able
> to launch both 32-bit and 64-bit applications. The 32-bit and 64-bit
> VirtualGL RPMs should be co-installable, so we can't have a different
> version of vglrun in each. Further, if you are on a 64-bit machine, you
> should be able to install or de-install the 32-bit VirtualGL RPM without
> affecting your ability to run 64-bit apps. All of that makes it
> minimally difficult, if not impossible, to create a version of vglrun
> that has a hard-coded library path in it. If it was auto-generated with
> the value of the VGL_LIBDIR CMake variable, then that would imply that
> the script would be different between 32-bit and 64-bit builds, which
> wouldn't work.
>
> I think that, in your case, you could patch the vglrun script so that it
> sets LD_PRELOAD to something like
> /usr/lib64/VirtualGL/libdlfaker.so:/usr/lib64/VirtualGL/librrfaker.so:/usr/lib/VirtualGL/libdlfaker.so:/usr/lib/VirtualGL/librrfaker.so.
> However, it would be nice to have a more generic solution. I note
> that some applications will install libraries under
> /usr/lib/{application}, even though the libraries are 64-bit. If we
> assumed that VGL_LIBDIR would be the same between the 32-bit and 64-bit
> packages, then we could get away with simply naming the faker libraries
> differently (librrfaker32.so and librrfaker64.so, for instance) and
> having vglrun pre-load
> @VGL_LIBDIR@/lib*faker64.so:@VGL_LIBDIR@/lib*faker32.so. Still seems
> inelegant, though.
>
> Looking at another package (valgrind) that preloads libraries, it stores
> the 32-bit and 64-bit interposers separately in /usr/lib/valgrind/ and
> /usr/lib64/valgrind/, similarly to what you're doing, but I have no idea
> how it determines which to load, since valgrind is a binary executable
> and not a script. The same valgrind binary can be used to launch both
> 32-bit and 64-bit applications. On the surface, at least, this is the
> same functionality we want with VirtualGL.
>
>
>> -- I would like to somehow maintain the ability to install our
>> official
>> version of VirtualGL on these platforms without causing problems. I
>> think we should open a dialog regarding that, such as what happens
>> when
>> a user has our version installed and they do a 'yum update'.
>> Maybe the
>> official binaries need to change names, maybe we need to consider
>> installing all of our stuff under /opt/VirtualGL and using
>> alternatives
>> to maintain the /usr/bin symlinks, or maybe we just adopt the same
>> packaging standards as Fedora and assume that one package replaces
>> the
>> other. Suggestions welcome.
>>
>>
>> I'm sorry I don't have a good answer here. I had thought about perhaps
>> the official rpms having a high epoc number, but I guess that won't work.
>>
>> My sponsor said: "There really aren't any great ways of dealing with
>> this. Probably the best way would be for the virtualgl project to
>> provide its own yum repo then people can use yum-priorities to prefer
>> that repo over the fedora repos.
>>
>> My hope would be that virtualgl would come to see the Fedora version as
>> equal to their own and point people to installing the Fedora version."
>
> Not likely to happen. For starters, all of my paying customers are
> using RHEL, not Fedora, and the second most popular platform among VGL
> users is Ubuntu. If I start relying upon external projects to provide
> binaries for me, I run into all sorts of problems with differing user
> experiences. VirtualGL has always been developed more as a product than
> a project. I freely admit that it doesn't exactly follow the model of
> most other open source projects, but you can find similarities in other
> projects, such as VirtualBox and OpenOffice, that have a heritage as
> commercial products (and also a heritage as Sun products, in both cases.)
>
> The goal of our "official" binaries has always been to provide an equal
> user experience across all platforms. Further, the purpose of the
> in-tree packaging system is to make it easy for people (including me) to
> generate binaries from a particular source revision, which makes it easy
> to put proposed patches in front of users for testing. It takes time
> for changes to propagate down through the various distribution
> repositories, and that's just going to slow down the process of fixing
> bugs. Further, I have no idea whether, at some point in the future,
> Fedora may decide to freeze on a particular revision of VirtualGL (as
> they have done with TigerVNC, for instance) or whether the maintainer of
> the RPM may lose interest in the project, etc. The official binaries we
> provide are an enterprise-class product, and I have to be able to stand
> behind that product, because my sole source of income relies upon it.
>
> Apart from providing an equal user experience, the other reason why we
> tend to store things in /opt/VirtualGL is so vglconnect (the launcher
> for the VirtualGL Client) knows where to find the binaries and scripts
> on the server. This is important when using SSH tunneling, because it
> has to know where to find vgllogin. If different platforms put vgllogin
> in different places and don't provide a symlink under
> /opt/VirtualGL/bin, then that means that the user always has to tell
> vglconnect where to find vgllogin on whatever server it's connecting to.
> If Fedora chooses not to provide that symlink, then so be it-- there
> is a tacit understanding that they are choosing to support their version
> of VirtualGL, and thus they are responsible for making it work with
> whatever changes they make to it. For me, however, I can only stand
> behind the packages I create. It would be nice to remove as many of the
> /opt/VirtualGL hard-coded references as possible, but I don't know if
> it's possible to get rid of all of them.
>
>
>> I have set up a yum repo before and its not too hard. Basically you have
>> a web directory (can also use ftp) and you drop rpms in there and run
>> the createrepo command with the path to the repo as an argument. One
>> thing that complicates it is that the rpms need to be signed. (rpm
>> --addsign /path/to/rpmfile) I could perhaps help with that offlist if
>> you need it?
>> Then when you put a new version of VirtualGL in your repo all the people
>> with the official version could get updates when yum update runs.
>
> Maybe, but then I also need to maintain an apt-get repository for the
> Ubuntu users, which opens up a whole new can of worms. There are only
> 200 hours in the VirtualGL general fund each year to take care of
> general project maintenance, community support, integrating patches from
> the community, fixing bugs reported by the community, etc. I generally
> run over that budget by about 100 hours each year, meaning that that
> additional time is all pro bono. I'm OK with spending 30 or 40 hours on
> something like a build system overhaul that ultimately allows me to
> spend less time maintaining the project, but creating my own repos
> ultimately is going to create more work for me, not less.
>
> When I look to other open source projects as a model, OpenOffice is
> notable. They have a similar distribution model to ours-- providing a
> set of "cross-distribution" RPMs and DEBs. However, their "official"
> RPMs and DEBs use a different name than the distribution-supplied
> OpenOffice packages, and the "official" packages install everything
> under /opt.
>
> That seems like the best approach for us as well. If we can sort how
> best to distribute the faker libraries under some subdirectory of
> /opt/VirtualGL, then I am perfectly fine with putting everything under
> /opt/VirtualGL and using alternatives to create symlinks in /usr/bin.
> Ideally, your RPM would likewise register anything it installs in
> /usr/bin via alternatives, allowing us to install both RPMs on the same
> system.
>
> In terms of naming, I would suggest naming your RPM something besides
> VirtualGL. If you are splitting it into multiple RPMs, then this is
> easy. Just ship RPMs named "VirtualGL-common", "VirtualGL-client",
> "VirtualGL-utils", "VirtualGL-server", "VirtualGL-devel", etc., and none
> of them will actually be named "VirtualGL". Or maybe use
> "VirtualGL-fedora" or some alternative (even lowercase "virtualgl",
> perhaps.)
>
>
>> -- common/glx.h and common/glxext.h are not bundled libraries.
>> They're
>> simply headers, included because not all of the platforms VirtualGL
>> builds on have a recent enough set of OpenGL headers, and it's just
>> easier to build against our own. I don't see why they would cause
>> problems.
>>
>>
>> Yeah, We need to build against our system headers according to my
>> project sponsor. But we are not *at all* trying to tell you that you
>> need to stop doing that or anything or that it is wrong. Its juts a
>> rule we have in the fedora project. If other distros need it please
>> don't mess them over because of us. :)
>
> It's best to think of glx.h and glxext.h as internal headers to
> VirtualGL. There is no easy way for me to modify the project to load
> those headers from an external directory, nor would I want to, so if you
> insist on doing so (why?), you're going to need to patch the source. The
> reason why we provide our own versions of those headers is simply so we
> can guarantee that there are valid prototypes for all of the functions
> we interpose. Again, best to think of these as internal headers. They
> are only used by the faker library.
>
> This is another example of a knee-jerk reaction that the distribution
> vendor is having to an automated test, without stopping to think about
> what the test is really testing. What they're trying to prevent is an
> application linking against its own in-tree static version of libGL.
> Fair enough, but that's not what we're doing. VirtualGL provides an
> implementation of the GLX API, just like Mesa provides an implementation
> of the GLX API. The difference is that our implementation is loaded
> into the application at run time rather than being linked in at compile
> time. Mesa builds against its own internal GLX headers, and so do we.
> The difference is that Mesa then installs their GLX headers, and we don't.
>
> I would also add that we don't even really support Mesa as a back end,
> and there are known interaction issues with, for instance, the Gallium
> driver and VirtualGL. Thus, it may be the case that someone wouldn't
> even be able to use VirtualGL with a "default" Fedora installation, and
> there certainly isn't much point to it unless you have 3D hardware
> acceleration (perhaps it works OK with nouveau, in which case you could
> make that a dependency-- except that it would prevent you from later
> uninstalling nouveau and installing the proprietary nVidia driver.)
>
>
>> -- I am willing to add a VGL_SYSTEMFLTK option to the build so
>> that it
>> looks for FLTK elsewhere, rather than building the in-tree version.
>>
>>
>> Fedora project is suggesting "VGL_USE_SYSTEM_FLTK", more in line with
>> similar variables from vtk/paraview cmake projects.
>
> It is our standard to use variable names that are as short and
> easy-to-remember as possible, and VGL_USE* is reserved for enabling
> run-time features, not for build options.
>
>
>> Please understand I am EXTREMELY new at this. In fact this is my first
>> package ever in the fedora project. So I did not mean to cause problems.
>> I wanted to see VirtualGL have a wider audience since it will
>> be installable from the many many packages in the fedora distro without
>> having to fuss with anything first. Plus my own package needs this as a
>> rpm dependency so I'm going to have to get this one in if I am to have
>> any hope for getting bumblebee into fedora.
>
> I'm willing to help out in any way I can, within reason, but I will also
> re-iterate that VirtualGL was never really designed to be integrated
> into an O/S distribution, so this is all new to me as well.
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
VirtualGL-Devel mailing list
VirtualGL-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
