This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: On NCR 4.3.03 conflict at compile time using gcc 2.95.3
- To: Brother Tuck <brothertuck72 at hotmail dot com>
- Subject: Re: On NCR 4.3.03 conflict at compile time using gcc 2.95.3
- From: Robert Lipe <robertlipe at usa dot net>
- Date: Wed, 4 Apr 2001 13:26:10 -0500
- Cc: tanes73 at yahoo dot com, gcc at gcc dot gnu dot org, gcc-help at gcc dot gnu dot org
- References: <F105hpJm8OtprR0E6fa0000042f@hotmail.com>
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.