3

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
  • Problem is a C++/CLI project, built with the /clr switch, which references the unmanaged C++ projects ProblemDependency1, a static lib, and ProblemDependency2, a dll.
  • ProblemDependency1 references ProblemDependency2.
  • getFoo() is declared as inline and defined outside of the class declaration, in the .h
  • PD2Class2 doesn't have an explicitly defined default constructor, but it has a constructor which has all default arguments, so you could say it includes the default constructor as a special case
  • The .h's where these are defined have #pragma once as their first line.

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()] ); }
Improve this question
3
  • Can you please post some parts of the code? I would like to see the class and constructor (with all default parameters) declaration in the header file for PD2Class2 (you can strip the rest of the class to shorten the code). Also please include any macros used in the class / constructor declaration. Commented Aug 5, 2011 at 14:01
  • Is the definition of the constructor within an .h file or in a .cpp file? Commented Aug 5, 2011 at 17:16
  • They're in separate .h and .cpp files Commented Aug 5, 2011 at 17:29

3 Answers 3

Reset to default
3
+100

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).

Improve this answer
Sign up to request clarification or add additional context in comments.

4 Comments

The whole class is marked as __declspec(dllexport). Didn't know that, gonna try unmarking the class and marking only the non-inline methods
You hit the nail on the head, that solved getFoo()'s error. However, the constructor error remains
Sweet! That fixed it in my box. If it works on the Continuous Integration Server, yer in fer some bounty matey!
Actually, it failed in the CI server (it seems MSBuild didn't see the macro definition I put in the project options, and Visual Studio did). But that's a whole different question, so that's it for this one
3

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.

Improve this answer

1 Comment

Nope, it's all local. Good to know that, anyway
3

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.

Improve this answer

4 Comments

You can't mess up that way with C++ projects. When you add a reference (right click the project in Solution Explorer, hit References, hit Add New Reference), you only get a project list to choose from. You can't browse for a dll like in C# or VB.NET. Of course, you can mess up using #pragma comment or fiddling with the linker input options, but we stick to the way I first described, except for third party dlls, for which we use the linker options
Ok, maybe a red herring, then, however, could it be that the depending project is dependent upon something other than the DLL output from the DLL you depend on, which is generated on build, but VS is not able to see the dependency? Have you looked at the output from the build? Is the build order in the order you would expect, in respect to the dependencies?
Your last question's a good shot, let me check that thoroughly
in my case it was because i was referencing a dll from the bin folder of another project instead of referencing the dll from the 'packages' folder. i.e. i had not installed a nuget package in both projects. Instead i had installed the package in one project, and referenced that dll from another project

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.