Softimage SDK Programmer's Guide > C++ API Development > Building C++ Plug-ins >

# Common Build Problems

- Cannot find include file

- Could not delete file

- Cannot open compiler intermediate file

- Undefined type

- Cannot convert

- Module machine type 'x86' conflicts with target machine type 'x64'

## Cannot find include file

If the XSISDK_ROOT environment variable is not set, you'll get an error message that looks like this:

    Cannot find include file: <xsi_application.h>

or this:

    c:\users\sblair\My Workgroup\Addons\Test\src\TestCommand.cpp(7) : fatal error C1083: Cannot open include file: 'xsi_application.h': No such file or directory

### Solution

On Windows, start Visual Studio from a Softimage command prompt. On Linux, source the .xsi_2013 resource file before you run gmake.

## Could not delete file

If a plug-in is loaded in Softimage, then the compiler will not be able to delete the existing dll, and you will get this error when you try to rebuild the plug-in:

    MyCommand : error PRJ0008 : Could not delete file 'c:\users\sblair\My Workgroup\Application\Plugins\Debug\MyCommand.dll'.

### Solution

Unload the plug-in before compiling.

## Cannot open compiler intermediate file

You can get this error after you start Visual C++ from a Softimage command prompt, exit Softimage, and then try to rebuild the plug-in.

    c1xx : fatal error C1083: Cannot open compiler intermediate file: 'C:\DOCUME~1\tamu\LOCALS~1\Temp\XSI_Temp_3092\_CL_aaa02860ex': No such file or directory

When Softimage starts up, it changes the value of the TMP and TEMP environment variables. These changes are inherited by Visual C++ when you start it from a Softimage command prompt that was opened from the Plug-in Manager. But if you exit Softimage, Softimage removes the temporary folders it created, leaving the TMP and TEMP environment variables pointing to non-existent folders.

### Solution

Exit and restart Visual C++, and then rebuild the plug-in.

## Undefined type

To increase compiler speed the C++ API header files often uses forward declaration, which can lead to this error if you don't include the header files for all the objects you want to use.

Error sample #1

    error C2027: use of undefined type 'Project'
    c:\Softimage\Softimage_2013\xsisdk\include\xsi_application.h(30) :
    see declaration of 'Project'

Error sample #2

    error C2079: 'ppg' uses undefined class 'XSI::PPGLayout'

Error sample #3

    error C2664: 'XSI::CustomOperator::AddIOPort' : cannot convert parameter 1
    from 'XSI::Primitive' to 'const XSI::CRef &'
    		Reason: cannot convert from 'XSI::Primitive' to 'const XSI::CRef'
    		Source or target has incomplete type

Error sample #4

    error C2679: binary '=' : no operator found which takes a right-hand operand of type 'XSI::Model'
    (or there is no acceptable conversion)

### Solution

Make sure you have included all necessary header files. Because of the naming convention of the header files it is easy to predict what header file contains each header.

Tip

If you prefer you could also create your own header file that includes many of the common Softimage header files.

For example, this table offers suggestions for solving the above sample errors:

Error to fix: | Directive to use:
--- | ---
Error sample #1 | include <xsi_project.h>
Error sample #2 | include <xsi_ppglayout.h>
Error sample #3 | include <xsi_primitive.h>
Error sample #4 | include <xsi_model.h>

## Cannot convert

CValue is the generalized data type that can store many types of data, including Softimage objects, which means that code that is being ported from scripting or which is generated by the cmdstubs utility will often use CValue to represent arguments.

For example:

    void DoSomething( const CValue & in_XSIRef )
    {
      //... stuff happens...
    }

Now suppose you want to pass a Softimage object to this function, for example a X3DObject:

    X3DObject someObj ;

    // Won't compile:
    DoSomething( someObj ) ;

This is the compiler error:

    error C2664: 'DoSomething' : cannot convert parameter 1 from 'XSI::X3DObject' to 'const XSI::CValue &'Reason: No constructor could take the source type, or constructor overload resolution was ambiguous

### Solution

A CValue takes a CRef as its representation of a Softimage object. All Softimage objects can be represented as a CRef, but they don't directly derive from CRef so they aren't truly CRef objects. However you can easily turn a Softimage object into a CRef by using the cast operator or the CBase::GetRef () function. Furthermore, you can turn a CRef into a CValue using the constructor or assignment operator. Put these two operations together and you can build a CValue out of an X3DObject.

In fact it is the fact that there are several ways to convert a Softimage object into a CValue that causes the compiler to complain, so the solution is to give the compiler some hint about exactly how it should turn the X3DObject into a CRef:

    DoSomething( CValue( someObj ) ) ;

or

    DoSomething( someObj.GetRef() ) ;

or

    DoSomething( (CRef&)someObj ) ;

To be really explicit you could use temporary variables. This shows what functions and constructors really get called:

    // This is just one of several options
     CRef& ref = someObj.GetRef() ;
     CValue val( ref ) ;
     DoSomething( val ) ;

Alternatively you could consider changing the function to be more specific about what type of object you expect, CValue is very vague:

- If the function only works for X3DObjects then that should be clear from the signature:

      void DoSomething( const X3DObject & in_XSIRef )
      {
      	//... stuff happens...
      }

- Or if the function works with any Softimage object you might want to use CBase or SIObject:

      void DoSomething( const SIObject & in_XSIRef )
      {
      	//... stuff happens...
      }

Note

The conversions between CValue, CRef, CBase are very fast and CRef and CBase are lightweight objects, so it is unlikely that you will have a big performance problem in normal circumstances. However within a tight loop or other performance critical bit of code it may be preferable to use explicit types instead of CValue.

## Unresolved external symbol

Any linker error that refers to an unresolved symbol in the C++ API is probably caused by not linking to sicppsdk.lib (or an old version):

    error LNK2001: unresolved external symbol "__declspec(dllimport) public:
    	class XSI::CRefArray __thiscall XSI::Operator::GetInputPorts(void)const "
    	(__imp_?GetInputPorts@Operator@XSI@@QBE?AVCRefArray@2@XZ)

    error LNK2001: unresolved external symbol "__declspec(dllimport) public:
    	__thiscall XSI::MATH::CRotation::~CRotation(void)"
    	(__imp_??1CRotation@MATH@XSI@@QAE@XZ)

Similarily, if there is an unresolved external symbol related to a missing constant then it is probably caused by not linking to sicoresdk.lib (or an old version):

    error LNK2001: unresolved external symbol "__declspec(dllimport) unsigned short const * const XSI::siControlCombo"
    (__imp_?siControlCombo@XSI@@3PBGB)

### Solution

Always link to sicoresdk.lib and sicppsdk.lib for any C++ API dll, and make sure the environment is properly set up to point to the correct installation of Softimage.

## Module machine type 'x86' conflicts with target machine type 'x64'

By default, .Net 2010 compiles in 64 bit, so if you are working in a 32-bit environment, the linker will generate an error (Linker Tools Error LNK1112):

    fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64
    '<user_home>\Application\Plugins\Debugx64\TestComponentSelection.obj

### Solution

Change the default Active solution configuration setting from Debug x64 or Release x64 to Debug or Release:

1. With the solution open, select Configuration Manager from the Build menu.

2. If the value in the Active solution configuration drop-down list is Debug x64 or Release x64 and you are compiling for a 32-bit environment, choose Debug or Release from the list and click Close.