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
