I'm compiling some C & C++ source files with DMC++.

The C compilation is breaking on a typedef in some internal Synesis header file, which basically typedefs bool from unsigned int, in the case where native bool support is not detected:

    h:\dev\include\SLBase.h(3131) : Error: 'bool' previously declared as something else
    It was declared as: int
    It is now declared: unsigned

The same problem can be seen with the simple file

    #include <stddef.h>
    typedef unsigned bool;
    int main()
    {
        return 0;
    }

The reason this is happening is that STLport typedefs int to bool in stl/_config.h:

    #if defined(_STLP_NO_BOOL)
    # if (defined (__IBMCPP__) && (__IBMCPP__ < 400)) && ! defined (_AIX)
    #  include <isynonym.hpp>
    #  if defined (__OS400__)
        typedef int bool;
    #  elif !( defined (__xlC__) || defined (_AIX))
        typedef Boolean bool;
    #  endif
    # else
    #  if defined(_STLP_YVALS_H)
    #   include <yvals.h>
    #  else
    #    if defined (_STLP_DONT_USE_BOOL_TYPEDEF)
    #     define bool int
    #    else
          typedef int bool;
    #    endif
    #    define true 1
    #    define false 0
    #  endif
    # endif /* __IBMCPP__ */
    #else
    #    define _STLP_BOOL_KEYWORD 1
    #endif /* _STLP_NO_BOOL */

as a result of the following in stl_dm.h:

    #  ifndef _BOOL_DEFINED
    #   define _STLP_NO_BOOL
    #  else
    #   define _STLP_DONT_USE_BOOL_TYPEDEF
    #  endif

The reason this is being picked up is that STLport has a stddef.h.

The reason that is being picked up is that STLport has to be before the main DMC++ include directory otherwise the (non-functioning) SGI std lib is picked up.

Anyone got any ideas for a solution that does not involve a hack in my source (which otherwise works perfectly with all other Win32 and Linux compilers)?

The only thing I can think of is that it'd be nice to have different sections in SC.INI for C and C++ compilation, e.g.


    [Environment]
    PATH=%PATH%;"%@P%\..\bin"
    BIN="%@P%\..\bin"
    LIB=%LIB%;"%@P%\..\lib";"%@P%\..\mfc\lib"
    HELP="%@P%\..\help"

    [Environment:C]
    INCLUDE="%@P%\..\include";"%@P%\..\mfc\include";%INCLUDE%;


    [Environment:C++]
    INCLUDE=%INCLUDE%;"%@P%\..\include";%@P%\..\mfc\include;


Cheers

Matthew

I'm also running into the same problem with RC. I have no idea how to hack this into shape. :-(


"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:d2le95$2gdu$1@digitaldaemon.com...
> I'm compiling some C & C++ source files with DMC++.
>
> The C compilation is breaking on a typedef in some internal Synesis header file, which basically typedefs bool from unsigned int, in the case where native bool support is not detected:
>
>    h:\dev\include\SLBase.h(3131) : Error: 'bool' previously declared as something else
>    It was declared as: int
>    It is now declared: unsigned
>
> The same problem can be seen with the simple file
>
>    #include <stddef.h>
>    typedef unsigned bool;
>    int main()
>    {
>        return 0;
>    }
>
> The reason this is happening is that STLport typedefs int to bool in stl/_config.h:
>
>    #if defined(_STLP_NO_BOOL)
>    # if (defined (__IBMCPP__) && (__IBMCPP__ < 400)) && ! defined (_AIX)
>    #  include <isynonym.hpp>
>    #  if defined (__OS400__)
>        typedef int bool;
>    #  elif !( defined (__xlC__) || defined (_AIX))
>        typedef Boolean bool;
>    #  endif
>    # else
>    #  if defined(_STLP_YVALS_H)
>    #   include <yvals.h>
>    #  else
>    #    if defined (_STLP_DONT_USE_BOOL_TYPEDEF)
>    #     define bool int
>    #    else
>          typedef int bool;
>    #    endif
>    #    define true 1
>    #    define false 0
>    #  endif
>    # endif /* __IBMCPP__ */
>    #else
>    #    define _STLP_BOOL_KEYWORD 1
>    #endif /* _STLP_NO_BOOL */
>
> as a result of the following in stl_dm.h:
>
>    #  ifndef _BOOL_DEFINED
>    #   define _STLP_NO_BOOL
>    #  else
>    #   define _STLP_DONT_USE_BOOL_TYPEDEF
>    #  endif
>
> The reason this is being picked up is that STLport has a stddef.h.
>
> The reason that is being picked up is that STLport has to be before the main DMC++ include directory otherwise the (non-functioning) SGI std lib is picked up.
>
> Anyone got any ideas for a solution that does not involve a hack in my source (which otherwise works perfectly with all other Win32 and Linux compilers)?
>
> The only thing I can think of is that it'd be nice to have different sections in SC.INI for C and C++ compilation, e.g.
>
>
>    [Environment]
>    PATH=%PATH%;"%@P%\..\bin"
>    BIN="%@P%\..\bin"
>    LIB=%LIB%;"%@P%\..\lib";"%@P%\..\mfc\lib"
>    HELP="%@P%\..\help"
>
>    [Environment:C]
>    INCLUDE="%@P%\..\include";"%@P%\..\mfc\include";%INCLUDE%;
>
>
>    [Environment:C++]
>    INCLUDE=%INCLUDE%;"%@P%\..\include";%@P%\..\mfc\include;
>
>
> Cheers
>
> Matthew
>
>
> 

