> Notice also that the libXext.so.6 variant is usually only a symlink to
eg. libXext.so.6.4.0 which in this case you only have to restore (as
root)
> > cd /usr/lib64/
> > ls libXext.so.6*
> > ln -s libXext.so.6.4.0 libXext.so.6
> > (given libXext.so.6.4.0 exists and is not libXext.so.6.3.8 or so)
>
> > Can I simply fire this up in the VMware virtual machine with a
> barebone xinit ?
>
> yes. just make sure you set your PATH etc so you start the new bits,
> not the
> system-wide ones.
Well that is not a problem, there is no system wide X at all on this vmware
machine.
> > aster $ ldd
hi,
i'm looking to compile xorg-server-1.13.99.901 from a tarball
to improve general performance with intel i915 but having
issue locating the DRIContextFlags struct.
Is this definition included into the xserver source tree or is provided
by another *proto package? If so, can you kindly point
On Tue, Jan 29, 2013 at 02:08:26PM -0500, Dennis Clarke wrote:
>
> > > Can I simply fire this up in the VMware virtual machine with a
> > barebone xinit ?
> >
> > yes. just make sure you set your PATH etc so you start the new bits,
> > not the
> > system-wide ones.
>
> Well that is not a prob
> > That there looks like a build error. One should never, ever, need
> to specify LD_IBRARY_PATH in order to run a binary in some location
> like /opt/foo. The RPATH *should* be in the binary itself.
> >
> > Otherwise there is no promise that the binary will operate as
> expected.
>
> f
> > > set LD_LIBRARY_PATH to $prefix/lib
> >
> > That there looks like a build error. One should never, ever, need
> to specify LD_IBRARY_PATH in order to run a binary in some location
> like /opt/foo. The RPATH *should* be in the binary itself.
> >
> > Otherwise there is no promise that th
