* Re: On NCR 4.3.03 conflict at compile time using gcc 2.95.3
@ 2001-04-05 3:55 Brother Tuck
2001-04-05 8:05 ` Robert Lipe
0 siblings, 1 reply; 8+ messages in thread
From: Brother Tuck @ 2001-04-05 3:55 UTC (permalink / raw)
To: tanes73, jbuck, gcc, gcc-help
Thanks Tanes for your patch and others comunity members for your help.
I'm able to compile and link my project using your patch.
It would be interresting if this patch can be include in the next gcc
packaging like linux and Sco patch.
Regards,
Emmanuel Soden
>
>Sorry. I forgot to tell you to apply patch for this. Apparently there
>are declarations (and provided functions) of htons, htonl, ... already
>in STREAMWare TCP. That's why you got an error. Here is patch I apply on
>gcc 2.95.2 and gcc 2.95.3 on file
>/usr/local/lib/gcc-lib/i586-ncr-sysv4.3.03/2.95.3/include/sys/byteorder.h.
>
>
>Regards,
>Tanes Sriviroolchai
>NCR (Thailand) Ltd.
>
>*** byteorder.h Thu Mar 29 18:16:58 2001
>--- ../../../2.95.2/include/sys/byteorder.h Mon Nov 8 10:14:24 1999
>***************
>*** 26,35 ****
>--- 26,37 ----
> #endif
>
> #ifdef __STDC__
>+ #if 0
> static __inline__ unsigned long htonl (unsigned long);
> static __inline__ unsigned short htons (unsigned int);
> static __inline__ unsigned long ntohl (unsigned long);
> static __inline__ unsigned short ntohs (unsigned int);
>+ #endif
> #endif /* defined (__STDC__) */
>
> #if defined (__i386__)
>***************
>*** 38,43 ****
>--- 40,46 ----
> #define __BYTE_ORDER__ __LITTLE_ENDIAN__
> #endif
>
>+ #if 0
> /* Convert a host long to a network long. */
>
> /* We must use a new-style function definition, so that this will also
>***************
>*** 64,69 ****
>--- 67,74 ----
> return __result;
> }
>
>+ #endif
>+
> #elif ((defined (__i860__) && !defined (__i860_big_endian__)) \
> || defined (__ns32k__) || defined (__vax__) \
> || defined (__spur__) || defined (__arm__))
>***************
>*** 125,130 ****
>--- 130,136 ----
>
> #endif /* big-endian */
>
>+ #if 0
> /* Convert a network long to a host long. */
>
> static __inline__ unsigned long
>***************
>*** 140,144 ****
>--- 146,152 ----
> {
> return htons (__arg);
> }
>+
>+ #endif
>
> #endif /* !defined (_SYS_BYTEORDER_H) */
>
>
>
>
>__________________________________________________
>Do You Yahoo!?
>Get email at your own domain with Yahoo! Mail.
> http://personal.mail.yahoo.com/
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com .
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: On NCR 4.3.03 conflict at compile time using gcc 2.95.3
2001-04-05 3:55 On NCR 4.3.03 conflict at compile time using gcc 2.95.3 Brother Tuck
@ 2001-04-05 8:05 ` Robert Lipe
0 siblings, 0 replies; 8+ messages in thread
From: Robert Lipe @ 2001-04-05 8:05 UTC (permalink / raw)
To: Brother Tuck; +Cc: tanes73, gcc, gcc-help
Brother Tuck wrote:
> Thanks Tanes for your patch and others comunity members for your help.
> I'm able to compile and link my project using your patch.
> It would be interresting if this patch can be include in the next gcc
> packaging like linux and Sco patch.
Certainly not this patch, since it will break other targets. You can't
just remove definitions and declarations becuase they happen to not
match YOUR target.
The correct way to fix this (which could get accepted into the tree)
is to add a test in fixincludes like I originally suggested.
RJL
>
> Regards,
> Emmanuel Soden
>
> >
> >Sorry. I forgot to tell you to apply patch for this. Apparently there
> >are declarations (and provided functions) of htons, htonl, ... already
> >in STREAMWare TCP. That's why you got an error. Here is patch I apply on
> >gcc 2.95.2 and gcc 2.95.3 on file
> >/usr/local/lib/gcc-lib/i586-ncr-sysv4.3.03/2.95.3/include/sys/byteorder.h.
> >
> >
> >Regards,
> >Tanes Sriviroolchai
> >NCR (Thailand) Ltd.
> >
> >*** byteorder.h Thu Mar 29 18:16:58 2001
> >--- ../../../2.95.2/include/sys/byteorder.h Mon Nov 8 10:14:24 1999
> >***************
> >*** 26,35 ****
> >--- 26,37 ----
> > #endif
> >
> > #ifdef __STDC__
> >+ #if 0
> > static __inline__ unsigned long htonl (unsigned long);
> > static __inline__ unsigned short htons (unsigned int);
> > static __inline__ unsigned long ntohl (unsigned long);
> > static __inline__ unsigned short ntohs (unsigned int);
> >+ #endif
> > #endif /* defined (__STDC__) */
> >
> > #if defined (__i386__)
> >***************
> >*** 38,43 ****
> >--- 40,46 ----
> > #define __BYTE_ORDER__ __LITTLE_ENDIAN__
> > #endif
> >
> >+ #if 0
> > /* Convert a host long to a network long. */
> >
> > /* We must use a new-style function definition, so that this will also
> >***************
> >*** 64,69 ****
> >--- 67,74 ----
> > return __result;
> > }
> >
> >+ #endif
> >+
> > #elif ((defined (__i860__) && !defined (__i860_big_endian__)) \
> > || defined (__ns32k__) || defined (__vax__) \
> > || defined (__spur__) || defined (__arm__))
> >***************
> >*** 125,130 ****
> >--- 130,136 ----
> >
> > #endif /* big-endian */
> >
> >+ #if 0
> > /* Convert a network long to a host long. */
> >
> > static __inline__ unsigned long
> >***************
> >*** 140,144 ****
> >--- 146,152 ----
> > {
> > return htons (__arg);
> > }
> >+
> >+ #endif
> >
> > #endif /* !defined (_SYS_BYTEORDER_H) */
> >
> >
> >
> >
> >__________________________________________________
> >Do You Yahoo!?
> >Get email at your own domain with Yahoo! Mail.
> > http://personal.mail.yahoo.com/
>
> _________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com .
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: On NCR 4.3.03 conflict at compile time using gcc 2.95.3
@ 2001-04-05 8:14 Brother Tuck
0 siblings, 0 replies; 8+ messages in thread
From: Brother Tuck @ 2001-04-05 8:14 UTC (permalink / raw)
To: robertlipe; +Cc: tanes73, gcc, gcc-help
I agree with you about this point.
Regards,
Emmanuel Soden
>Brother Tuck wrote:
> > Thanks Tanes for your patch and others comunity members for your help.
> > I'm able to compile and link my project using your patch.
> > It would be interresting if this patch can be include in the next gcc
> > packaging like linux and Sco patch.
>
>Certainly not this patch, since it will break other targets. You can't
>just remove definitions and declarations becuase they happen to not
>match YOUR target.
>
>The correct way to fix this (which could get accepted into the tree)
>is to add a test in fixincludes like I originally suggested.
>
>RJL
>
>
> >
> > Regards,
> > Emmanuel Soden
> >
> > >
> > >Sorry. I forgot to tell you to apply patch for this. Apparently there
> > >are declarations (and provided functions) of htons, htonl, ... already
> > >in STREAMWare TCP. That's why you got an error. Here is patch I apply
>on
> > >gcc 2.95.2 and gcc 2.95.3 on file
> >
> >/usr/local/lib/gcc-lib/i586-ncr-sysv4.3.03/2.95.3/include/sys/byteorder.h.
> > >
> > >
> > >Regards,
> > >Tanes Sriviroolchai
> > >NCR (Thailand) Ltd.
> > >
> > >*** byteorder.h Thu Mar 29 18:16:58 2001
> > >--- ../../../2.95.2/include/sys/byteorder.h Mon Nov 8 10:14:24
>1999
> > >***************
> > >*** 26,35 ****
> > >--- 26,37 ----
> > > #endif
> > >
> > > #ifdef __STDC__
> > >+ #if 0
> > > static __inline__ unsigned long htonl (unsigned long);
> > > static __inline__ unsigned short htons (unsigned int);
> > > static __inline__ unsigned long ntohl (unsigned long);
> > > static __inline__ unsigned short ntohs (unsigned int);
> > >+ #endif
> > > #endif /* defined (__STDC__) */
> > >
> > > #if defined (__i386__)
> > >***************
> > >*** 38,43 ****
> > >--- 40,46 ----
> > > #define __BYTE_ORDER__ __LITTLE_ENDIAN__
> > > #endif
> > >
> > >+ #if 0
> > > /* Convert a host long to a network long. */
> > >
> > > /* We must use a new-style function definition, so that this will
>also
> > >***************
> > >*** 64,69 ****
> > >--- 67,74 ----
> > > return __result;
> > > }
> > >
> > >+ #endif
> > >+
> > > #elif ((defined (__i860__) && !defined (__i860_big_endian__)) \
> > > || defined (__ns32k__) || defined (__vax__) \
> > > || defined (__spur__) || defined (__arm__))
> > >***************
> > >*** 125,130 ****
> > >--- 130,136 ----
> > >
> > > #endif /* big-endian */
> > >
> > >+ #if 0
> > > /* Convert a network long to a host long. */
> > >
> > > static __inline__ unsigned long
> > >***************
> > >*** 140,144 ****
> > >--- 146,152 ----
> > > {
> > > return htons (__arg);
> > > }
> > >+
> > >+ #endif
> > >
> > > #endif /* !defined (_SYS_BYTEORDER_H) */
> > >
> > >
> > >
> > >
> > >__________________________________________________
> > >Do You Yahoo!?
> > >Get email at your own domain with Yahoo! Mail.
> > > http://personal.mail.yahoo.com/
> >
> >
>_________________________________________________________________________
> > Get Your Private, Free E-mail from MSN Hotmail at
> http://www.hotmail.com .
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com .
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: On NCR 4.3.03 conflict at compile time using gcc 2.95.3
2001-04-05 1:30 Brother Tuck
@ 2001-04-05 2:03 ` Tanes Sriviroolchai
0 siblings, 0 replies; 8+ messages in thread
From: Tanes Sriviroolchai @ 2001-04-05 2:03 UTC (permalink / raw)
To: Brother Tuck, robertlipe; +Cc: tanes73, gcc, gcc-help
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/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: On NCR 4.3.03 conflict at compile time using gcc 2.95.3
2001-04-04 9:11 Brother Tuck
2001-04-04 11:26 ` Robert Lipe
@ 2001-04-05 1:58 ` Tanes Sriviroolchai
1 sibling, 0 replies; 8+ messages in thread
From: Tanes Sriviroolchai @ 2001-04-05 1:58 UTC (permalink / raw)
To: Brother Tuck, jbuck, gcc, gcc-help
Sorry. I forgot to tell you to apply patch for this. Apparently there
are declarations (and provided functions) of htons, htonl, ... already
in STREAMWare TCP. That's why you got an error. Here is patch I apply on
gcc 2.95.2 and gcc 2.95.3 on file
/usr/local/lib/gcc-lib/i586-ncr-sysv4.3.03/2.95.3/include/sys/byteorder.h.
Regards,
Tanes Sriviroolchai
NCR (Thailand) Ltd.
*** byteorder.h Thu Mar 29 18:16:58 2001
--- ../../../2.95.2/include/sys/byteorder.h Mon Nov 8 10:14:24 1999
***************
*** 26,35 ****
--- 26,37 ----
#endif
#ifdef __STDC__
+ #if 0
static __inline__ unsigned long htonl (unsigned long);
static __inline__ unsigned short htons (unsigned int);
static __inline__ unsigned long ntohl (unsigned long);
static __inline__ unsigned short ntohs (unsigned int);
+ #endif
#endif /* defined (__STDC__) */
#if defined (__i386__)
***************
*** 38,43 ****
--- 40,46 ----
#define __BYTE_ORDER__ __LITTLE_ENDIAN__
#endif
+ #if 0
/* Convert a host long to a network long. */
/* We must use a new-style function definition, so that this will also
***************
*** 64,69 ****
--- 67,74 ----
return __result;
}
+ #endif
+
#elif ((defined (__i860__) && !defined (__i860_big_endian__)) \
|| defined (__ns32k__) || defined (__vax__) \
|| defined (__spur__) || defined (__arm__))
***************
*** 125,130 ****
--- 130,136 ----
#endif /* big-endian */
+ #if 0
/* Convert a network long to a host long. */
static __inline__ unsigned long
***************
*** 140,144 ****
--- 146,152 ----
{
return htons (__arg);
}
+
+ #endif
#endif /* !defined (_SYS_BYTEORDER_H) */
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: On NCR 4.3.03 conflict at compile time using gcc 2.95.3
@ 2001-04-05 1:30 Brother Tuck
2001-04-05 2:03 ` Tanes Sriviroolchai
0 siblings, 1 reply; 8+ messages in thread
From: Brother Tuck @ 2001-04-05 1:30 UTC (permalink / raw)
To: robertlipe; +Cc: tanes73, gcc, gcc-help
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 .
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: On NCR 4.3.03 conflict at compile time using gcc 2.95.3
2001-04-04 9:11 Brother Tuck
@ 2001-04-04 11:26 ` Robert Lipe
2001-04-05 1:58 ` Tanes Sriviroolchai
1 sibling, 0 replies; 8+ messages in thread
From: Robert Lipe @ 2001-04-04 11:26 UTC (permalink / raw)
To: Brother Tuck; +Cc: tanes73, gcc, gcc-help
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* On NCR 4.3.03 conflict at compile time using gcc 2.95.3
@ 2001-04-04 9:11 Brother Tuck
2001-04-04 11:26 ` Robert Lipe
2001-04-05 1:58 ` Tanes Sriviroolchai
0 siblings, 2 replies; 8+ messages in thread
From: Brother Tuck @ 2001-04-04 9:11 UTC (permalink / raw)
To: brothertuck72, tanes73, jbuck, gcc, gcc-help
Hi,
I have built successfully the gcc 2.95.3 on NCR 4.3.03.
But when I try to compile a part of my project using this fresh
installation.
I got an error at compile time for severals function, for me:
- htons(..)
- ntohs(..)
At the beginning I believed that the problem coming from the binutils
package so I have recompile the gcc usin native as, linker...
And I got the same error.
-------------------------- m_test.cpp
#include <netinet/in.h>
#ifndef __M_TEST_NO_ARPA
#include <arpa/inet.h>
#endif
#define DEST_IP "127.0.0.1"
#define DEST_PORT 23
void main(void) {
struct sockaddr_in dest_addr;
dest_addr.sin_port = htons(DEST_PORT);
dest_addr.sin_addr.s_addr = inet_addr(DEST_IP);
}
--------------------------- end of m_test.cpp
When I try to compile including the header inet.h for the system
=================================================
bash-2.02$ c++ -o m_test m_test.cpp
In file included from m_test.cpp:2:
/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
If I compile without the header inet.h
============================
bash-2.02$ c++ -D__M_TEST_NO_ARPA -o m_test m_test.cpp
m_test.cpp: In function `int main(...)':
m_test.cpp:14: implicit declaration of function `int inet_addr(...)'
I have also try to give the path to the system include (It's not a good
idea...)
=======================================================
bash-2.02$ gcc -o m_test m_test.c -I/usr/include
In file included from /usr/include/sys/endian.h:37,
from /usr/include/netinet/in.h:58,
from m_test.c:1:
/usr/include/sys/byteorder.h:87: parse error before `unsigned'
m_test.c: In function `main':
m_test.c:10: warning: return type of `main' is not `int'
bash-2.02$ gcc -o m_test m_test.c -I/usr/include
bash-2.02$ mv m_test.c m_test.cpp
bash-2.02$ gcc -o m_test m_test.cpp -I/usr/include
In file included from /usr/include/sys/endian.h:37,
from /usr/include/netinet/in.h:58,
from m_test.cpp:1:
/usr/include/sys/byteorder.h:87: parse error before `unsigned'
/usr/include/sys/byteorder.h:90: syntax error before `,'
/usr/include/sys/byteorder.h:110: syntax error before `,'
/usr/include/sys/byteorder.h:135: syntax error before `,'
/usr/include/sys/byteorder.h:139: syntax error before `,'
/usr/include/sys/byteorder.h:143: syntax error before `%'
/usr/include/sys/byteorder.h:167: syntax error before `,'
/usr/include/sys/byteorder.h:171: syntax error before `,'
/usr/include/sys/byteorder.h:175: syntax error before `%'
If someone can help me...
Regards,
Emmanuel Soden
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com .
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2001-04-05 8:14 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-04-05 3:55 On NCR 4.3.03 conflict at compile time using gcc 2.95.3 Brother Tuck
2001-04-05 8:05 ` Robert Lipe
-- strict thread matches above, loose matches on Subject: below --
2001-04-05 8:14 Brother Tuck
2001-04-05 1:30 Brother Tuck
2001-04-05 2:03 ` Tanes Sriviroolchai
2001-04-04 9:11 Brother Tuck
2001-04-04 11:26 ` Robert Lipe
2001-04-05 1:58 ` Tanes Sriviroolchai
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).