The Xorg 7.5 code base is known not to work on older systems (RHEL 4 and 5, in particular) due to an autotools incompatibility (even though the configure.ac file in Xorg says it supports AC 2.57 and later, it uses some macros that are only available on newer versions.) However, it should work on something as new as Lenny. What is the specific build error? The Xorg 7.5 build changes are relatively new and untested, so there may be a legitimate bug in the build-xorg system.
On 9/30/10 12:49 PM, Robert Goley wrote: > 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, Adam >>>>>>>>> >>>>>>>>>> On 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 ------------------------------------------------------------------------------ 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
