This one time, at band camp, Stephen Gran said:
> > Could you try new glibc 2.3.2-2?
>
> Still fails. -fpermissive downgrades it to a warning, allowing the
> build to complete, though, so at least there's a workaround.
Scratch that. -fpermissive no longer allows it to build - I just didn't
wait long enough to get to the part that fails. It seems that the ISO
C++ issue has been resolved, only to be replaced by a new one. Some
change in this version gives me a new error:
In file included from /usr/include/linux/cdrom.h:14,
from audiocd.h:33,
from cddbaccessdialog.h:31,
from cddbaccessdialogdata.cpp:10:
/usr/include/asm/byteorder.h:38: error: syntax error before `(' token
/usr/include/asm/byteorder.h:42: error: '__u64' is used as a type, but is not
defined as a type.
/usr/include/asm/byteorder.h:43: error: syntax error before `}' token
/usr/include/asm/byteorder.h:44: error: syntax error before `.' token
/usr/include/asm/byteorder.h:50: error: syntax error before `.' token
/usr/include/asm/byteorder.h:51: error: syntax error before `.' token
/usr/include/asm/byteorder.h:52: error: syntax error before `:' token
In file included from /usr/include/linux/byteorder/little_endian.h:11,
from /usr/include/asm/byteorder.h:65,
from /usr/include/linux/cdrom.h:14,
from audiocd.h:33,
from cddbaccessdialog.h:31,
from cddbaccessdialogdata.cpp:10:
/usr/include/linux/byteorder/swab.h:199: error: syntax error before `(' token
/usr/include/linux/byteorder/swab.h:209: error: syntax error before `(' token
/usr/include/linux/byteorder/swab.h:213: error: `__u64' was not declared in
this scope
/usr/include/linux/byteorder/swab.h:213: error: `addr' was not declared in this
scope
/usr/include/linux/byteorder/swab.h:214: error: variable or field `__swab64s'
declared void
/usr/include/linux/byteorder/swab.h:214: error: `__swab64s' declared as an
`inline' variable
/usr/include/linux/byteorder/swab.h:214: error: syntax error before `{' token
The relevant lines from byteorder.h are (lines 38-53):
static inline __u64 ___arch__swab64(__u64 val)
{
union {
struct { __u32 a,b; } s;
__u64 u;
} v;
v.u = val;
#ifdef CONFIG_X86_BSWAP
asm("bswapl %0 ; bswapl %1 ; xchgl %0,%1"
: "=r" (v.s.a), "=r" (v.s.b)
: "0" (v.s.a), "1" (v.s.b));
#else
v.s.a = ___arch__swab32(v.s.a);
v.s.b = ___arch__swab32(v.s.b);
asm("xchgl %0,%1" : "=r" (v.s.a), "=r" (v.s.b) : "0" (v.s.a), "1" (v.s.b));
#endif
and swab.h (lines 198-216):
#ifdef __BYTEORDER_HAS_U64__
static __inline__ __const__ __u64 __fswab64(__u64 x)
{
# ifdef __SWAB_64_THRU_32__
__u32 h = x >> 32;
__u32 l = x & ((1ULL<<32)-1);
return (((__u64)__swab32(l)) << 32) | ((__u64)(__swab32(h)));
# else
return __arch__swab64(x);
# endif
}
static __inline__ __u64 __swab64p(__u64 *x)
{
return __arch__swab64p(x);
}
static __inline__ void __swab64s(__u64 *addr)
{
__arch__swab64s(addr);
}
I must say I don't immediately see the problem there. Perhaps we're
barking up the wrong tree here, and this is a problem with g{cc,++}
barfing on perfectly good code?
--
-----------------------------------------------------------------
| ,''`. Stephen Gran |
| : :' : sgran@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
Attachment:
pgpdM8rVXUeWh.pgp
Description: PGP signature