CODEWITHSUNDEEP
visual-studio-2010visual-c++buildc++-clilinker-errors
dario_ramos
dario_ramos

Reputation: 7309

Visual Studio, MSBuild: First build after a clean fails, following builds succeed

There's obviously something wrong with my build, but I can't figure it out. I narrowed this down to one of my projects: first build after clean fails, all following builds succeed.

I get linking errors which say that some symbols are already defined:

>------ Build started: Project: Problem, Configuration: Debug Win32 ------
> Blah blah blah...
23>     Creating library D:\SVN.DRA.WorkingCopy\Debug\Problem.lib and object D:\SVN.DRA.WorkingCopy\Debug\Problem.exp
23>ProblemDependency1.lib(PD1.obj) : error LNK2005: "public: unsigned short __thiscall PD2Class::getFoo(void)const " (?getFoo@PD2Class@@QBEGXZ) already defined in ProblemDependecy2.lib(ProblemDependency2.dll)
23>ProblemDependency1.lib(PD1.obj) : error LNK2005: "public: void __thiscall PD2Class2::`default constructor closure'(void)" (??_FPD2Class2@Image@DRA@@QAEXXZ) already defined in ProblemDependency2.lib(ProblemDependency2.dll)
23>D:\SVN.DRA.WorkingCopy\Debug\Problem.dll : fatal error LNK1169: one or more multiply defined symbols found

Any hint on troubleshooting this? I can post more info if needed

Update: I solved the first error thanks to Anders Abel's suggestion, but I still can't solve the second one (the one about the default constructor)

Update: If I compile using MSBuild outside Visual Studio, it fails always, with the same error

Edit: Here's some code. First, a bit of PD2Class2's declaration. PD2Class2's real name is CImage (feeling lazy to anonymize), CImage.h:

#pragma once
#pragma warning( disable: 4251 )    //TODO: Disable and solve

#include "ImageProperties.h"
#include "../CommonCppLibrary/CriticalSection.h"
#include <windows.h>
#include <stdexcept>
#include <string>

class CSharedMemory;
class EmptyImageException;
struct IShape;

struct SImageStatics {
    unsigned short low3Percentile;
    unsigned short high97Percentile;
    unsigned short medianPixelValue;
    unsigned short meanPixelValue;
    unsigned short minPixelValue;
    unsigned short maxPixelValue;
};

namespace DRA{
namespace Image{
class __declspec(dllexport) CImage {
    friend class CImageLock;

//Attributes
    int m_iPitch;
protected:
    mutable CImageProperties                    m_cProperties;
    CSharedMemory *                             m_pSharedMemmory;
    mutable DRA::CommonCpp::CCriticalSection    m_csData;
    static const float                          PIXEL_FREQUENCY_COVERAGE;
    static const float                          PIXEL_CUTOFF_PERCENTAGE;
    static const int                            MINIMUM_PIXEL_FREQUENCY;    //Pixels with a frequency lower than this are ignored
    static const int                            MINIMUM_WINDOW_WIDTH_FOR_16_BITS;

//Methods
    //Some private methods

public:

    CImage( DWORD dwWidth = 0, DWORD dwHeight = 0, ULONG uBytesPerPixel = 0,
            bool isSigned = false, EPhotometricInterpretation ePI = PI_UNKNOWN,
            UINT bitsStored = 0, float pw = -1.0f, float ph = -1.0f, BYTE * pData = NULL );
    CImage( const CImageProperties& cProperties, int iPitch = 0 );
    CImage( const CImage& rImage );
    virtual ~CImage();
    virtual CImage& operator=( const CImage& );
    bool operator==( const CImage& rImage );

//Alter State
    //More methods
//Query State
    //More methods
};
}
}

Next, the constructor's definition, from CImage.cpp:

CImage::CImage( DWORD dwWidth, DWORD dwHeight, ULONG uBytesPerPixel, bool isSigned,
                EPhotometricInterpretation ePI, UINT bitsStored, float pw, float ph,
                BYTE * pData ) :
        m_iPitch( dwWidth * uBytesPerPixel ),
        m_cProperties( dwWidth, dwHeight, uBytesPerPixel, bitsStored, ePI, isSigned, pw, ph ),
        m_pSharedMemmory( NULL ),
        m_csData(){
    m_pSharedMemmory = new CSharedMemory( pData ? pData : new BYTE[getSize()] );
}

Upvotes: 3

Views: 2271

Answers (3)

Anders Abel
Anders Abel

Reputation: 69250

Is getFoo() marked as __declspec(dllexport)? If it is an inline function, it is instantiated/used from wherever it is called through the included header. It shouldn't be part of the functions that the dll exports and it should not have a dllexport directive.

__declspec(dllexport) might be handled through a macro that is expanded to dllexport or dllimport depending on if it is the dll or code using the dll that is compiled. If there is any macro in the function declaration you might have to dig into it to find if there is an export directive.

Update

I think that if the header file is used both when the dll is built and when the dll is used, it is incorrect to have __declspec(dllexport) in the header file. Instead use a macro system:

#ifdef PROBLEMDEPENDENCY2
#define DLLEXPORT __declspec(dllexport)
#else
#define DLLEXPORT __declspec(dllimport)
#endif

class DLLEXPORT CImage
{
    //...
}

Then define the PROBLEMDEPENDENCY2 preprocessor symbol when building the dll, but not when using it. The problem with hardcoding __declspec(dllexport) in the header file is that the compiler will try to export the class both from ProblemDependency2 (which is correct) and from ProblemDependency1 (which is incorrect).

Upvotes: 3

Erik A. Brandstadmoen
Erik A. Brandstadmoen

Reputation: 10588

I dont' have much c++ experience, but problems like this in other .NET languages, often result from having a DLL reference to another project in the same solution (to the DLL in the "obj" or "bin" folder of the other project, instead of a project reference. This stops Visual Studio from being able to figure out the build order, and, hence, the first time after a "clean", you will not have the DLL you are depending on. On the second build, this DLL will already have been built, and the build will succeed.

Upvotes: 3

Wesley Long
Wesley Long

Reputation: 1708

Just something I've run into recently to check:

Are you building on a network volume? I had been having problems with not being able to debug my applications because the .pdb file was not "there" after the build and before the debug launch due to latency in the SAN that I was working on as a build directory.

Once I moved the project build to a local volume, everything was fine.

Don't know if that's what's happening to you or not, but something I'd look into.

Upvotes: 3

Related Questions