bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: build failures


From: Bruno Haible
Subject: Re: build failures
Date: Sun, 7 Aug 2011 22:38:39 +0200
User-agent: KMail/1.13.6 (Linux/2.6.37.6-0.5-desktop; KDE/4.6.0; x86_64; ; )

Hi Simon,

> >> unictype/categ_LC.c:27: error: 'UC_CATEGORY_MASK_LC' undeclared here
> >> (not in a function)
> >> make[4]: *** [unictype/categ_LC.o] Error 1
> >
> > It looks like the generated unictype.h file is broken (possibly empty?).
> > Can you compare unictype.in.h with unictype.h? Was there an error when it
> > was created? What happens if you remove it and try "make" again?
> 
> There is no unictype.h file!
> 
> address@hidden:~/src/gnulib/m master$ find . -name unictype.h
> address@hidden:~/src/gnulib/m master$ 
> 
> I have libunistring installed in /usr/local on my machine, which
> explains why building doesn't complain about missing unictype.h.

Yes, it explains that, but then the compilation should find the
/usr/local/include/unictype.h file, and it should contain a definition
of UC_CATEGORY_MASK_LC. The output of "gcc -E ..." ought to provide more
details.

> I can create unictype.h manually:
> 
> cd gllib
> make unictype.h
> 
> and then building and linking works fine.  I assume there is some
> missing dependency to generate unictype.h?

I guess the gl_LIBUNISTRING_LIBHEADER([0.9], [unictype.h]) invocation
detected that the installed unictype.h could be used (given the version
numbers), but it was incomplete.

> >> In file included from unictype/test-combiningclass_name.c:17:
> >> ./config.h:1990:1: warning: "HAVE_DECL_TCGETSID" redefined
> >> In file included from ./config.h:64,
> >>                  from unictype/test-combiningclass_name.c:17:
> >> ./../config.h:1975:1: warning: this is the location of the previous 
> >> definition
> >
> > What is the result of
> > $ grep -i tcgetsid config.status gltests/config.status
> 
> Same on both hurd and debian squeeze:
> 
> config.status:S["HAVE_DECL_TCGETSID"]="0"
> config.status:S["GNULIB_TCGETSID"]="1"
> config.status:D["HAVE_DECL_TCGETSID"]=" 0"
> config.status:D["HAVE_TCGETSID"]=" 1"
> config.status:D["GNULIB_TEST_TCGETSID"]=" 1"
> config.status:D["HAVE_RAW_DECL_TCGETSID"]=" 1"
> gltests/config.status:S["HAVE_DECL_TCGETSID"]="1"
> gltests/config.status:S["GNULIB_TCGETSID"]="1"
> gltests/config.status:D["HAVE_DECL_TCGETSID"]=" 1"
> gltests/config.status:D["HAVE_TCGETSID"]=" 1"
> gltests/config.status:D["GNULIB_TEST_TCGETSID"]=" 1"
> gltests/config.status:D["HAVE_RAW_DECL_TCGETSID"]=" 1"

Since in both cases the 'tcgetsid' module is present, which depends on 
'extensions', so that _GNU_SOURCE gets defined, which causes the declaration
of tcgetsid() to be enabled, I'm wondering why this:
  > config.status:S["HAVE_DECL_TCGETSID"]="0"
  > config.status:D["HAVE_DECL_TCGETSID"]=" 0"

Can you look in config.log what gcc error caused this wrong value for
HAVE_DECL_TCGETSID?

Bruno
-- 
In memoriam Szczepan Ścibior <http://pl.wikipedia.org/wiki/Szczepan_Ścibior> 
<http://home.clara.net/clinchy/neeb5.htm>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]