Bug#677861: lftp: FTBFS[kfreebsd-i386]: error: conflicting declaration 'typedef __int32_t gl_intptr_t'

2012-11-26 Thread Cyril Brulebois
Hello,

Michael Stapelberg stapelb...@debian.org (26/11/2012):
 Andreas Henriksson andr...@fatal.se writes:
  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.
 This is slightly off-topic, but aren’t porter boxes supposed to help
 with that? I fail to see how I can use them (e.g. fischer.debian.org) in
 this very case: I don’t have root access, so I cannot install the
 build-deps of lftp. Do I really have to send a request and wait for some
 human to install the deps before I can do any work on this?

yes: http://dsa.debian.org/doc/install-req/

Installed in fischer's sid chroot.

Mraw,
KiBi.


signature.asc
Description: Digital signature


Bug#677861: lftp: FTBFS[kfreebsd-i386]: error: conflicting declaration 'typedef __int32_t gl_intptr_t'

2012-11-26 Thread Andreas Henriksson
tags 677861 patch
thanks

On Mon, Nov 26, 2012 at 08:22:24PM +0100, Cyril Brulebois wrote:
[...]
 Installed in fischer's sid chroot.

Thanks. The attached patch works around the issue on kFreeBSD.
Build tested in the sid chroot on fischer.debian.org.

Hopefully kFreeBSD porters or package maintainers can now pick
this up and discuss a suitable long term solution for gnulib
on kFreeBSD with gnulib upstream?!

-- 
Andreas Henriksson
Description: prevent sys/_stdint.h from redefining intptr_t et.al.
Author: Andreas Henriksson andr...@fatal.se
Bug-Debian: http://bugs.debian.org/677861
Forwarded: no

--- lftp-4.3.6.orig/lib/stdint.in.h
+++ lftp-4.3.6/lib/stdint.in.h
@@ -75,6 +75,10 @@
  _@GUARD_PREFIX@_STDINT_H is defined.
  The include_next requires a split double-inclusion guard.  */
 # @INCLUDE_NEXT@ @NEXT_STDINT_H@
+#ifdef __FreeBSD_kernel__
+// prevent sys/_stdint.h from being included and redefine intptr_t et.al.
+#define _SYS__STDINT_H_
+#endif
 #endif
 
 #if ! defined _@GUARD_PREFIX@_STDINT_H  ! defined _GL_JUST_INCLUDE_SYSTEM_STDINT_H


signature.asc
Description: Digital signature


Bug#677861: lftp: FTBFS[kfreebsd-i386]: error: conflicting declaration 'typedef __int32_t gl_intptr_t'

2012-11-25 Thread Michael Stapelberg
Hi,

On Tue, 30 Oct 2012 14:04:42 -0700
Christoph Egger christ...@debian.org wrote:
 Andreas Henriksson andr...@fatal.se writes:
  I guess someone needs to untangle all the preprocessor and configure
  macros in lib/stdint.in.h.
  If someone from the kfreebsd camp could post the generated
  lib/stdint.h that would be helpful to be able to see things a bit
  more clearly.
Here is some further analysis:

lftp’s configure script checks for a working stdint.h and that test
fails on kfreebsd-i386 (tested on fischer.debian.org). 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

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.m4line=70numfiles=185#L70

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.

-- 
Best regards,
Michael


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#677861: lftp: FTBFS[kfreebsd-i386]: error: conflicting declaration 'typedef __int32_t gl_intptr_t'

2012-11-25 Thread Andreas Henriksson
Hello Michael Stapelberg!

On Sun, Nov 25, 2012 at 10:11:46PM +0100, Michael Stapelberg wrote:
 Here is some further analysis:

Thanks for this! I'll contribute by adding some further confusion below.

 
 lftp’s configure script checks for a working stdint.h and that test
 fails on kfreebsd-i386 (tested on fischer.debian.org). 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
 
 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.m4line=70numfiles=185#L70

Apparently this stdint.m4 file in src:m4 is not installed in any binary
package.

Additionally the header of src:m4 version of m4/stdint.m4 says:

# stdint.m4 serial 39
dnl Copyright (C) 2001-2011 Free Software Foundation, Inc.

While lftp packages m4/stdint.m4 says:

# stdint.m4 serial 43
dnl Copyright (C) 2001-2012 Free Software Foundation, Inc.


