Error C2040: ... differs in levels of indirection from ... MXVC++ Problem # 1

[imaloner]

I am posting two threads because I have two different problems, but both have the same background information.

Common Background Information:

I am trying to rebuild code for a working, commercially sold application with only partial build instructions. The previous maintainer of the code (a mixture of C and C++) is no longer with the company, but when he built the code he used MSVC++, and though I am not certain of the version he was using, I think it was either 4.0 or 6.0. I have only a little experience building with this environment (I am otherwise a seasoned developer) so I need help getting past a couple of issues that I have encountered. Computers (and backups of those computers) previously used for running this build are now completely unavailable.

I have set up the build on my system using MSVC++ 6.0. The source repository contained a workspace (.dsw) file that I am using for all of the projects. I do not have specific instructions for this product on how to adjust the references to libraries, includes, etc. for a particular machine, but I am using instructions for this from a similar (in terms of languages and tools used) product that was written around the same time. I have gotten 43 of 53 classes (projects) to build, but am getting primarily two errors with the remaining 10 clases (projects).

Because I know this code base was building properly (for someone else who is no longer available on a machine that is no longer available), I would strongly prefer adjustments to the build environment over code modification to get it to work, so please focus your assistance/suggestions in this area.

Thanks !

Problem #1: Error C2040: ... differs in levels of indirection from ...

Here are the exact error messages I am receiving:

Fxactn.cpp
\develop\3rdParty\xvtdsp45\w32_x86\include\xvt_type.h(54) : error C2040: 'LONG_PTR' : 'long *' differs in levels of indirection from 'long'
\develop\3rdParty\xvtdsp45\w32_x86\include\xvt_type.h(55) : error C2040: 'ULONG_PTR' : 'unsigned long *' differs in levels of indirection from 'unsigned long'
Fxapifun.cpp
C:\PROGRAM FILES\MICROSOFT SDK\INCLUDE\basetsd.h(92) : error C2040: 'LONG_PTR' : 'long' differs in levels of indirection from 'long *'
C:\PROGRAM FILES\MICROSOFT SDK\INCLUDE\basetsd.h(93) : error C2040: 'ULONG_PTR' : 'unsigned long' differs in levels of indirection from 'unsigned long *'
Guicinit.cpp
\develop\3rdParty\xvtdsp45\w32_x86\include\xvt_type.h(54) : error C2040: 'LONG_PTR' : 'long *' differs in levels of indirection from 'long'
\develop\3rdParty\xvtdsp45\w32_x86\include\xvt_type.h(55) : error C2040: 'ULONG_PTR' : 'unsigned long *' differs in levels of indirection from 'unsigned long'

The first two errors and the last two errors come from the same include file. I put the errors twice simply to emphasize that I am receiving these errors on multiple source files. The middle two errors are only occurring once.

Here are lines 41 through 58 of xvt_type.h (apparently a third party include file):

typedef unsigned short T_LNUM;
typedef unsigned short T_PNUM;
typedef unsigned long  XVT_COLOR_TYPE; /* Color Component Type (XVT_COLOR_* */

/* The following legacy "data types" are being phased out, as they cause    */
/* problems with constness: "const int *x" is NOT same as "const INT_PTR x" */
//typedef int           *INT_PTR;
typedef BOOLEAN       *BOOLEAN_PTR;
typedef char           XVT_BYTE;    /* raw data */
typedef unsigned char  XVT_UBYTE;   /* raw data */
typedef XVT_BYTE      *DATA_PTR;    /* ptr to arbitrary data - backwards compat. */
typedef XVT_UBYTE     *UDATA_PTR;   /* unsigned ptr to arbitrary data */
typedef XVT_UBYTE      DATA_BYTE;   /* for raw data */
typedef long          *LONG_PTR;          [B]/* THIS IS LINE 54 */[/B]
typedef unsigned long *ULONG_PTR;        [B]/* THIS IS LINE 55 */[/B]

/* define a point to function which will be used in xvt_win_enum_wins etc. */
typedef XVT_CALLCONV_TYPEDEF( BOOLEAN, XVT_ENUM_CHILDREN, (WINDOW child, long data));

Here are the first 98 lines of the BaseTsd.h file:

/*++

Copyright (c) Microsoft Corporation.  All rights reserved.

Module Name:

    basetsd.h

Abstract:

    Type definitions for the basic sized types.

Author:

Revision History:

--*/

#ifndef _BASETSD_H_
#define _BASETSD_H_

#if _MSC_VER > 1000
#pragma once
#endif

