Suggestion: improve cross-compiling ability

Suggestion: improve cross-compiling ability

[Fedin Pavel]

 Hello! I have got one small idea on how to improve compatibility with
cross-compiling Linux software. This time it's glibc.

 At certain point glibc's rpcgen program (which is being compiled for host),
relies on '#ifndef __u_char_defined' and '#ifndef __daddr_t_defined' in
order to determine presence of 'u_char' and 'daddr_t' respectively (see
libc/sunrpc/rpc/types.h). I have to patch this to add _BSDTYPES_DEFINED
check in order to be able to cross-build glibc under Cygwin.
 What if we add also these Linux-style definitions to our includes ?

 P.S. I understand that actually it's glibc needs fixing because the same
will happen on any other non-Linux OS. But i believe FSF will simply say "we
don't care" and won't accept this fix.

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

Re: Suggestion: improve cross-compiling ability

[Yaakov (Cygwin/X)]

On 2013-07-08 07:07, Fedin Pavel wrote:
>   Hello! I have got one small idea on how to improve compatibility with
> cross-compiling Linux software. This time it's glibc.
>
>   At certain point glibc's rpcgen program (which is being compiled for host),
> relies on '#ifndef __u_char_defined' and '#ifndef __daddr_t_defined' in
> order to determine presence of 'u_char' and 'daddr_t' respectively (see
> libc/sunrpc/rpc/types.h). I have to patch this to add _BSDTYPES_DEFINED
> check in order to be able to cross-build glibc under Cygwin.
>   What if we add also these Linux-style definitions to our includes ?

Actually, I just fixed this in CVS last week:

http://sourceware.org/ml/newlib/2013/msg00521.html
http://sourceware.org/ml/newlib-cvs/2013-q3/msg00005.html

This will be in Cygwin 1.7.21 when released; in the meantime, it is safe 
to apply that patch to your existing /usr/include/sys/types.h.

BTW, following up on the previous discussion wrt cross-compiling the 
Linux kernel, my stdint patch is now in the kbuild and linux-next trees 
as commit b35310627f396efcc25d71fb343b3aa02039d20d; hopefully it will 
get into 3.11, but it is also necessary for (and applies clean to) all 
stable branches since 3.3.

HTH,


Yaakov


--
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

RE: Suggestion: improve cross-compiling ability

[Fedin Pavel]

 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

Re: Suggestion: improve cross-compiling ability

[Greg Turner]

On Mon, Jul 8, 2013 at 5:07 AM, Fedin Pavel <p.fedin@samsung.com> wrote:
>  Hello! I have got one small idea on how to improve compatibility with
> cross-compiling Linux software. This time it's glibc.
>
>  At certain point glibc's rpcgen program (which is being compiled for host),
> relies on '#ifndef __u_char_defined' and '#ifndef __daddr_t_defined' in
> order to determine presence of 'u_char' and 'daddr_t' respectively (see
> libc/sunrpc/rpc/types.h). I have to patch this to add _BSDTYPES_DEFINED
> check in order to be able to cross-build glibc under Cygwin.
>  What if we add also these Linux-style definitions to our includes ?
>
>  P.S. I understand that actually it's glibc needs fixing because the same
> will happen on any other non-Linux OS. But i believe FSF will simply say "we
> don't care" and won't accept this fix.

Why wouldn't they care?  Even if you're right about them "not caring,"
you stand to lose nothing by giving them the chance to surprise you
favorably.

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).

-gmt

--
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