So it seems lftp's copy is actually newer?!?



 
 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.

According to random google searches it seems people are saying that
these defines should NOT be needed according to C++11 and that earlier
versions didn't say anything explicit at all about them.

See http://lists.gnu.org/archive/html/bug-gnulib/2011-12/msg00073.html
and the mailing list thread pointed out in the beginning of that mail.

(This makes me question the quoted part of the stdint.h from kfreebsd
libc headers above.)

I'm too confused right now to see an obvious solution, but fixing
kfreebsd libc headers still seems like a valid alternative to me.

-- 
Andreas Henriksson


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#677861: lftp: FTBFS[kfreebsd-i386]: error: conflicting declaration 'typedef __int32_t gl_intptr_t'

2012-11-25 Thread Andreas Henriksson
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.m4line=70numfiles=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


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#677861: lftp: FTBFS[kfreebsd-i386]: error: conflicting declaration 'typedef __int32_t gl_intptr_t'

2012-11-25 Thread Michael Stapelberg
Hi Andreas,

Thanks for your excellent further analysis of the problem at hand.

Andreas Henriksson andr...@fatal.se writes:
 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.
This is slightly off-topic, but aren’t porter boxes supposed to help
with that? I fail to see how I can use them (e.g. fischer.debian.org) in
this very case: I don’t have root access, so I cannot install the
build-deps of lftp. Do I really have to send a request and wait for some
human to install the deps before I can do any work on this?

-- 
Best regards,
Michael


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#677861: lftp: FTBFS[kfreebsd-i386]: error: conflicting declaration 'typedef __int32_t gl_intptr_t'

2012-10-30 Thread Andreas Henriksson
Hello Robert Millan!

On Thu, Jun 21, 2012 at 07:44:48PM +0200, Robert Millan wrote:
 2012/6/17 Christoph Egger christ...@debian.org:
  ../lib/stdint.h:295:18: error: 'gl_intptr_t' has a previous declaration as 
  'typedef long int gl_intptr_t'
 
 The problem is that lib/stdint.h is hijacking system headers with
 definitions such as:
 
 #define intptr_t gl_intptr_t
 #define uintptr_t gl_uintptr_t

