Re: Compilation failure for libunistring-0.9.3 on ia64 hpux 11.23 and 11.31

[Gary V. Vaughan]

Ping number 4.

Should I stop pinging every week and assume upstream does not want
ia64 hpux compatibility? Guile-2.0.0 depends on libunistring, so an
important part of GNU does not work on ia64 unless each user who
needs it is prepared to diagnose and fix the release locally. HP is
moving from hppa to ia64, so there will come a time where Guile
does not build on a currently supported HP machine...

On Sat, Apr 23, 2011 at 05:12:23PM +0700, Gary V. Vaughan wrote:
> Hi Bruno,
> 
> Either I haven't been able to reach you at your clisp address, or your
> responses have not reached me, so I'm reposting to bug-gnulib.
> 
> On Sun, Apr 17, 2011 at 11:18:44AM +0700, Gary V. Vaughan wrote:
> > Ping?
> > 
> > On Wed, Apr 13, 2011 at 12:57:40AM +0700, Gary V. Vaughan wrote:
> > > Not sure whether this is the gnulib stdbool tests gone awry or a bug
> > > in libunistring itself... I suspect the latter because some files
> > > include <stdbool.h> and get the system stdbool which defines bool as
> > > _Bool, where others include "unistring/stdbool.h" which doesn't trust
> > > the system bool declaration and sets it to unsigned char.
> > > 
> > > This results in a prototype mistmatch when compiling
> > > lib/unicase/u16-is-invariant.c, which first includes unicase/invariant.h,
> > > which itself includes <stdbool.h> so that the prototypes in
> > > unicase/invariant.h are declared with bool expanded to _Bool.
> > > 
> > > Then a few lines further down, unicase/u16-is-invariant.c includes
> > > "unistr.h", which includes "unistring/stdbool.h", and that changes the
> > > bool definition so that when unicase/u-is-invariant.h is pulled in at
> > > the end of the file, the function definitions now have bool expanded to
> > > unsigned char, which the compiler flags as a type mismatch error.
> > > 
> > > I can force the compilation of that file through by passing 
> > > -D_GL_STDBOOL_H
> > > (which is obviously wrong, but might be a useful data point) to make
> > > sure that compilation unit gets only the system bool definition... but 
> > > then
> > > I get a similar error on the next file.
> > > 
> > > cc -DHAVE_CONFIG_H -DNO_XMALLOC -I. -I..  -I. -I. -I.. -I.. 
> > > -DIN_LIBUNISTRING -DDEPENDS_ON_LIBICONV=1 
> > > -I/opt/TWWfsw/libiconv113/include -z +O2 +Olit=all +Ofltacc +Oentrysched 
> > > +Odataprefetch -c unicase/u16-is-invariant.c
> > > "unicase/u-is-invariant.h", line 19: error #2147: declaration is 
> > > incompatible
> > >           with "int u16_is_invariant(const unistring_uint16_t *, size_t,
> > >           unistring_uint16_t *(*)(const unistring_uint16_t *, size_t, 
> > > const
> > >           char *, uninorm_t, unistring_uint16_t *, size_t *), const char 
> > > *,
> > >           _Bool *)" (declared at line 33 of "./unicase/invariant.h")
> > >   FUNC (const UNIT *s, size_t n,
> > >   ^
> > > 
> > > 1 error detected in the compilation of "unicase/u16-is-invariont.c".
> > > 
> > > yukio% grep -i bool config.h
> > > /* Define to 1 if stdbool.h conforms to C99. */
> > > #define HAVE_STDBOOL_H 1
> > > /* Define to 1 if the system has the type `_Bool'. */
> > > #define HAVE__BOOL 1
> > > 
> > > Is this a known bug?  Can I pull a fix from somewhere?  Or is there
> > > anything I can provide to help you track down the root cause of the bug?
> > > 
> > > [there was no bug address in configure.ac, so I took the liberty of
> > >  contacting you directly.  Please forward this message to an appropriate
> > >  mailing list and continue the thread there if you prefer, but please
> > >  keep this address in the Cc:.]
> 
> I was able to solve this particular problem by replacing all references
> to unistring/stdbool.h with stdbool.h so that the same definitions are
> present everywhere.  Applying this change and recompiling even on Linux
> doesn't affect the testsuite results, though I can't imagine that you
> would have gone to the trouble of patching the gnulib files to include
> a second stdbool.h if there weren't good reason... am I missing something,
> or were my hosts perhaps not affected by whatever you were fixing with
> the additional stdbool.h?
> 
> Also I have a couple of other small changes I had to make to compile
> libunistring-0.9.3 on all the architectures I have access to.  Please
> contact me off-list if you'd like the patches.

Cheers,
-- 
Gary V. Vaughan (address@hidden)