On Sun, Jan 10, 2010 at 07:46:30PM -0600, DRC wrote: > I have been trying to come up with a reasonable set of build scripts for > generating a version of TigerVNC on RHEL 4 that is forward compatible > with later versions of Linux. I have managed to modify build-xorg-7.4 > and create wrappers for it that produce a TigerVNC build with > essentially the same very limited shared library dependencies that our > released version of Xvnc has. This involved building the Xorg modules > as static libraries, building a static version of freetype, and wrapping > build-xorg-7.4 to set up a build environment which eliminates other > dependencies such as libcrypto, libstdc++, and libgcc. > > The goal is to be able to provide users with a means of building and > packaging such a cross-compatible release themselves. This is a further > step toward the long-term goal of replacing TurboVNC. > > Once I started playing with my build, I came across two problems. These > problems aren't specific to my static build, as I can reproduce them > with a non-static build as well (as well as with our 1.0.0 release build > of Xvnc.) > > (1) I've tried running Xvnc on both RHEL 4 and 5, and Xvnc seems to fail > to talk to xfs in both cases. I swear I had this working with 0.0.90, > but I'm not sure what could have changed. As you recall, I modified > vncserver to use xfs as the first choice for determining the font path, > if xfs is running. However, if xfs is running, now TigerVNC will > pretend to start up fine, but I will get the following errors in the log > file: > > Window manager warning: xserver doesn't have 'fixed' font. > Bug in window manager: Unexpected X error: BadName (named color or font > does not exist) serial 170 error_code 15 request_code 45 minor_code 0) > > Subsequently, Gnome fails to work correctly. If I stop xfs, then start > the TigerVNC session, then start xfs again, everything works fine. > > It would not break my heart to remove xfs support from vncserver > altogether, or at least discontinue using it as the default, since > vncserver generates a reasonable font path for older systems such as > RHEL 4 and 5. However, I want to make sure I'm not missing something here.
AFAIK we can safely drop xfs support. If I remember correctly X.Org 1.5.X (and newer versions) ran with no xfs, at least in Fedora. > (2) GLX support. I have this working, but Xvnc seems to only want to > load swrast_dri.so if that file is located within my build directory > (putting it elsewhere in the LD_LIBRARY_PATH doesn't work.) Wondering > if there is any way to make Mesa load swrast_dri.so from a path I > specify at run time. As Peter wrote currently there is no way how to specify path for Mesa _dri.so modules. It requires X server to be patched (it has to be possible to change dri_driver_path variable in glx/glxdriswrast.c at run time). Regards, Adam -- Adam Tkac, Red Hat, Inc. ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
