Re: Bug#677861: lftp: FTBFS[kfreebsd-i386]: error: conflicting declaration 'typedef __int32_t gl_intptr_t'
Hello again!
After looking more at this I think I'm less confused now....
On Sun, Nov 25, 2012 at 11:22:28PM +0100, Andreas Henriksson wrote:
> > lftp’s configure script checks for a working stdint.h and that test
> > fails on kfreebsd-i386 (tested on fischer.debian.org).
Please note that the check for a C99 conformant stdint.h also
fails on i386 linux (and all others as well?)....
so that's not kfreebsd-specific!
> > The test contains
> > these lines at the top of the file:
> >
> > #define _GL_JUST_INCLUDE_SYSTEM_STDINT_H 1
> > #include <stdint.h>
> >
> > #if !(defined WCHAR_MIN && defined WCHAR_MAX)
> > #error "WCHAR_MIN, WCHAR_MAX not defined in <stdint.h>"
> > #endif
> >
> > However, libc0.1-dev:kfreebsd-i386’s /usr/include/stdint.h defines
> > WCHAR_MIN and others within a block that is guarded by:
> >
> > /* The ISO C99 standard specifies that in C++ implementations these
> > macros should only be defined if explicitly requested. */
> > #if !defined __cplusplus || defined __STDC_LIMIT_MACROS
The same guard is used in /usr/include/stdint.h on linux eglibc!
The test is built using C++, so this is the cause for the failure
on all architectures... but again not kFreeBSD specific.
> >
> > Looking at the current version of the corresponding m4 file, it seems
> > like this was already fixed in autotools:
> > http://codesearch.debian.net/show?file=m4_1.4.16-3%2Fm4%2Fstdint.m4&line=70&numfiles=185#L70
Actually, this was in gnulib but was dropped because it broke stuff:
http://git.savannah.gnu.org/cgit/gnulib.git/commit/m4/stdint.m4?id=501af6ba6cbdb199856d2a12f8a1ee754e7bd2ae
http://git.savannah.gnu.org/cgit/gnulib.git/commit/m4/stdint.m4?id=efd3a9be2cb5340e953dad2bc324bc14f6903b1f
So lftp stdint.m4 is actually newer then the one pointed to in the m4 source.
> >
> > I therefore think that this bug can be fixed by "simply" rebuilding
> > lftp’s configure. However, I have no clue on what the best way to do
> > this is, so I’ll leave that up to somebody else.
True. I do think we can revert what upstream did to hopefully get
further in the build process (by not having to involve the gnulib
version of stdint.h at all), but I wonder if it's a good idea to
go directly against gnulib upstream like that.....
Since gnulib is supposed to help us out with portability, fixing
it in any case would probably be a good idea.
I think the problem is something like this:
lftp includes (gnu)lib/stdint.h, which includes_next /usr/include/stdint.h,
then it undef and redefines intptr_t et.al. Standard include guards protect
the include files against being re-included again.
This is enough on Linux .... unfortunately not on kFreeBSD, because
/usr/include/sys/_stdint.h gets pulled in by other headers later on
and this header has not been included before and also tries to define
intptr_t (which is already redefined to gl_intptr_t, thus giving the crazy
looking error message in the build log).
The definitions of intptr_t are conditional in both places,
but they use DIFFERENT conditions!
>From /usr/include/stdint.h:
# ifndef __intptr_t_defined
typedef int intptr_t;
# define __intptr_t_defined
# endif
>From /usr/include/sys/_stdint.h:
#ifndef _INTPTR_T_DECLARED
typedef __intptr_t intptr_t;
#define _INTPTR_T_DECLARED
#endif
(I have no idea how these are prevented from clashing on kFreeBSD
in general.)
I see two versions of basically the same fix for gnulib. When doing
#include_next <stdint.h> from lib/stdint.h, also do either:
#include <sys/_stdint.h>
or to just prevent it from being included:
#define _SYS__STDINT_H_
(Another version would be to go for the more fine grained guards
and define _INTPTR_T_DECLARED et.al.... but that is probably less
likely to be a solution that works good in the long run.)
Hopefully the explanation of this mail makes more sense.
Anyone with a kFreeBSD installation are welcome to try to build
lftp with any of the solutions discussed to see how much further
this gets us.....
--
Andreas Henriksson
Reply to: