Yes, it's intended. Putting the libraries under *lib*/64/ is a Sun convention, and it's time to change it.
There will probably be some further packaging changes before 2.4 is released. Since O/S distributors are starting to package VirtualGL, we're going to run into potential conflicts with their releases, so my thought is to start putting everything in our "official" packages under /opt/VirtualGL and create the symlinks under /usr using alternatives. In this case, the faker libs would go under /opt/VirtualGL/lib[64][32], and I'd simply create a libGL symlink under that same directory, eliminating the need for a separate "fakelib" directory altogether. On 9/4/12 12:04 PM, Arthur Huillet wrote: > On Tue, 04 Sep 2012 11:45:31 -0500 > DRC <dcomman...@users.sourceforge.net> wrote: > >> Yes, it's a known issue. Please search the list archives for a more >> detailed explanation and the current workaround. We've been pressuring >> the VBox developers to fix this for 6 months, but thus far, they have >> not done so. > > I knew about the workaround and I've just tried it. Now the VM starts OK. > I thought the issue had been fixed but I was wrong. > > Sorry for the extra noise - as of right now people still need to symlink > VBoxTestOGL to /bin/true. > > By the way, your VirtualGL "nightly" x86-64 rpm doesn't seem to > create /opt/VirtualGL/fakelib/64, instead it creates /opt/VirtualGL/fakelib64. > I'm not sure whether this is intended. > > Thanks > ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
