On 3/23/15 7:58 PM, Nathan Kidd wrote:
> BTW, yes, you are correct. Multiple vglrun copies in the path is a very
> similar problem to multiple librrfaker.so copies in the library search
> order.
It's a problem in theory, but in practice, people don't typically
install multiple copies in their PA
On 18/03/15 03:37 PM, DRC wrote:
> I kept the basic idea of these patches but modified them in my own way
> to be more project-friendly:
>
> -- It was necessary to modify vglrun so that it uses the custom
> "rrfaker", "dlfaker", and "gefaker" strings. I assume that OpenText may
> not be using
On 18/03/15 03:37 PM, DRC wrote:
> I kept the basic idea of these patches but modified them in my own way
> to be more project-friendly:
Got a chance to rebase on that tree: Works for me. Thanks.
-Nathan
--
Dive into
I kept the basic idea of these patches but modified them in my own way
to be more project-friendly:
-- It was necessary to modify vglrun so that it uses the custom
"rrfaker", "dlfaker", and "gefaker" strings. I assume that OpenText may
not be using vglrun (some vendors don't), which is why thi
On 14/03/15 10:35 PM, DRC wrote:
> I'll look into it. There are a couple of obvious bugs ("defaker"
> instead of "dlfaker"), and I think I can make CMake do a little more
> of the work instead of requiring so many ifdefs
Sorry, looking at that 3rd patch again, besides s/defaker/dlfaker/ and
DEFAKE
I'll look into it. There are a couple of obvious bugs ("defaker" instead of
"dlfaker"), and I think I can make CMake do a little more of the work instead
of requiring so many ifdefs, but I agree that this is useful. There is at least
one other remote display vendor now selling their own version
