Re: On NCR 4.3.03 conflict at compile time using gcc 2.95.3

["Brother Tuck" <brothertuck72 at hotmail dot com>]

Thanks to all for your help. But I have found another way to resolv it. But 
I'm not sure
about the side effect.
I have edit in the endian.h provide by gcc.  I have found the following 
macros definition, at line 35 in my endian.h file.

#if BYTE_ORDER == LITTLE_ENDIAN

#include <sys/byteorder.h>

#else   /* BYTE_ORDER */

#define ntohl(x)        (x)
#define htonl(x)        (x)
#define ntohs(x)        (x)
#define htons(x)        (x)

#endif  /* BYTE_ORDER */

To correct my problem, I have just add a define before  the include of the 
file <sys>/byteorder.h. I put a define because, I'm not sure about the side 
effect.
#if BYTE_ORDER == LITTLE_ENDIAN

#ifndef __REMOVE_INCLUDE_OF_BYTEORDER_H
#include <sys/byteorder.h>
#endif

#else   /* BYTE_ORDER */

#define ntohl(x)        (x)
#define htonl(x)        (x)
#define ntohs(x)        (x)
#define htons(x)        (x)

#endif  /* BYTE_ORDER */


When I compile my source using the flag -D__REMOVE_INCLUDE_OF_BYTEORDER_H
I have no problem....
Is it a good way to ??

Regards,
Emmanuel Soden

>
>Brother Tuck wrote:
>
> > I have built successfully the gcc 2.95.3 on NCR 4.3.03.
>
>I've never tried that precise combination, but having some experience
>with SVR4-like substances on IA32, this sounds familiar.
>
> > /usr/include/arpa/inet.h:67: declaration of C function `in_port_t
> > htons(short unsigned int)' conflicts with
> > 
>/usr/local/gcc/2.95.3/lib/gcc-lib/i586-ncr-sysv4.3.03/2.95.3/include/sys/byteorder.h:60:
> > previous declaration `short unsigned int htons(unsigned int)' here
> > /usr/include/arpa/inet.h:69: declaration of C function `in_port_t
> > ntohs(short unsigned int)' conflicts with
> > 
>/usr/local/gcc/2.95.3/lib/gcc-lib/i586-ncr-sysv4.3.03/2.95.3/include/sys/byteorder.h:140:
> > previous declaration `short unsigned int ntohs(unsigned int)' here
>
>
>I'm guessing that <sys/byteorder.h> is using vendor asms to implement
>those functions and not properly bracketing them with a test that the
>vendor compiler is in use.  I fixed this back in '99 or so for SVR5,
>but the code in inclhack.def might be too conservative to match on your
>hostname.  I don't recall if that code was in 2.95 or now.  Search for
>"endian.h" in inclhack.def if you have to backport that to 2.95.
>
>It has also been fixed in later SVR5 builds by adding a test that the
>vendor compiler is used around the __asm calls.
>
>

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.