I am attempting to use the OFELI library in a CLI/C++ solution containing both C# and C++ projects, under VS2010. In short, the UI is written in WPF, and computations are done in CLR-enabled C++.
I downloaded the OFELI source, converted the solution to VS2010 format, and was able to successfully build the static lib. However, upon linking to the lib (ofeli-debug.lib) a slew of LNK2005 errors result;
error LNK2005: "private: static class std::locale::_Locimp * __cdecl std::locale::_Getgloballocale(void)" (?_Getgloballocale#locale#std##CAPAV_Locimp#12#XZ) already defined in msvcprtd.lib(MSVCP100D.dll)
I took care to insure that the lib was built with the /MDd setting, just as the project is. If I set the project to ignore msvcprtd.lib, I end up with a multitude of LNK2019 errors, as I'd expect.
Through experimentation, I've found that I can successfully link and use the ofeli lib from a non-CLR C++ test project, but not from a CLR enabled project (even if ofeli is compiled with CLR support enabled).
A simple code snippet which fails with many LNK2005 errors in my CLR project is below.
#include "stdafx.h"
#include <OFELI.h>
using namespace OFELI;
int _tmain(int argc, _TCHAR* argv[])
{
Mesh(10, 1); // Instance an object from the OFELI namespace
return 0;
}
What am I missing?
Related
I am trying to build The Mypintool sample that comes with pin distribution for x64 architecture.
I am using pin3.0 (build 76991) and Visual Studio 2012. The build is successful if I have not included windows.h.
But if I include window.h (in a separate namespace) like this:-
namespace WD {
#include "Windows.h"
}
Then the build gives the error :-
C:\Program Files (x86)\Windows Kits\8.0\Include\um\winnt.h(3486): error C2888: '_CONTEXT::<unnamed-tag>' : symbol cannot be defined within namespace 'WD'
C:\Program Files (x86)\Windows Kits\8.0\Include\um\winnt.h(3488): error C2888: '_CONTEXT::<unnamed-tag>::<unnamed-tag>' : symbol cannot be defined within namespace 'WD'
Also, I am able to build the tool for win32 with windows.h included without any issue. Also, I have compared the build settings for win32 and x64 and I could not find any discrepancy.
Any help is appreciated.
It is unclear to me if you have a windows application that makes use of "Pin" or a "Pin" application that needs to call some Windows APIs - or a hybrid where massive use of both APIs exists in a single program.
Nonetheless, the Windows SDK is quite large, and is designed (mostly) to work with C, or with a subset of C++ compatible with C so it cannot be expected to work if wrapped in a namespace.
So, your only effective way to deal with a conflict in headers, is to avoid it by never including the "pin" or "windows" headers in the same cpp file. You need to partition the parts of your program that call windows, and that call "pin" into separate cpp files.
Create a bridging header file that defines classes and functions that use only C++ declarations. As it makes no use of either pin, or windows, this file can be #included by both sides of your project. Of course, depending on what your application is attempting to achieve this may be difficult so you might have to engage in some heavy duty type erasure.
Something like this:
// pin.cpp
#include <intel/pin.h>
#include "bridge.h"
void method(){
Window* wnd = Window::Create();
wnd.Show();
}
.
// bridge.h
class Window {
public:
static Window* Create();
virtual void Show()=0;
};
.
// WindowsImpl.cpp
#include <windows.h>
#include "bridge.h"
class WindowImpl : public Window {
HWND hwnd;
public:
bool Create(){
hwnd = CreateWindowEx(...);
return hwnd != NULL;
}
void Show() override {
ShowWindow(hwnd,...);
}
};
Window* Window::Create(){
WindowImpl* newWnd = new WindowImpl();
newWnd->Create();
return newWnd;
}
First of all i am a beginner in visual studio so please forgive and guide me if i m going wrong in some way , i am a java and php programmer so i am not new to programming
i want to develop a application which reads fingerprint , i use this device
http://www.egistec.com/en/sensors/fingerprint-es603wb.aspx
which i think uses Windows Biometric Framework , so i tried to run the code mentioned in this page
http://msdn.microsoft.com/en-us/library/windows/desktop/ee207405(v=vs.85).aspx
this is what i did
#include "stdafx.h"
#include "Windows.h"
#include "Stdio.h"
#include "Conio.h"
#include "Winbio.h"
int _tmain(int argc, _TCHAR* argv[])
{ HRESULT CaptureSample(); }
you can find the function CaptureSample() in the second link provided above.
As you can see in the they said to link Winbio.lib, i know that its a dll in system32 , i did some research and created a Winbio.def file and Winbio.lib file,
Now my problem is i dont know how to link the lib file , i added "Winbio.lib" in properties >>LInker >> Additional Dependencies
it shows me the following error
*error LNK2019: unresolved external symbol _WinBioOpenSession#28*
infact this error appears even if i remove it from Additional Dependencies
please tell me where i am going wrong , should i place the lib file in any specific directory ? should i copy the dll somewhere ? or something else ?
Linker > General > Additional library Directoreis
put the path to the lib
Linker > Input
Put the lib name.
You can find this if you do some googling.
If everything is fine and still does not work, very probable that your lib file is not generated correctly. You can then try use dynamic loading of your dll file.
http://msdn.microsoft.com/en-us/library/ms810279.aspx
First loadLibrary is called to get a handle to your dll, then getProcAddress is called to get the pointer to the function. Cast the pointer into the target function defined in your h file. Then you'll be able to call the function.
I had the same problem. Following steps helped me on VS 2015 Community Edition
Right click on the project > Properties.
Linker > Input > then in the Addition Dependencies put winbio.lib; to front
I've got a huge legacy project which uses MFC and COM. The idea being to migrate it to Linux (winelib doesn't work for this), I need to identify the portions of the code that use MFC. Strange thing is that the solution contains two DLL projects which inherit from CWinApp and instantiate it. Besides, I don't see the purpose of CWinApp in these DLL's because the actual GUI code is in a separate non-dll project.
Two questions:
1. Is there any tool which can help me locate the MFC specific code so that I can remove it? Already saw the Qt option.
2. Why is CWinApp instantiated (as below) in a DLL project which isn't doing any GUI work at all? Is it used for message passing? I don't see any such syntax though. Removing the CWinApp instantiation results in a pointer of another project not being initialized. Weird!
One of the DLL project's code goes like this:
#include "stdafx.h"
#include "resource.h"
#include <initguid.h>
#include "dlldatax.h"
//removed some project-specific includes for posting on SO
#ifdef _MERGE_PROXYSTUB
extern "C" HINSTANCE hProxyDll;
#endif
CComModule _Module;
BEGIN_OBJECT_MAP(ObjectMap)
OBJECT_ENTRY(CLSID_MyManager, CMyManager)
//removed some other similar lines as the line above
END_OBJECT_MAP()
// Component Category Helper Functions
static HRESULT CreateComponentCategory( CATID catid, WCHAR* catDescription );
static HRESULT UnRegisterCategory( CATID catid );
class CMyClassWrapperApp : public CWinApp
{
public:
public:
virtual BOOL InitInstance();
virtual int ExitInstance();
DECLARE_MESSAGE_MAP()
};
BEGIN_MESSAGE_MAP(CMyClassWrapperApp, CWinApp)
END_MESSAGE_MAP()
CMyClassWrapperApp theApp;
BOOL CMyClassWrapperApp::InitInstance()
{
#ifdef _MERGE_PROXYSTUB
hProxyDll = m_hInstance;
#endif
_Module.Init(ObjectMap, m_hInstance, &LIBID_MyClassWrapperLib);
return CWinApp::InitInstance();
}
int CMyClassWrapperApp::ExitInstance()
{
_Module.Term();
return CWinApp::ExitInstance();
}
In your MFC project settings, change to Use of MFC to Use
Standard Windows Libraries. Then remove all includes starting with
'afx' from your StdAfx.h. The compilation errors will guide you to
all MFC specific parts!
CWinApp is there to allow your MFC executable to correctly use any MFC code in your DLL. The framework will initialize your DLL through this object. For non-MFC DLLs you would just use DllMain.
Regarding COM and no MFC, I would start by googling this: atl com codeproject
I'm wondering how Visual Studio, other IDE's, and any other sort of circumstances (ie. no IDE at all) handle bringing in code from outside.
At first I thought #includes were the only way to do this, by either placing the assembly files in the designated directory for Visual Studio assembly files and then using the <> format to bring them in, or by putting the assembly files in the project directory and using the "" format to bring them in (that is, <> and "" respectively). But now I come up to the example at the end of this post with the #using directive (which, to note, is different than just the 'using' directive without the '#', for namespaces). Also I've come across adding assembly references in visual studio from within the 'configuration properties' dialogue.
So, would someone set me straight on all the in's and out's of adding assembly files and other code to a given project?
--The following is the example that has confused me-->
I have this section in my book that states:
"...The figure combines C++ 2008 code
with legacy C and native C++ code. It
also presents the two assembly
reference files you'll use most often
with C++ 2008, along with their
associated namespaces. Unlike when
you use Visual Studio to develop a
project, the assembly reference files
aren't included by default when you
code a single source file. Because of
that, you must code #using directives
for these files. ..."
#include <stdio.h>
#include <iostream>
#using <system.dll>
#using <system.windows.forms.dll>
// Associated namespace directives
using namespace std;
using namespace System;
using namespace System::Windows::Forms;
void main()
{
printf( "Hello, Earth\n"); // from stdio.h
cout << "Hello, Mars\n"; // from iostream
Console::WriteLine("Hello, Jupiter"); // from system.dll
MessageBox::Show ("Hello, Saturn"); // from system.windows.forms.dll
}
This is not native C++ (usually just referred to as C++), but C++/CLI, which is actually a .NET language designed to ease interacting between native and managed code, and as such can use both. It is, however, definitely not C++, despite an intentionally strong resemblance. Assemblies are .NET managed code repositories. You use the #using command to use them. #include is for native C++ headers. You should also be able to add managed references (that is, #using but done throughout for you) from the project's properties.
In native C++, then you must #include headers, and if appropriate, link to .lib files (or use GetProcAddress manually), and Visual Studio also offers #import for COM libraries. C++/CLI also offers #using for bringing in managed assemblies.
void main()
{
printf( "Hello, Earth\n"); // C native code
cout << "Hello, Mars\n"; // C++/CLI's wrapper on C++ Standard
Console::WriteLine("Hello, Jupiter"); // .NET managed code
MessageBox::Show ("Hello, Saturn"); // A thin wrapper on WinAPI
}
If you don't already know both C++ and .NET code, and/or you're not trying to link the two together, it's not recommended to use C++/CLI.
I'm using the OpenCV library and one of its header files, cxoperations.hpp, generates "warning C4793: 'anonymous namespace'::CV_XADD' : function compiled as native", if my C++ project is compiled with CLR support. I can prevent the warning by surrounding the OpenCV header include like this:
#pragma managed(push,off)
#include <cv.h>
#pragma managed(pop)
But the project that actually uses OpenCV isn't compiled with CLR support, it's a native C++ static library. The project that does have CLR support, and generates this warning without the pragma statements, simply uses this static library. So I'm a bit surprised that the warning was created at all, especially given the fact that the entire static library is not compiled with CLR support, and yet it's only this one header that causes the problem.
Thus this solution seems sub-optimal to me. Is this how you would handle this warning, or can you recommend a better practice?
I think what you want is this:
#pragma unmanaged
#include <cv.h>
#pragma managed
// managed code wrapping unmanaged opencv functions
A C++/CLI project can contain both managed and unmanaged parts, and the compiler takes care of marshalling data between the 2 for you. The managed entry points will be callable from normal .NET apps (like C# and the rest) and will use garbage collection, and they'll call unmanaged functions to do the heavy lifting.
I think you should suppress the warning. The MSDN doc explicitly states that the managed/unmanaged pragmas should not be used before include statements.
#pragma warning(push)
#pragma warning(disable: 4793) // methods are compiled as native (clr warning)
#include <cv.h>
#pragma warning(pop)
If you cannot change existing code files, you can get rid of the warning by disabling CLR support for the specific file that shows warning 4793. Of course, this only works if this file does not make any use of CLR features.
To disable CLR support for a specific file, locate it in Solution Explorer, right-click and open its Property Pages. Set Common Language RunTime Support to No Common Language RunTime Support. Don't forget to do this for All Configurations and All Platforms.