| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2072.1 | reproducible under DEC C V5.3-006 on OpenVMS VAX V6.2 - not a compiler error | WIDTH::MDAVIS | Mark Davis - compiler maniac | Tue Jan 28 1997 10:06 | 62 |
| ucx$rpcxdr.h does:
#ifndef __IN_H
#include <in.h> /* needed by svc.h */
#endif /* __IN_H */
in.h has:
#ifndef __SOCKET_TYPEDEFS
typedef char * caddr_t;
typedef unsigned short u_short;
typedef unsigned long u_long;
typedef unsigned char u_char;
#define __SOCKET_TYPEDEFS
#endif
then, later in ucx$rpcxdr.h there is another typedef of caddr_t:
#ifndef __RPC_TYPES_H__
#define __RPC_TYPES_H__
#ifndef KERNEL
#ifndef major /* ouch! */
/*#include <sys/types.h>*/
/*
** <sys/types.h>
*/
#ifndef __SOCKET_TYPEDEFS
typedef unsigned char *caddr_t;
typedef unsigned long u_long;
typedef unsigned short u_short;
#endif /* __SOCKET_TYPEDEFS */
One def is char*, the other is UNSIGNED char*.
> The workaroud is to include also SOCKET.H
Here's the code in socket.h
#ifndef __SOCKET_TYPEDEFS
typedef char * caddr_t;
typedef unsigned short u_short;
typedef unsigned long u_long;
typedef unsigned char u_char;
#define __SOCKET_TYPEDEFS
#endif
I don't have any documentation to look at, but presumably you're supposed
to include socket.h before including ucx$rpcxdr.h....
Mark Davis
c/c++ team
|
| 2072.2 | | VIRGIN::PFISTERR | Carpe Diem, Memento Mori | Fri Jan 31 1997 01:59 | 8 |
| Thank You for the answer!
The customer is not so happy with this workaround. He asked me, how can
DIGITAL deliver a new compiler which has new header files which
requires, that he has to change 90% of his code. When will DIGITAL
deliver a solution which don't need the additional 3. header file?
Rene
|
| 2072.3 | wrong group to ask | HNDYMN::MCCARTHY | A Quinn Martin Production | Fri Jan 31 1997 05:58 | 11 |
| >> DIGITAL deliver a new compiler which has new header files which
That header file is not part of the compiler product.
>> requires, that he has to change 90% of his code. When will DIGITAL
>> deliver a solution which don't need the additional 3. header file?
Since the UCX header file is owned by the UCX (old name) product, ask that
question. There conference is lassie::ucx.
bjm
|
| 2072.4 | | CSC64::BLAYLOCK | If at first you doubt,doubt again. | Fri Jan 31 1997 10:31 | 7 |
|
In the mean time, you could just have your customer
modify UCX$RPCXDR.H to include socket.h until UCX engineering
delivers a modify version of their own.
Then only one module is changed for the customer.
|
| 2072.5 | UCX V3.3 no longer supported | CUJO::SAMPSON | | Sat Feb 01 1997 00:46 | 1 |
| Also, the customer might want to try upgrading to UCX V4.1 ECO 4.
|
| 2072.6 | | VIRGIN::PFISTERR | Carpe Diem, Memento Mori | Mon Feb 10 1997 02:50 | 11 |
| The customer answered me:
The only problem is, that a program which is developed
under V4.1 is not able to link or run under UCX 3.x.
All our production systems have UCX 3.x installed.
I hope this shows you a little bit our problem with
this software.
->What can he do?
|
| 2072.7 | see .4 for simple possible solution | HNDYMN::MCCARTHY | A Quinn Martin Production | Mon Feb 10 1997 05:59 | 8 |
| >> ->What can he do?
Continue the line of questioning in the UCX conference. I would think
for 3.n systems, fixing a header file would be the right thing to do and
those fixes should come from the UCX group - or at least directed from the UCX
engineering team and not from the C++ team.
bjm
|