|
Hmm... That may be my problem. I have been trying to build
against 7.5 or the git repo. I haven't tried 7.4 since before the
TLS stuff was officially added. I will try 7.4 again and post my
results. Noticed the typo in the last email. I meant TigerVNC of
course.... Robert On 09/30/2010 12:40 PM, DRC wrote: Me too! That is why I'm willing to work on the CMake system. I haven't yet been able to successfully build the Windows code myself, except for just VNCViewer (which is painful because of all the MinGW dependencies.)As far as building on Lenny, I'm surprised that using build-xorg doesn't work for you. That method, when used with the Xorg 7.4 code base, should be backward compatible all the way back to RHEL 4 and its contemporaries (Ubuntu 6, etc.) On 9/30/10 8:46 AM, Robert Goley wrote:I realize it would never completely replace autotools. I was just hoping for wrapper that would work a bit better. I haven't had that much luck with compiling TigerVNC on Lenny yet. The client stuff works fine but even compiling the whole Xorg tree for dependencies has not worked yet... May have just been my frustration coming thru... The Windows platform is next on my list and history tells me it never plays nice (MSVC or MinGW). I really want to start working with TightVNC's TLS connections. I applaud the work all the developers have done and look forward to when I can actually get to use it. Robert On 09/30/2010 01:25 AM, DRC wrote:I didn't say that SCons didn't work great on Windows. I just said that it was my impression that CMake was more "Windows-friendly." By that, I mean it has full support for generating IDE projects and doesn't require external dependencies like Python, etc. I thought the link from the SCons wiki was a pretty good summary of the trade-offs. Realistically, we're never going to be able to remove autotools from the Unix/Linux build, because autotools is necessary to build Xorg. Thus, I don't see the point in trying to unify the build system across Windows and Unix. We already have that in our existing build system, which requires using MinGW to build Windows binaries. However, that system ironically works a lot better on Linux than it does on an actual Windows machine (see http://www.mail-archive.com/tigervnc-devel@lists.sourceforge.net/msg00649.html), and it requires using an unsupported patch to MinGW in order to build WinVNC. I don't think that it will be that difficult to implement the CMake system in TigerVNC, since I am implementing it in TurboVNC and libjpeg-turbo first. I'll be able to leverage a lot of that existing work. On 9/29/10 5:20 PM, Robert Goley wrote:I am not sure on the visualization stuff or what you mean by it exactly. KDE moved to SCons initially and then to CMake because they wanted custom changes and we not getting results as fast as they liked. I haven't seen anything that would require a custom change in SCons myself. It does work great on Windows though. Not sure where you got the idea it didn't. It was actually one of the first places I had to use it. It does require Python to be downloaded but Python is available and works fine on Windows. It also has functionality to create MS Studio Projects as well though this functionality may be limited in some areas. I am more of a command line or automation type of guy for my build systems but have used some of the MS project generation pieces. I guess everyone has their preferences though. Thanks for taking a look at it and responding so quickly. My offer still stands on helping with a SCons based build system. I can't offer the same help with the CMake system though. I will be glad to see an improvement in the build system either way though. I would love to be able to get it to compile on Debian Lenny with one build command though I know Windows is your focus. Robert On 09/29/2010 05:40 PM, DRC wrote:I've looked at SCons cursorily. The original reason why I started looking at CMake was that I'm a visualization guy, and CMake has a lot of traction in that community (that's where it came from originally.) More generally, however, my (perhaps incorrect) impression is that there seem to be more projects moving to CMake than SCons (including some heavy hitters, like KDE), and it seems that CMake is more Windows-friendly. I like the idea of users being able to generate Visual Studio project files and then use the Visual Studio IDE to compile their project if they so desire. Most Windows developers are comfortable with this model. Personally, I'm more of a command line guy, so I like using Makefiles, but this gives us the option to support both environments without supporting multiple build systems. I don't see any particularly compelling reason to move the Unix code off of autotools, so really what we're looking for is what provides the best solution for Windows native development. CMake is a self-contained executable, i.e. it doesn't require Python (which isn't available on Windows systems), and thus it seems to be the most straightforward solution. The common view is that it's also faster, for the same reason. Interesting perspective here: http://www.scons.org/wiki/SconsVsOtherBuildTools#head-3d0faf3f1d4d3b73f31eaa0ba97d4df18a474369 On 9/29/10 3:11 PM, Robert Goley wrote:I would be glad to see a better cross platform build system. I have done some work with CMake in the past and with SCons. I found Scons to be a better system overall. One of the big selling points of it for me was that it literally replaced the native systems make command and launched the compiler and linker directly instead of wrapping them. This seemed to allow for better concurrent object compiling with multiple processors/cores. I saw my compile times cut in have comparing it to GNU make's -j option with the same number of processors. Have you looked into SCons at all? I know this is just my 2 cents but I certainly would be willing to help with a SCons based build system. What are your thoughts? Robert On 09/29/2010 03:50 PM, DRC wrote:I've been getting my hands dirty with CMake in recent weeks, and I now firmly believe that's the way to go with respect to a Windows build system for TigerVNC. I don't propose replacing autotools (at least for now), but CMake allows one to generate their own build system based on NMake or Visual Studio projects or even MinGW, and it works with 64-bit. People can still use MinGW and autotools to build TigerVNC if they want, but this gives native Windows developers a viable option for working with our code that doesn't require compiler customizations. The intermediary step is for me to implement a CMake system for Windows builds of libjpeg-turbo, and adding the system to TigerVNC should be straightforward after this is done. Since this is currently unfunded work, I can't give a timeframe as to when I might be able to complete it, but I believe that it needs to be part of 1.1. On 9/16/10 4:15 AM, Adam Tkac wrote:On Thu, Sep 16, 2010 at 03:14:02AM -0500, DRC wrote:Once I can successfully get a static build going on RHEL 4 (still having problems with the lack of gnutls_transport_set_global_errno), I'll look into these issues. libgcrypt and libgnutls are definitely not cross-compatible, so the -static switch to build-xorg will probably have to accommodate those libs as well as the others. I'm hoping that the new Xorg 7.5 patches you just checked in will eliminate the build issue I had previously that was preventing me from using Xorg 7.5. If so, I will generate a static Xvnc binary and look into linking statically with gnutls. I then want to try out the security features to make sure they behave like I expect, and I'll be cool with releasing the alpha at that point. What is the situation with respect to doing Windows builds? I have never successfully managed to build WinVNC. Did those patches ever make it into a release of MinGW?My MinGW patch isn't accepted, yet. And I'm not sure if it will be accepted: https://sourceforge.net/mailarchive/message.php?msg_name=AANLkTikg0hAGpArLTqFSWn6IdSI5aNOwJk-3ZDl4rqrq%40mail.gmail.com I'm going to merge my "vcstudio_buildsys" branch to trunk so it should be possible to build winvnc with both MSVC and MinGW. Regards, AdamOn 9/15/10 9:06 AM, Adam Tkac wrote:Hello, as you might have seen I performed build-xorg improvements and it is now possible to build Xvnc via those scripts. In my opinion prebuilt Xvnc will be built with this script so it's good time to discuss remaining issues. "Statically" linked Xvnc now contains references for following libraries: $ readelf -a ./Xvnc |grep NEEDE 0x0000000000000001 (NEEDED) Shared library: [libpam.so.0] 0x0000000000000001 (NEEDED) Shared library: [libgnutls.so.26] 0x0000000000000001 (NEEDED) Shared library: [libgcrypt.so.11] 0x0000000000000001 (NEEDED) Shared library: [libdl.so.2] 0x0000000000000001 (NEEDED) Shared library: [librt.so.1] 0x0000000000000001 (NEEDED) Shared library: [libm.so.6] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x0000000000000001 (NEEDED) Shared library: [ld-linux-x86-64.so.2] 0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0] Everything except libgnutls.so.26 is present on old systems (i.e. RHEL4& friends) so we must decide what to do with libgnutls. Although I'm not friend of static linking it seems we have to link Xvnc statically against libgnutls to avoid compatibility issues. I also created two patches which add -dridir and -xkbcompdir parameters to Xvnc. Those parameters should be determined same way as -fp parameter in vncserver script and passed to Xvnc. After vncserver gets improved UNIX code is ready for the alpha release, in my opinion. Regards, Adam------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel-- *Robert Goley* FOSS Implementation Specialist Toll Free: (800) 338-4984 Local: (770) 479-7933 Fax: (770) 479-4076 www.openrda.com /America's only Free & Open Source fund accounting software company./ --
Robert Goley
 FOSS Implementation Specialist Toll Free: (800) 338-4984 Local: (770) 479-7933 Fax: (770) 479-4076 www.openrda.com America's only Free & Open Source fund accounting software company. |
------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
