The specific errors I see when trying to build with the Xorg 7.5 code on
RHEL 4 and 5 are as follows:
configure.ac:468: error: possibly undefined macro: AC_MSG_ERROR
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure:463: error: possibly undefined macro: AM_DEFAULT_VERBOSITY
configure:2493: error: possibly undefined macro: AC_PROG_CC_C99
configure:4791: error: possibly undefined macro: AS_VERSION_COMPARE
configure:4793: error: possibly undefined macro: AC_MSG_WARN
autoreconf: /usr/bin/autoconf failed with exit status: 1
Also AC-related, but I'm not sure if that's what you're seeing as well.
As far as building with Windows, if all you need to build is just
VNCViewer, the most painless way to do it is to install a "legacy" MinGW
environment using the following installers:
MinGW-5.1.6.exe (The MinGW project no longer has this available for
download, so e-mail me if you are unable to find it)
http://sourceforge.net/projects/mingw/files/MSYS/BaseSystem/msys-core/msys-1.0.11/MSYS-1.0.11.exe
http://sourceforge.net/projects/mingw/files/MSYS/Supplementary%20Tools/msysDTK-1.0.1/msysDTK-1.0.1.exe
MinGW has a fancy new installer for the GCC 4.5 toolchain.
Unfortunately, however, that toolchain cannot be successfully used to
build TigerVNC, due to a problem described in this previous message:
http://www.mail-archive.com/tigervnc-devel@lists.sourceforge.net/msg00665.html
I've verified that the problem still exists with the toolchain installed
by the new MinGW installer. :(
The next step would be to download and install GnuTLS:
http://josefsson.org/gnutls4win/gnutls-2.10.1.exe
and NASM:
http://www.nasm.us/pub/nasm/releasebuilds/2.09.02/win32/nasm-2.09.02-installer.exe
Install into c:\nasm
Now, you should be able to open a new MSYS shell, check out (or update
to) the latest TigerVNC SVN trunk, then
cd tigervnc
mkdir windows
cd windows
export CPATH=/c/Program\ Files/GnuTLS-2.10.1/include
export LIBRARY_PATH=/c/Program\ Files/GnuTLS-2.10.1/lib
sh ../configure NASM=/c/nasm/nasm.exe; make
To link statically with GNU TLS, instead do:
sh ../configure GNUTLS_LDFLAGS='-Wl,-Bstatic -lgnutls -lgcrypt
-lgpg-error -ltasn1 -Wl,-Bdynamic -lws2_32' NASM=/c/nasm/nasm.exe; make
Wait ... A very long time ...
If everything goes well, you should now have a working binary under
tigervnc\windows\win\vncviewer\vncviewer.exe
Issues:
-- The resulting binary will not perform optimally, because the
libjpeg-turbo codec that TigerVNC uses for JPEG
compression/decompression requires GCC 4.1 or later or Visual C++ to
perform at its peak. The 32-bit version of this codec, in particular,
will be noticeably slower when built with GCC 3.4.x
-- Win64 support, or rather, lack thereof. I have successfully built
TigerVNC for Win64, but it requires MinGW-w64, which isn't for the faint
of heart. Also, there are currently no Win64 binaries for GnuTLS
(scuttlebutt on their forums seems to indicate that this is in the works.)
-- MSYS autotools are ridiculously slow (the ones in Cygwin are even worse.)
One other note:
During this exercise, I also discovered that there aren't any Visual C++
static libraries for GnuTLS either. <sigh> That means that,
ultimately, building with Visual C++ via the proposed CMake build system
might require either building GnuTLS from source or using the DLL's.
Fizzbin, anyone?
On 9/30/10 4:02 PM, Robert Goley wrote:
> I was able to get it built correctly using the 7.4 release. I have not
> had the chance to test it much but it built without any issues. That
> was not the case when I tried it previously but that has been a
> while.... As for 7.5, the errors were AC related. I got several
> warnings regarding quoting of TLS macros. Otherwise, it was just
> configure errors with xorg. It would build part of the dependencies and
> then bomb. All is good with 7.4 using the -static option. After I get
> this tested, I will move on to the Windows build.... :-(
>
>
> Robert
>
>
> On 09/30/2010 04:34 PM, DRC wrote:
>> 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
>
> --
> *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