I'm using my own boolean type with all capital letters in some projects, 'BOOL' instead 'bool' like this,

#ifdef __cplusplus
typedef bool BOOL
#define TRUE true
#define FALSE false

#else // not C++, don't have boolean type

typedef int BOOL
#define TRUE 1
#define FALSE 0
#endif

In article <d2lq2h$2upi$1@digitaldaemon.com>, Matthew says...
>
>I'm also running into the same problem with RC. I have no idea how to hack this into shape. :-(
>
>
>"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:d2le95$2gdu$1@digitaldaemon.com...
>> I'm compiling some C & C++ source files with DMC++.
>>
>> The C compilation is breaking on a typedef in some internal Synesis header file, which basically typedefs bool from unsigned int, in the case where native bool support is not detected:
>>
>>    h:\dev\include\SLBase.h(3131) : Error: 'bool' previously declared as something else
>>    It was declared as: int
>>    It is now declared: unsigned
>>
>> The same problem can be seen with the simple file
>>
>>    #include <stddef.h>
>>    typedef unsigned bool;
>>    int main()
>>    {
>>        return 0;
>>    }
>>
>> The reason this is happening is that STLport typedefs int to bool in stl/_config.h:
>>
>>    #if defined(_STLP_NO_BOOL)
>>    # if (defined (__IBMCPP__) && (__IBMCPP__ < 400)) && ! defined (_AIX)
>>    #  include <isynonym.hpp>
>>    #  if defined (__OS400__)
>>        typedef int bool;
>>    #  elif !( defined (__xlC__) || defined (_AIX))
>>        typedef Boolean bool;
>>    #  endif
>>    # else
>>    #  if defined(_STLP_YVALS_H)
>>    #   include <yvals.h>
>>    #  else
>>    #    if defined (_STLP_DONT_USE_BOOL_TYPEDEF)
>>    #     define bool int
>>    #    else
>>          typedef int bool;
>>    #    endif
>>    #    define true 1
>>    #    define false 0
>>    #  endif
>>    # endif /* __IBMCPP__ */
>>    #else
>>    #    define _STLP_BOOL_KEYWORD 1
>>    #endif /* _STLP_NO_BOOL */
>>
>> as a result of the following in stl_dm.h:
>>
>>    #  ifndef _BOOL_DEFINED
>>    #   define _STLP_NO_BOOL
>>    #  else
>>    #   define _STLP_DONT_USE_BOOL_TYPEDEF
>>    #  endif
>>
>> The reason this is being picked up is that STLport has a stddef.h.
>>
>> The reason that is being picked up is that STLport has to be before the main DMC++ include directory otherwise the (non-functioning) SGI std lib is picked up.
>>
>> Anyone got any ideas for a solution that does not involve a hack in my source (which otherwise works perfectly with all other Win32 and Linux compilers)?
>>
>> The only thing I can think of is that it'd be nice to have different sections in SC.INI for C and C++ compilation, e.g.
>>
>>
>>    [Environment]
>>    PATH=%PATH%;"%@P%\..\bin"
>>    BIN="%@P%\..\bin"
>>    LIB=%LIB%;"%@P%\..\lib";"%@P%\..\mfc\lib"
>>    HELP="%@P%\..\help"
>>
>>    [Environment:C]
>>    INCLUDE="%@P%\..\include";"%@P%\..\mfc\include";%INCLUDE%;
>>
>>
>>    [Environment:C++]
>>    INCLUDE=%INCLUDE%;"%@P%\..\include";%@P%\..\mfc\include;
>>
>>
>> Cheers
>>
>> Matthew
>>
>>
>> 
>
>

I think you just need to define _BOOL_DEFINED when __cplusplus is defined in DMC++ config files of STLport.

Btw, I think the problem is in your SLBase.h, it tries to redefine 'bool', the same problem will occur too when you compiling it in C++ mode.

In article <d2le95$2gdu$1@digitaldaemon.com>, Matthew says...
>
>I'm compiling some C & C++ source files with DMC++.
>
>The C compilation is breaking on a typedef in some internal Synesis header file, which basically typedefs bool from unsigned int, in the case where native bool support is not detected:
>
>    h:\dev\include\SLBase.h(3131) : Error: 'bool' previously declared as something else
>    It was declared as: int
>    It is now declared: unsigned

Jack

As you may note below, I'm talking only about C compilation. ;)

The problem may be seen as the fact that the STLport directory has to come before the 'std' DMC++ include, in order to prevent selection of the SGI STL, coupled with the fact that DMC++ uses a single INCLUDE variable in SC.INI for both C and C++. STLport has its own stddef.h etc, and so we pick up the definition of bool.

"Jack" <Jack_member@pathlink.com> wrote in message news:d2miqf$jn4$1@digitaldaemon.com...
>I think you just need to define _BOOL_DEFINED when __cplusplus is defined in
> DMC++ config files of STLport.
>
> Btw, I think the problem is in your SLBase.h, it tries to redefine 'bool', the same problem will occur too when you compiling it in C++ mode.


>
> In article <d2le95$2gdu$1@digitaldaemon.com>, Matthew says...
>>
>>I'm compiling some C & C++ source files with DMC++.
>>
>>The C compilation is breaking on a typedef in some internal Synesis header file, which basically typedefs bool from unsigned int, in the case where native bool support is not detected:
>>
>>    h:\dev\include\SLBase.h(3131) : Error: 'bool' previously declared as something else
>>    It was declared as: int
>>    It is now declared: unsigned
>
> Jack