XLW is an open sourced library that wrap C++ code into XLL add-in for Excel. A strange LNK4006 error is reported in a project i'm handling, reporting an XLW function is "already defined".
I'm using XLW version 4.0.0.f0, to simplify the situation, I break down it to a toy project, there are only three files --
StdAfx.cpp, the boilterplate file :
#include "stdafx.h"
StdAfx.h, boilterplate but mysterious (I never understood the content)
#if !defined(AFX_STDAFX_H__0D719468_50D1_11D2_9DAF_00207813663F__INCLUDED_)
#define AFX_STDAFX_H_0_D719468_50D1_11D2_9DAF_00207813663F__INCLUDED_
#if _MSC_VER >= 1000
#pragma once
#endif // _MSC_VER >= 1000
#define VC_EXTRALEAN // Exclude rarely-used stuff from Windows headers
#include <afxwin.h> // MFC core and standard components
#include <afxext.h> // MFC extensions
#ifndef _AFX_NO_AFXCMN_SUPPORT
#include <afxcmn.h> // MFC support for Windows Common Controls
#endif // _AFX_NO_AFXCMN_SUPPORT
//{{AFX_INSERT_LOCATION}}
// Microsoft Developer Studio will insert additional declarations immediately before the previous line.
#endif // !defined(AFX_STDAFX_H__0D719468_50D1_11D2_9DAF_00207813663F__INCLUDED_)
and then the puzzle, WhyLNK4006.cpp:
#include <xlw/xlw.h>
void WhyLNK4006()
{
xlw::XlfExcel &x = xlw::XlfExcel::Instance();
xlw::XlfExcel::Instance().FreeMemory();
}
This will trigger an LNK4006 error, which I could suppress it as a warning but couldn't guess why this happen:
xlw-vc120-mt-gd-4_0_0f0.lib(XlfExcel.obj) : warning LNK4006: "public:
void __thiscall xlw::XlfExcel::FreeMemory(bool)"
(?FreeMemory#XlfExcel#xlw##QAEX_N#Z) already defined in B15.obj;
second definition ignored
I couldn't understand, why there's such an error?
Both XLW and my toy project are compiled as /MTd, all XLW header file XXX.h have preprocessor protection e.g.
> #if !defined(XXX_H)
> #define XXX_H //the read content of XXX.h
> #endif
How come this could lead to a double definition?
I am building an application that uses freeglut, in windows 32bit, debug mode. I have linked the static debug freeglut lib.
To fix linkage errors, as mentioned here:
freeglut error LNK1104
I have added:
#define FREEGLUT_STATIC
#define _LIB
#define FREEGLUT_LIB_PRAGMAS = 1
to the head of my .cpp.
That solves the linkage errors, but gives me an error in the freeglut_std.h file.
These sections:
# if FREEGLUT_LIB_PRAGMAS
# pragma comment (lib, "freeglut_static.lib")
# endif
# if FREEGLUT_LIB_PRAGMAS
# pragma comment (lib, "glu32.lib") /* link OpenGL Utility lib */
# pragma comment (lib, "opengl32.lib") /* link Microsoft OpenGL lib */
# pragma comment (lib, "gdi32.lib") /* link Windows GDI lib */
# pragma comment (lib, "winmm.lib") /* link Windows MultiMedia lib */
# pragma comment (lib, "user32.lib") /* link Windows user lib */
# endif
give me:
Error 3 error C1017: invalid integer constant expression freeglut_std.h 72 1
4 IntelliSense: expected an expression freeglut_std.h 72 12
Where am I going wrong here?
Thank you.
When trying to build a project using glut I get an error. Not in the main.cpp but rather in the glut.h I've included.
#pragma comment (lib, "winmm.lib") /* link with Windows MultiMedia lib */
#pragma comment (lib, "opengl32.lib") /* link with Microsoft OpenGL lib */
#pragma comment (lib, "glu32.lib") /* link with OpenGL Utility lib */
#pragma comment (lib, "glut32.lib") /* link with Win32 GLUT lib */
#pragma warning (disable:4244) /* Disable bogus conversion warnings. */
#pragma warning (disable:4305) /* VC++ 5.0 version of above warning. */
All of these lines are the ones who show an error with the description:
Warning: ignoring #pragma warning [-Wunkown-pragmas]
It's the same error for all of the these lines.
I also get one additional error, also in the glut.h file. It's on the line:
typedef unsigned short wchar_t;
This error reads:
error: redeclaration of built in C++ type "wchar-t" [-fpermissive]
Anyone who's got an idea of how I should go about solving this issue.
The linking seems to be fine since it realizes that the glut.h file
exist but the glut.h is the file providing the errors.
I am trying to compile Boost 1.47 for x86 Windows CE using Visual Studio 2008 and STLPort 5.2.1. I can successfully compile for x86 Windows and ARMV4I Windows Mobile 6.5.
When I run bjam, I get this error in most every module:
stlport\ctype.h(42) : fatal error C1083: Cannot open include file: '../1/ctype.h': No such file or directory
That line of code the error refers to in STLPort's ctype.h is:
#include _STLP_NATIVE_C_HEADER(ctype.h)
If I create a new Visual Studio project and add the lines:
#define STR1(x) #x
#define STRINGIZE(x) STR1(x)
#pragma message (STRINGIZE(_STLP_NATIVE_C_HEADER(ctype.h)))
I see: <../X86/ctype.h> as I would expect.
Why is boost replacing "X86" with "1"? It does not have this issue when compiling for ARMV4I Windows Mobile or x86 Windows.
Edit
More information. Something is very deliberately doing a string replace on "X86".
In stlport\stl\config_evc.h I added the pragma messages to this code:
# if !defined (_STLP_NATIVE_INCLUDE_PATH)
# if defined (_X86_)
# if defined (_STLP_WCE_TARGET_PROC_SUBTYPE_EMULATOR)
# define _STLP_NATIVE_INCLUDE_PATH ../Emulator
# else
# define _STLP_NATIVE_INCLUDE_PATH ../X86
# pragma message (STRINGIZE(../abcdefg))
# pragma message (STRINGIZE(../X86))
# pragma message (STRINGIZE(_STLP_NATIVE_INCLUDE_PATH))
# endif
The output is:
../abcdefg
../1
../1
You have X86 macro defined (either by one of the earlier-included headers, or from a command line) and set to 1, so it gets expanded, like macros tend to do. #undef X86 will get rid of it.
Please look at the following file: (it is a complete file)
#ifndef TEES_ALGORITHM_LIBRARY_WRAPPER_H
#define TEES_ALGORITHM_LIBRARY_WRAPPER_H
#ifdef _TEES_COMPILE_AS_LIB
#include <dfa\Includes\DFC_algorithms.hpp>
#include <DFA\FuzzyClassifier\FuzzyAlgorithmIntialization\InitFuzzyAlgorithm.hpp>
typedef teesalgorithm::tees_fuzzy_algorithms algorithms_switchyard_class;
#else
#include <DFA\Includes\commercial_algorithms.hpp>
//An incomplete class to hide implementation
class algorithms_switchyard_class;
#endif
class AlgorithmLibraryWrapper {
algorithms_switchyard_class * algorithmPtr_;
typedef teesalgorithm::tees_paramObj paramObj_type;
typedef teesalgorithm::tees_errorObj errorObj_type;
typedef teesalgorithm::tees_statusObj statusObj_type;
typedef teesalgorithm::tees_dataObj dataObj_type;
typedef teesalgorithm::tees_outputObj outputObj_type;
public:
AlgorithmLibraryWrapper(const std::string& sAlgName, paramObj_type& paramObj, errorObj_type& errObj, statusObj_type& statusObj, const char* sFilePath);
static bool dataReader(const std::string& sFileName, dataObj_type& dataObj, errorObj_type& errObj, statusObj_type& statusObj);
bool runalgorithm(const dataObj_type& dataObj, outputObj_type& outObj, errorObj_type& errObj, statusObj_type& statusObj);
~AlgorithmLibraryWrapper();
};
#ifdef _TEES_USE_COMPILED_ALGORITHM_LIB
# ifdef _MSC_VER
#if _MSC_VER < 1400 // If VC 2003
#ifdef _DEBUG
#error No AlgorithmLibWrapper libraries compiled for this version of VC
#else
#error No AlgorithmLibWrapper libraries compiled for this version of VC
#endif
#elif defined(UNDER_CE) // Win CE
#ifdef _DEBUG
#pragma comment( lib, "AlgorithmLibWrapperCEd" )
#else
#pragma comment( lib, "AlgorithmLibWrapperCE" )
#endif
#else // If VC 2005
#ifdef _DEBUG
#pragma comment( lib, "AlgorithmLibWrapperd" )
#else
#pragma comment( lib, "AlgorithmLibWrapper" )
#endif
#endif
#endif
#endif
#endif //TEES_ALGORITHM_LIBRARY_WRAPPER_H
I am getting the following errors; I don't know why. I manually counted the preprocessor directives also.
AlgorithmLibraryWrapper.hpp:10:1: unterminated #ifdef
AlgorithmLibraryWrapper.hpp:7:1: unterminated #ifndef
I am using the poor vxWorks gcc compiler. Please let me know if the fault is mine or the compiler's.
It could be that the problem is in the included files (if there actually are unbalaced #if/#endifs.
I would try preprocessing with another compiler. You can use gcc for that, doesn't matter it wouldn't compile. Just get gcc (or MinGW if you're on Windows) and run
cpp -Iinclude_direcories your_file
Or, if you don't like gcc, get MSVC Express edition. Again, you can preprocess code that even doesn't compile, so no problem with nonworking library etc.
Most compilers have an option that will give you the output from the preprocessor so you can check what it's doing. For example,
gcc -E file.c >file.preproc
will give you the pre-processed source so you can check the balancing of #if against #endif.
At a guess, one of the files you are #including from this one has a mismatched #ifdef/#endif pair. You need to look at all the files (as the preprocesor does), not just this one.
As others have noted, this is most likely due to mismatched include guards.
If the files you are including are under your control (i.e. not part of a 3rd party closed source library), you could consider replacing the #ifndef et. al. guards (which are used to prevent multiple inclusion) with #pragma once. This will eliminate the possibility of having mismatched preprocessor directives.
One caveat of this is that pragma once is non-standard, so it will only work if your compiler supports it.
I have tried to compile your source using vs 6.0 but did not get the error you have mentioned. As others said may be the error is coming from the included header file . For me to get your code compiled i need to comment the above header.
Please check the above header once.
I'd debug this by commenting out sections one by one and trying to identify which section is causing the error.
It could be your compiler does not like the nested #ifdefs or does not interpret the syntax correctly. Maybe it doesn't like the #pragmas.
This is a long shot, but in your source file you have the following line:
# ifdef _MSC_VER
where there is whitespace between the '#' character and the directive name (ifdef). This is valid in C/C++; however, it's not too commonly seen so I wouldn't be very surprised if the odd compiler choked on it.