#ifdef __cplusplus
extern "C" {
#endif

typedef signed char         INT8, *PINT8;
typedef signed short        INT16, *PINT16;
typedef signed int          INT32, *PINT32;
typedef signed __int64      INT64, *PINT64;
typedef unsigned char       UINT8, *PUINT8;
typedef unsigned short      UINT16, *PUINT16;
typedef unsigned int        UINT32, *PUINT32;
typedef unsigned __int64    UINT64, *PUINT64;

//
// The following types are guaranteed to be signed and 32 bits wide.
//

typedef signed int LONG32, *PLONG32;

//
// The following types are guaranteed to be unsigned and 32 bits wide.
//

typedef unsigned int ULONG32, *PULONG32;
typedef unsigned int DWORD32, *PDWORD32;

#if !defined(_W64)
#if !defined(__midl) && (defined(_X86_) || defined(_M_IX86)) && _MSC_VER >= 1300
#define _W64 __w64
#else
#define _W64
#endif
#endif

//
// The INT_PTR is guaranteed to be the same size as a pointer.  Its
// size with change with pointer size (32/64).  It should be used
// anywhere that a pointer is cast to an integer type. UINT_PTR is
// the unsigned variation.
//
// __int3264 is intrinsic to 64b MIDL but not to old MIDL or to C compiler.
//
#if ( 501 < __midl )

    typedef [public] __int3264 INT_PTR, *PINT_PTR;
    typedef [public] unsigned __int3264 UINT_PTR, *PUINT_PTR;

    typedef [public] __int3264 LONG_PTR, *PLONG_PTR;
    typedef [public] unsigned __int3264 ULONG_PTR, *PULONG_PTR;

#else  // midl64
// old midl and C++ compiler

#if defined(_WIN64)
    typedef __int64 INT_PTR, *PINT_PTR;
    typedef unsigned __int64 UINT_PTR, *PUINT_PTR;

    typedef __int64 LONG_PTR, *PLONG_PTR;
    typedef unsigned __int64 ULONG_PTR, *PULONG_PTR;

    #define __int3264   __int64

#else
    typedef _W64 int INT_PTR, *PINT_PTR;
    typedef _W64 unsigned int UINT_PTR, *PUINT_PTR;

    typedef _W64 long LONG_PTR, *PLONG_PTR;
    typedef _W64 unsigned long ULONG_PTR, *PULONG_PTR;

    #define __int3264   __int32

#endif
#endif // midl64

My thoughts so far are as follows:

1. One possibility is that the previous builder of this code precompiled these (and probably all 3rd party and MS) headers separately using a different environment or different settings prior to the build, and he had the pre-compiled headers available when he ran the main build, so he would not have gotten these errors.
2. Another possibility is that the previous builder was using different settings for the compile than I am using -- perhaps a older version compatability flag or something like that. However, if this was on the main build (as opposed to a separate run to precompile header files) I would expect that setting to be in the saved workspace (.dsw) file.
3. The only other possibility that I have been able to come up with is that the previous builder was using or pointing to a later version of these header files than I am. I will look into this possibility, but I wanted to go ahead and post to get the ball rolling first, in case someone else had other helpful ideas.

Any thoughts or suggestions from an experienced MSVC++ user would be greatly appreciated.

[StuXYZ]

At a guess. I think that your problem is that you are using long, by itself, and not long int or long unsigned int , or long double etc.

Yes there is a fall back of long to long int, but does that still apply to long* and going to long int* ??

However, I don't have a windows system to test it but gcc casts long* to long int*. [linux].

[NathanOliver]

i noticed in your code that you posted that in basetsd.h int the #if statement #if ( 501 < __midl ) there are typedef's for a LONG_PTR and a ULONG_PTR which might be giving you the error since you are typedefing them again in your xvt_type.h file

[JasonHippy]

Hey there, I just replied to your other thread:
http://www.daniweb.com/forums/thread195614.html

Try altering your include order as mentioned in my reply to the post in the above URL and see if that does the trick. It may solve this problem as well as the other problems you were having!

Cheers for now,
Jas.

[imaloner]

First of all, I want to clarify one item. I did not include all error messages in the original post. When I try to build some projects I only get the error involving xvt_type.h. There is only one project that gives me both the xvt_type.h error and the basetsd.h error, but even in that case it is trying to compile different source files. Thus, I don't think suggestions that the errors are caused by conflicts between xvt_type.h and basetsd.h hold water.

Secondly, in response to suggestions that I have received regarding changing the order of include and library directory searches... I have tried several different orders with no noticeable impact. The order I have right now is Microsoft SDK first, third party includes and libraries second, and VC98 includes and libraries last. This seems the safest, but again no order seems to work (trying every single permutation would take quite a while.)

Thirdly, in regards to the suggestion that I received that I might need older MS header files (and another that suggested that the basetsd.h that I quoted in my post looked like it might be from VC++ 2008 instead of from MSVC++ 6.0), let me say that the basetsd.h file I put in the post was definitely from the Microsoft SDK directory and that the files on my machine in that directory are all dated March 2003 and earlier. I am pretty sure I am using the right age SDK (but I may not be using the SDK for/from the right system... see next paragraph.)

Lastly, and most importantly, it has come to my attention that the product that I am building is sold only for Server 2000 and Server 2003 and that the previous building of this code base was running on a Server 2003 system. Since I have been trying my builds on an XP machine, I am leaning towards setting up a virtual machine running Server 2003 in which to compile to see if this helps. However, since that will take a while to set up, I was hoping someone out there might have thoughts about whether or not this is likely to help.