Suggestion: improve cross-compiling ability

Fedin Pavel p.fedin@samsung.com
Tue Jul 9 10:39:00 GMT 2013


 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



More information about the Cygwin mailing list