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
