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

[Tanes Sriviroolchai <tanes73@yahoo.com>]

Emmanuel,
   I don't think this is a good way to exclude all stuffs in byteorder.h
since there are some defines you might need (e.g. LITTLE_ENDIAN, etc.).
Only declarations and inline codes need to be removed.

Regards,
Tanes Sriviroolchai

--- Brother Tuck <brothertuck72@hotmail.com> wrote:
> 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 .
> 


__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/