Hello!
> I don't know anything about _BSDTYPES_DEFINED but it sounds like some
> autotools solution is already in place, which defines
> __{u_char,daddr_t}_defined; it's hard to imagine a patch fixing that
> autotools stuff to correctly differentiate cbuild from ctarget would be
> poo-poo'ed by the glibc folks (or, for that matter, whatever upstream
> glibc's autotools scripts might be relying on for this).
This is not about autotools. This particular code fragment does not rely on
autotools. It's just the following text in .h file:
--- cut ---
#ifndef __u_char_defined
typedef __u_char u_char;
typedef __u_short u_short;
typedef __u_int u_int;
typedef __u_long u_long;
typedef __quad_t quad_t;
typedef __u_quad_t u_quad_t;
typedef __fsid_t fsid_t;
# define __u_char_defined
#endif
#ifndef __daddr_t_defined
typedef __daddr_t daddr_t;
typedef __caddr_t caddr_t;
# define __daddr_t_defined
#endif
--- cut ---
Looks like this should work for some hypothetical system which doesn't have
things like u_char etc. Here __u_char and friends appear to be own versions,
defined somewhere by glibc code itself. This code causes 'type redefinition'
error because we actually have u_char but don't have accompanying indicator.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
