I now have working 32-bit and 64-bit builds.
Glad to hear.
I would propose to make the above PREFIX the default value, instead of storing the X11 module build under /tmp.
Sure, fine with me.
Before the 32-bit build would work, I had to install a 32-bit version of e2fsprogs-devel and add the following 32-bit development stubs: /usr/lib/libcairo.so-->/usr/lib/libcairo.so.2 /usr/lib/libXpm.so->/usr/lib/libXpm.so.4 /lib/libdbus-1.so->/lib/libdbus-1.so.3 The 32-bit e2fsprogs-devel was necessary to build libSM, but libSM seems to be only used by DRI. Question-- does DRI even work with TigerVNC?
A dependency on e2fsprogs-devel is quite odd. I believe you should be able to get rid of this dependency by building libSM with --with-libuuid=no. Can you add this to the build script?
Wrt DRI, I guess that depends on what one means with DRI. With Xvnc, applications cannot of course use DRI to access the video hardware, since there might be none. However, as Xorg is structured nowadays, it seems impossible to build Xvnc with software based OpenGL support without enabling DRI. We have this comment in our Mesa build script:
# Driver must be dri, or GL/internal/dri_interface.h won't be installed.Then, the resulting swrast_dri.so must be deployed with Xvnc to enable software OpenGL.
Another question -- The resulting Xvnc shows up with dependencies on the following dynamic libs which will cause compatibility issues when deploying the application: Hard-coded dependencies to libs in TigerVNC build directory: libXfont.so.1 libfontenc.so.1 libpixman-1.so.0 libX11.so.6 libXau.so.6 libXdmcp.so.6 System dependencies: libfreetype.so.6 libhal.so.1 libdbus-1.so.3 libcrypto.so.6 libstdc++.so.6 The first list is of the most concern, because the LD run path of these is hard coded to the TigerVNC development directory. I am wondering whether the build would work using the system-installed version of these libraries instead, or perhaps if Xvnc should be built as a monolithic executable with those libraries included statically.
I guess this depends on the kind of binary you want - what kind of deployment we are talking about. For ThinLinc, we are linking such libraries statically, so that we can support a large number of platforms. Currently, our only dependencies are:
NEEDED libc.so.6 NEEDED libz.so.1 NEEDED libdl.so.2 NEEDED libm.so.6One important question is whether we - the TigerVNC project - should distribute binaries. I think it's more common, and easier, to not doing that; only distribute source. But as I understand it, TurboVNC distributes binaries, and perhaps that's something that TurboVNC users really wants. DRC, what's your opinion?
Best regards, ---
Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 Linköping Phone: +46-13-21 46 00
------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