It also does undef prior to that. So if system headers got
included first, it should work but it seems it gets included
after (and that's why it looks like the system header is defining
gl_intptr_t when it's really typedefing intptr_t).

Looks like lib/stdint.in.h tries to include the system header first,
if it has been detected as existing (and configure output seems to
indicate that it did find it).

I guess someone needs to untangle all the preprocessor and configure
macros in lib/stdint.in.h.
If someone from the kfreebsd camp could post the generated lib/stdint.h
that would be helpful to be able to see things a bit more clearly.

 
 causing them to missbehave. These defines need to be removed. If you
 want intptr_t, etc, you can get them from stdint.h as usual.

Just removing this part of stdint.in.h could be used as a hack to get things
to build on kfreebsd (since it's not used on linux), sure. That's not
suitable for upstream though
Another possibility to hack around the problem could be to add
#define __intptr_t_defined to stdint.in.h. Still ugly, but would
hopefully avoid breaking (upstream target) platforms that do need
the (re)defines.

Begs to be asked why kfreebsd headers aren't C99 compatible though... or
are the configure tests invalid? Or wait, I don't want to know.

-- 
Andreas Henriksson


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#677861: lftp: FTBFS[kfreebsd-i386]: error: conflicting declaration 'typedef __int32_t gl_intptr_t'

2012-10-30 Thread Christoph Egger
Andreas Henriksson andr...@fatal.se writes:
 I guess someone needs to untangle all the preprocessor and configure
 macros in lib/stdint.in.h.
 If someone from the kfreebsd camp could post the generated lib/stdint.h
 that would be helpful to be able to see things a bit more clearly.

For the version in wheezy

/* DO NOT EDIT! GENERATED AUTOMATICALLY! */
/* Copyright (C) 2001-2002, 2004-2012 Free Software Foundation, Inc.
   Written by Paul Eggert, Bruno Haible, Sam Steingold, Peter Burwood.
   This file is part of gnulib.

   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; either version 3, or (at your option)
   any later version.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.

   You should have received a copy of the GNU General Public License
   along with this program; if not, see http://www.gnu.org/licenses/.  */

/*
 * ISO C 99 stdint.h for platforms that lack it.
 * http://www.opengroup.org/susv3xbd/stdint.h.html
 */

#ifndef _GL_STDINT_H

#if __GNUC__ = 3
#pragma GCC system_header
#endif


/* When including a system file that in turn includes inttypes.h,
   use the system inttypes.h, not our substitute.  This avoids
   problems with (for example) VMS, whose sys/bitypes.h includes
   inttypes.h.  */
#define _GL_JUST_INCLUDE_SYSTEM_INTTYPES_H

/* On Android (Bionic libc), sys/types.h includes this file before
   having defined 'time_t'.  Therefore in this case avoid including
   other system header files; just include the system's stdint.h.
   Ideally we should test __BIONIC__ here, but it is only defined after
   sys/cdefs.h has been included; hence test __ANDROID__ instead.  */
#if defined __ANDROID__ \
 defined _SYS_TYPES_H_  !defined _SSIZE_T_DEFINED_
# include_next stdint.h
#else

/* Get those types that are already defined in other system include
   files, so that we can #define int8_t signed char below without
   worrying about a later system include file containing a typedef
   signed char int8_t; that will get messed up by our macro.  Our
   macros should all be consistent with the system versions, except
   for the fast types and macros, which we recommend against using
   in public interfaces due to compiler differences.  */

#if 1
# if defined __sgi  ! defined __c99
   /* Bypass IRIX's stdint.h if in C89 mode, since it merely annoys users
  with This header file is to be used only for c99 mode compilations
  diagnostics.  */
#  define __STDINT_H__
# endif

  /* Some pre-C++11 stdint.h implementations need this.  */
# ifdef __cplusplus
#  ifndef __STDC_CONSTANT_MACROS
#   define __STDC_CONSTANT_MACROS 1
#  endif
#  ifndef __STDC_LIMIT_MACROS
#   define __STDC_LIMIT_MACROS 1
#  endif
# endif

  /* Other systems may have an incomplete or buggy stdint.h.
 Include it before inttypes.h, since any #include stdint.h
 in inttypes.h would reinclude us, skipping our contents because
 _GL_STDINT_H is defined.
 The include_next requires a split double-inclusion guard.  */
# include_next stdint.h
#endif

#if ! defined _GL_STDINT_H  ! defined _GL_JUST_INCLUDE_SYSTEM_STDINT_H
#define _GL_STDINT_H

/* sys/types.h defines some of the stdint.h types as well, on glibc,
   IRIX 6.5, and OpenBSD 3.8 (via machine/types.h).
   AIX 5.2 sys/types.h isn't needed and causes troubles.
   MacOS X 10.4.6 sys/types.h includes stdint.h (which is us), but
   relies on the system stdint.h definitions, so include
   sys/types.h after stdint.h.  */
#if 1  ! defined _AIX
# include sys/types.h
#endif

/* Get LONG_MIN, LONG_MAX, ULONG_MAX.  */
#include limits.h

#if 1
  /* In OpenBSD 3.8, inttypes.h includes machine/types.h, which defines
 int{8,16,32,64}_t, uint{8,16,32,64}_t and __BIT_TYPES_DEFINED__.
 inttypes.h also defines intptr_t and uintptr_t.  */
# include inttypes.h
#elif 0
  /* Solaris 7 sys/inttypes.h has the types except the *_fast*_t types, and
 the macros except for *_FAST*_*, INTPTR_MIN, PTRDIFF_MIN, PTRDIFF_MAX.  */
# include sys/inttypes.h
#endif

#if 1  ! defined __BIT_TYPES_DEFINED__
  /* Linux libc4 = 4.6.7 and libc5 have a sys/bitypes.h that defines
 int{8,16,32,64}_t and __BIT_TYPES_DEFINED__.  In libc5 = 5.2.2 it is
 included by sys/types.h.  */
# include sys/bitypes.h
#endif

#undef _GL_JUST_INCLUDE_SYSTEM_INTTYPES_H

/* Minimum and maximum values for an integer type under the usual assumption.
   Return an unspecified value if BITS == 0, adding a check to pacify
   picky compilers.  */

#define _STDINT_MIN(signed, bits, zero) \
  ((signed) ? (- ((zero) + 1)  ((bits) ? (bits) - 1 : 0)) : (zero))

#define _STDINT_MAX(signed, bits, zero) \
  ((signed) \
   ? ~ _STDINT_MIN (signed, bits, zero) \
   : /* The expression for the unsigned 

Bug#677861: lftp: FTBFS[kfreebsd-i386]: error: conflicting declaration 'typedef __int32_t gl_intptr_t'

2012-10-14 Thread Steve McIntyre
On Wed, Aug 15, 2012 at 09:00:55PM +0200, Noël Köthe wrote:
forwarded 677861 
http://univ.uniyar.ac.ru/pipermail/lftp-devel/2012-July/28.html
thanks

Hello Jakub,

Am Samstag, den 11.08.2012, 14:04 +0200 schrieb Jakub Wilk:

 Thanks for the report and the comment. I forwarded it to the upstream 
 mailinglist.
 
 N.b. I can't find your e-mail in the lftp-devel archives.

yes, you were right. I asked Alexander the upstream author about and the
mail was in the mailman queue. It was now approved and it is available
in the mailinglist archive (see URL above). He will look at the problem.

Thanks for the hint.

Hi Noël,

Do you have any plan for getting this fixed so that we can ship lftp
with Wheezy? I can see that you've uploaded a new upstream version
since this was reported (and 4.3.8-1 looks to build OK on a test
machine for me), but the changes for from 4.3.6-1 (in current testing)
to 4.3.8-1 (current unstable) are *huge*, way too big for the release
team to accept them in my experience.

I would expect that a focussed TPU upload with just the changes needed
to fix kfreebsd building is much more likely to make it into wheezy.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Into the distance, a ribbon of black
Stretched to the point of no turning back


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#677861: lftp: FTBFS[kfreebsd-i386]: error: conflicting declaration 'typedef __int32_t gl_intptr_t'

2012-08-15 Thread Noël Köthe
forwarded 677861 
http://univ.uniyar.ac.ru/pipermail/lftp-devel/2012-July/28.html
thanks

Hello Jakub,

Am Samstag, den 11.08.2012, 14:04 +0200 schrieb Jakub Wilk:

 Thanks for the report and the comment. I forwarded it to the upstream 
 mailinglist.
 
 N.b. I can't find your e-mail in the lftp-devel archives.

yes, you were right. I asked Alexander the upstream author about and the
mail was in the mailman queue. It was now approved and it is available
in the mailinglist archive (see URL above). He will look at the problem.

Thanks for the hint.

-- 
Noël Köthe noel debian.org
Debian GNU/Linux, www.debian.org


signature.asc
Description: This is a digitally signed message part


Bug#677861: lftp: FTBFS[kfreebsd-i386]: error: conflicting declaration 'typedef __int32_t gl_intptr_t'

2012-08-11 Thread Jakub Wilk

Control: found -1 4.3.6-1

The problem is that lib/stdint.h is hijacking system headers with 
definitions such as:


#define intptr_t gl_intptr_t
#define uintptr_t gl_uintptr_t


But the purpose of lib/stdint.h is:
| /*
|  * ISO C 99 stdint.h for platforms that lack it.
|  * http://www.opengroup.org/susv3xbd/stdint.h.html
|  */

Now the question is: why is this file being used in the first place?

Thanks for the report and the comment. I forwarded it to the upstream 
mailinglist.


N.b. I can't find your e-mail in the lftp-devel archives.

--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#677861: lftp: FTBFS[kfreebsd-i386]: error: conflicting declaration 'typedef __int32_t gl_intptr_t'

2012-07-05 Thread Noël Köthe
tags 677861 + upstream
forwarded 677861 lftp-de...@uniyar.ac.ru
thanks

Hello,

Am Donnerstag, den 21.06.2012, 19:44 +0200 schrieb Robert Millan:
 2012/6/17 Christoph Egger christ...@debian.org:
  ../lib/stdint.h:295:18: error: 'gl_intptr_t' has a previous declaration as 
  'typedef long int gl_intptr_t'
 
 The problem is that lib/stdint.h is hijacking system headers with
 definitions such as:
 
 #define intptr_t gl_intptr_t
 #define uintptr_t gl_uintptr_t
 
 causing them to missbehave. These defines need to be removed. If you
 want intptr_t, etc, you can get them from stdint.h as usual.

Thanks for the report and the comment. I forwarded it to the upstream
mailinglist.

-- 
Noël Köthe noel debian.org
Debian GNU/Linux, www.debian.org


signature.asc
Description: This is a digitally signed message part


Bug#677861: lftp: FTBFS[kfreebsd-i386]: error: conflicting declaration 'typedef __int32_t gl_intptr_t'

2012-06-21 Thread Robert Millan
2012/6/17 Christoph Egger christ...@debian.org:
 ../lib/stdint.h:295:18: error: 'gl_intptr_t' has a previous declaration as 
 'typedef long int gl_intptr_t'

The problem is that lib/stdint.h is hijacking system headers with
definitions such as:

#define intptr_t gl_intptr_t
#define uintptr_t gl_uintptr_t

causing them to missbehave. These defines need to be removed. If you
want intptr_t, etc, you can get them from stdint.h as usual.

-- 
Robert Millan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#677861: lftp: FTBFS[kfreebsd-i386]: error: conflicting declaration 'typedef __int32_t gl_intptr_t'

2012-06-17 Thread Christoph Egger
Package: src:lftp
Version: 4.3.7-1
Severity: serious
Tags: sid wheezy
User: debian-...@lists.debian.org
Usertags: kfreebsd
X-Debbugs-Cc: debian-...@lists.debian.org
Justification: fails to build from source (but built successfully in the past)

Hi!

Your package failed to build on the kfreebsd-i386 buildds:

/bin/bash ../libtool --silent --tag=CXX   --mode=compile gcc -DHAVE_CONFIG_H 
-I. -I../lib -I../lib -I../trio  -I/usr/include/p11-kit-1
-D_FORTIFY_SOURCE=2  -g -O2 -fstack-protector --param=ssp-buffer-size=4 
-Wformat -Werror=format-security -g -Wall -Wall -Wwrite-strings 
-Woverloaded-virtual -fno-exceptions -fno-rtti -fno-implement-inlines -MT 
Resolver.lo -MD -MP -MF .deps/Resolver.Tpo -c -o Resolver.lo Resolver.cc
In file included from /usr/include/sys/kern/types.h:71:0,
 from /usr/include/sys/kern/param.h:67,
 from /usr/include/osreldate.h:1,
 from /usr/include/i386-kfreebsd-gnu/sys/param.h:39,
 from /usr/include/arpa/nameser.h:59,
 from Resolver.cc:40:
/usr/include/sys/_stdint.h:74:21: error: conflicting declaration 'typedef 
__int32_t gl_intptr_t'
In file included from /usr/include/netinet/in.h:24:0,
 from network.h:33,
 from Resolver.h:29,
 from Resolver.cc:25:
../lib/stdint.h:295:18: error: 'gl_intptr_t' has a previous declaration as 
'typedef long int gl_intptr_t'
In file included from /usr/include/sys/kern/types.h:71:0,
 from /usr/include/sys/kern/param.h:67,
 from /usr/include/osreldate.h:1,
 from /usr/include/i386-kfreebsd-gnu/sys/param.h:39,
 from /usr/include/arpa/nameser.h:59,
 from Resolver.cc:40:
/usr/include/sys/_stdint.h:78:22: error: conflicting declaration 'typedef 
__uintptr_t gl_uintptr_t'
In file included from /usr/include/netinet/in.h:24:0,
 from network.h:33,
 from Resolver.h:29,
 from Resolver.cc:25:
../lib/stdint.h:296:27: error: 'gl_uintptr_t' has a previous declaration as 
'typedef long unsigned int gl_uintptr_t'
make[2]: *** [Resolver.lo] Error 1
make[2]: Leaving directory 
`/build/buildd-lftp_4.3.7-1-kfreebsd-i386-lAjblU/lftp-4.3.7/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory 
`/build/buildd-lftp_4.3.7-1-kfreebsd-i386-lAjblU/lftp-4.3.7'
make: *** [build-stamp] Error 2
dpkg-buildpackage: error: debian/rules build-arch gave error exit status
2

Full build log at
https://buildd.debian.org/status/fetch.php?pkg=lftparch=kfreebsd-i386ver=4.3.7-1stamp=1339520753

Regards

Christoph

If you have further questions please mail debian-...@lists.debian.org

-- 
9FED 5C6C E206 B70A 5857  70CA 9655 22B9 D49A E731
Debian Developer | Lisp Hacker | CaCert Assurer



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org