For some odd reason, my system had gcj installed but not libgcj (not sure how it managed that.) Anyway, it's fixed, and I've updated configure.ac and the build requirements. I also discovered that a newer pkgconfig is required if building Xvnc, to get the PKG_CHECK_EXISTS macro (I similarly used the SRPM from Fedora 5.)
Will spin a new build soon. I wanted to look at the full-screen maximize issue on Windows first. On 5/11/11 7:48 AM, Franz Sirl wrote: > Hi, > > I checked and the minimum version for gettext is 0.14.4. The crucial > point is if gettext.m4 contains code like "return (int) gettext (..." > (fails on 64bit) or "return * gettext (..." (works on 64bit). > > I updated my CentOS4.9 VM with > > > http://archive.fedoraproject.org/pub/archive/fedora/linux/core/5/source/SRPMS/gettext-0.14.5-3.src.rpm > > > I used "rpm --rebuild" to build it on 4.9, installed it, ran "autoreconf > -fi" in the tigervnc sources and copied these sources to my > SLES11SP1/x86_64 machine. "configure --enable-nls" then worked fine and > "make/make install" created the *.mo files. > > Franz. > > > Am 2011-05-11 11:33, schrieb DRC: >> I think his point was that upgrading to a newer gettext is necessary to >> fix a bug whereby configure doesn't properly detect NLS support. What >> I'm asking for is the minimum version of gettext that fixes the issue, >> so I can upgrade my own build server and thus ensure that the source >> tarball we distribute doesn't have the bug. >> >> I think it would be appropriate to require this newer version of >> gettext, assuming it is straightforward to compile on RHEL 4. >> >> >> On 5/11/11 3:36 AM, Adam Tkac wrote: >>> Hello, >>> >>> about the 64bit gettext issue. AFAIK this is due following line in >>> configure.ac: >>> >>> AM_GNU_GETTEXT_VERSION([0.14.1]) >>> >>> It is needed to build TigerVNC on RHEL-4 and was added long time ago, >>> before TigerVNC was founded. If we bump this number, TigerVNC won't be >>> compilable on RHEL-4. >>> >>> For now I would keep macro written above in place, till we drop support >>> for RHEL-4& similar systems. For distributions I recommend to put >>> something like this into their build scripts: >>> >>> sed -i 's/AM_GNU_GETTEXT_VERSION.*/AM_GNU_GETTEXT_VERSION([0.18.1])/' >>> configure.ac >>> >>> Regards, Adam >>> >>> On 05/10/2011 08:21 PM, DRC wrote: >>>> As far as the autotools, can you identify which version would minimally >>>> fix the problem? If so, I will make sure my build server is >>>> updated. I >>>> recently got a new workstation that I am using in part as my Linux >>>> build >>>> server, and it runs RHEL 5 (the old one ran RHEL 4.) I had high hopes >>>> that I would be able to build TigerVNC and other software on RHEL 5 >>>> using the RHEL 4 backward compatibility libraries and still maintain >>>> compatibility with RHEL 4, but unfortunately, those compatibility >>>> libraries don't work properly with C++ (argh!) Thus, I'm back to >>>> building on RHEL 4, which is now running in a virtual machine. >>>> >>>> >>>> On 5/10/11 4:34 AM, Franz Sirl wrote: >>>>> Hi, >>>>> >>>>> with 1.0.90-20110429 the bug 3290864 >>>>> http://sourceforge.net/tracker/?func=detail&aid=3290864&group_id=254363&atid=1126848 >>>>> >>>>> I reported is fully fixed for me. >>>>> No keyrepeat problem anymore, the Windows-EXE doesn't crash the >>>>> standard >>>>> SLES11SP1 Xvnc anymore, the prebuilt Xvnc Linux binary works fine and >>>>> also no build problems. >>>>> >>>>> However, as I like to use packages on my servers, I stumbled over a >>>>> few >>>>> minor things while building. >>>>> First, for the release you should update your autotools and run >>>>> 'autoreconf -fi' (maybe fix the warnings that show up too), >>>>> otherwise an >>>>> outdated gettext.m4 will fail to detect glibc NLS support on 64-bit >>>>> platforms (with --enable-nls), because a pointer is casted to (int). >>>>> Second, after some thinking I decided to build a tigervnc-Xvnc as a >>>>> subpackage of the SLES11SP1 xorg-x11-server source RPM. This way I can >>>>> follow any xserver package updates (security, whatever) easily. >>>>> Integration required changing tigervnc's build procedure a bit. >>>>> Instead >>>>> of copying xserver sources to tigervnc source tree, I copied tigervnc >>>>> sources into the xserver source tree. This works nicely, but required >>>>> some minor changes to the tigervnc sources, as you can see in the >>>>> attached patch. >>>>> tigervnc-rpm1.patch is a replacement for the mi/miinitext.c part of >>>>> xserver16.patch (without it some parts of xserver will complain about >>>>> the missing vncExtensionInit definition during linking). >>>>> tigervnc-rpm2.patch contains the corresponding change to the tigervnc >>>>> source. >>>>> I hope these 2 can be applied to your repository. >>>>> >>>>> I have an additional hunk for vnc/Makefile.am, but this one is not >>>>> appropriate for general use (and can also be done via the make >>>>> invocation, maybe you prepend LIB_DIR with TIGERVNC_ though): >>>>> -TIGERVNC_SRCDIR=${top_srcdir}/../.. >>>>> -LIB_DIR=${top_builddir}/../../common >>>>> +TIGERVNC_SRCDIR=${top_srcdir}/tigervnc >>>>> +LIB_DIR=${top_builddir}/tigervnc/common >>>>> >>>>> Is there a way turn this into an autoconf option like >>>>> --enable-tigervnc-within-xserver? I don't know autoconf enough to do >>>>> that myself. >>>>> >>>>> I can also post the resulting spec-file (or a diff with the >>>>> changes) if >>>>> it is considered OK for this list. >>>>> >>>>> Franz >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> Achieve unprecedented app performance and reliability >>>>> What every C/C++ and Fortran developer should know. >>>>> Learn how Intel has extended the reach of its next-generation tools >>>>> to help boost performance applications - inlcuding clusters. >>>>> http://p.sf.net/sfu/intel-dev2devmay >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Tigervnc-devel mailing list >>>>> Tigervnc-devel@lists.sourceforge.net >>>>> https://lists.sourceforge.net/lists/listinfo/tigervnc-devel >>>> ------------------------------------------------------------------------------ >>>> >>>> Achieve unprecedented app performance and reliability >>>> What every C/C++ and Fortran developer should know. >>>> Learn how Intel has extended the reach of its next-generation tools >>>> to help boost performance applications - inlcuding clusters. >>>> http://p.sf.net/sfu/intel-dev2devmay >>>> _______________________________________________ >>>> Tigervnc-devel mailing list >>>> Tigervnc-devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/tigervnc-devel >>> >> >> ------------------------------------------------------------------------------ >> >> Achieve unprecedented app performance and reliability >> What every C/C++ and Fortran developer should know. >> Learn how Intel has extended the reach of its next-generation tools >> to help boost performance applications - inlcuding clusters. >> http://p.sf.net/sfu/intel-dev2devmay >> _______________________________________________ >> Tigervnc-devel mailing list >> Tigervnc-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/tigervnc-devel >> >> > ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
