I can't get that SRPM to rebuild. I get
cpio: gettext-0.14.5/gettext-runtime/libasprintf/<internal>: No such
file or directory
cpio: gettext-0.14.5/gettext-tools/lib/<internal>: No such file or directory
cpio: gettext-0.14.5/gettext-tools/src/<internal>: No such file or directory
cpio: gettext-0.14.5/gettext-tools/src/plural.y: No such file or directory
...
RPM build errors:
File not found by glob:
/var/tmp/gettext-0.14.5-root/usr/lib64/gettext/gnu.gettext.*
File not found by glob:
/var/tmp/gettext-0.14.5-root/usr/lib64/gettext/gnu.gettext.*
Same error when attempting to rebuild the gettext 0.14.6 SRPM from
CentOS 5.5. I'm thinking my system is missing something that the build
needs, but I'm not sure what.
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
