[tlbuild] lcdf-typetools-2.78 -- is hashcode() unsigned, uint32_t, or size_t
Ken Brown
kbrow1i at gmail.com
Tue May 19 17:25:27 CEST 2009
On 4/30/2009 9:27 AM, Peter Breitenlohner wrote:
> On Thu, 30 Apr 2009, Angelo Graziosi wrote:
>
> Hi Eddie,
>
> here a report from an attempt to build lcdf-typetools for TeX Live.
>
>>> On current Cygwin (1.5.25-15) it fails, without applying any
>>> *patches*, as follow:
>>> CC='gcc-4' CXX='g++-4' CPP='cpp-4' CFLAGS='-Wno-write-strings
>>> -Wno-attributes' CXXFLAGS='-Wno-write-strings -Wno-attributes'
>>> LDFLAGS='-Wl,--enable-auto-import -Wl,--enable-runtime-pseudo-reloc'
>>> TL_CONFIGURE_ARGS='--disable-xetex --without-graphite' ./Build
>>> [...]
>>> g++-4 -W -Wall -DHAVE_CONFIG_H -I.
>>> -I../../../../texk/lcdf-typetools/liblcdf -I..
>>> -I../../../../texk/lcdf-typetools/include -Wno-write-strings
>>> -Wno-attributes -MT string.o -MD -MP -MF .deps/string.Tpo -c -o
>>> string.o ../../../../texk/lcdf-typetools/liblcdf/string.cc
>>> ../../../../texk/lcdf-typetools/liblcdf/string.cc:535: error:
>>> prototype for 'uint32_t String::hashcode(const char*, const char*)'
>>> does not match any in class 'String'
>>> ../../../../texk/lcdf-typetools/include/lcdf/string.hh:261: error:
>>> candidates are: unsigned int String::hashcode() const
>>> ../../../../texk/lcdf-typetools/include/lcdf/string.hh:250: error:
>>> static unsigned int String::hashcode(const unsigned char*, const
>>> unsigned char*)
>>> ../../../../texk/lcdf-typetools/include/lcdf/string.hh:246: error:
>>> static unsigned int String::hashcode(const char*, const char*)
>>> make[6]: *** [string.o] Error 1
>> [...]
>>
>> Applying only this patch, seems to solve many problems...
>> =======================================
>> diff -Naur
>> texlive-source.orig/texk/lcdf-typetools/include/lcdf/string.hh
>> texlive-source/texk/lcdf-typetools/include/lcdf/string.hh
>> --- texlive-source.orig/texk/lcdf-typetools/include/lcdf/string.hh
>> 2009-03-20 10:50:07.000000000 +0100
>> +++ texlive-source/texk/lcdf-typetools/include/lcdf/string.hh
>> 2009-04-30 10:16:19.328125000 +0200
>> @@ -243,10 +243,10 @@
>> * @invariant If end1 - begin1 == end2 - begin2 and memcmp(begin1,
>> begin2,
>> * end1 - begin1) == 0, then hashcode(begin1, end1) ==
>> hashcode(begin2,
>> * end2). */
>> - static unsigned hashcode(const char *begin, const char *end);
>> + static uint32_t hashcode(const char *begin, const char *end);
>>
>> /** @overload */
>> - static inline unsigned hashcode(const unsigned char *begin,
>> + static inline uint32_t hashcode(const unsigned char *begin,
>> const unsigned char *end) {
>> return hashcode(reinterpret_cast<const char *>(begin),
>> reinterpret_cast<const char *>(end));
>> @@ -258,7 +258,7 @@
>> * "SuperFastHash."
>> *
>> * @invariant If s1 == s2, then s1.hashcode() == s2.hashcode(). */
>> - inline unsigned hashcode() const {
>> + inline uint32_t hashcode() const {
>> return length() ? hashcode(begin(), end()) : 0;
>> }
>> =======================================
>
> Interestingly this problem show up for neither Cygwin 1.7, Linux, Solaris,
> nor Mac OS X. The declaration, implementation, and use of hashcode() are,
> however, inconsistent but I somewhat hesitate to apply to patch above
> because the file include/lcdf/string.hh does not include any header that
> might be required to declare uint32_t.
>
> Can you please clarify this.
>
> Regards
> Peter
Hi Peter,
Did you ever get a response from Eddie? I'm asking because Karl has
asked Angelo and me to get all of our proposed patches together and send
them to the appropriate upstream people. But I don't know if we should
contact Eddie about this or if it's better for you to try again.
Regards,
Ken
More information about the tlbuild
mailing list