lib1 has two files
math.h
inline void hello();
and math.cpp
#include <iostream>
#include "math.h"
void hello() {
std::cout << "hello from math";
}
lib2 is a c++ 2a module lib:
export module Bar;
import "math.h";
import std.core;
export namespace bar {
void BarFunc() {
hello();
}
}
visual studio 16.8.0
compiler will say:(Bar.ixx.obj) : error LNK2001: unresolved external symbol "void __cdecl hello(void)" (?hello##YAXXZ)
math.h
inline void hello();
to
void hello();
works.
Given the current information, I am afraid that I cannot determine the cause of the problem. So, I suggest that you could use DUMPBIN to help you find the cause.
The /EXPORTS and /SYMBOLS options of the DUMPBIN command-line tool are
useful here. They can help you discover which symbols are defined in
your .dll and object or library files. You can use the symbols list to
verify that the exported decorated names match the decorated names the
linker searches for.
In some cases, the linker can only report the decorated name for a
symbol. You can use the UNDNAME command-line tool to get the
undecorated form of a decorated name.
Related
I'm trying to create a managed (.net core) C++/CLI wrapper for a native library (Srt) but when referencing methods in the native lib I'm getting 2 build errors. I've referenced the headers srt.h from the native library, tried calling a method named srt_cleanup but get this on build:
error LNK2028: unresolved token (0A00000B) "extern "C" int __cdecl srt_cleanup(void)" (?srt_cleanup##$$J0YAHXZ) referenced in function "public: void __clrcall HeliosMediaStreamCliSrt::SrtReceiver::Stop(void)" (?Stop#SrtReceiver#HeliosMediaStreamCliSrt##$$FQE$AAMXXZ)
error LNK2019: unresolved external symbol "extern "C" int __cdecl srt_cleanup(void)" (?srt_cleanup##$$J0YAHXZ) referenced in function "public: void __clrcall HeliosMediaStreamCliSrt::SrtReceiver::Stop(void)" (?Stop#SrtReceiver#HeliosMediaStreamCliSrt##$$FQE$AAMXXZ)
Sample:
// pch.h
#ifndef PCH_H
#define PCH_H
#include <srt.h>
#include <stdio.h>
#include <tchar.h>
#include <memory>
#include <map>
#include <stdlib.h>
#endif //PCH_H
// SrtReceiver.h
#pragma once
using namespace System;
namespace TestSrt {
public ref class SrtReceiver {
public:
void SrtReceiver::Stop();
private:
};
}
// SrtReceiver.cpp
#include "pch.h"
#include "SrtReceiver.h"
namespace TestSrt {
void SrtReceiver::Stop() {
srt_cleanup();
}
}
Project Configuration:
General -> Configuration Type: Dynamic Library (.dll)
Advanced -> Common Language Runtime Support: .NET Core Runtime Support (/clr:netcore)
Advanced -> .NET Core Target Framework: .NET 5.0
C/C++ -> General -> Common Language Runtime Support: NetCore
I'm pretty rusty with C++ so I'm unfamiliar with the build system and its resulting in confusing errors. I've never tried doing anything with .net core in c++ before as C# is more my speed. This looks like something to do with build properties and the compiler is looking for the wrong internal method names. How would I go about fixing this?
I simply forgot to include the paths to the .lib files in Linker -> Input -> Additional Dependencies: /path/to/srt.lib
Simple, but spent hours of google searching to no avail. Hopefully this helps out other a C++ beginners as I didn't come across it.
I want to buy license for QR codes read and generating from Leadtools but first I want to try their demo tools. I'm using MSVC 2013 x64 compiler. I think I did everything as follows in documentation:
Copied all dll's to my project directory (where build and release folder are located)
Copied Include and Lib folders to my project directory and add this lines to .pro file.
LIBS += -L$$PWD/Lib/CDLLVC12/x64/ -lLtkrn_x
INCLUDEPATH += $$PWD/Include
PRE_TARGETDEPS += $$PWD/Bin/CDLLVC12/x64/Ltkrnx.dll
include and #define LTV19_CONFIG, here is my code:
#define LTV19_CONFIG
#include <iostream>
#include <Ltkrn.h>
#include <ClassLib/LtWrappr.h>
using namespace std;
int main( ){
if( LT_KRN == LBase::LoadLibraries( LT_KRN, LT_DLGKRN))
cout << "success" << endl;
L_TCHAR licenseFile[] = L"d:\\temp\\TestLic.lic";
L_TCHAR key[] = L"xyz123abc";
LSettings::SetLicenseFile( licenseFile, key);
return 0;
}
Ask leadtools support, but they don't have much experience with working with QT...
When I tries to build application I get following errors:
LNK2019: unresolved external symbol "__declspec(dllimport) public: static unsigned int __cdecl LBase::LoadLibraries(unsigned int,unsigned int)" (__imp_?LoadLibraries#LBase##SAIII#Z) referenced in function main
LNK2019: unresolved external symbol "__declspec(dllimport) public: static int __cdecl LSettings::SetLicenseFile(wchar_t *,wchar_t *)" (__imp_?SetLicenseFile#LSettings##SAHPEA_W0#Z) referenced in function main
For following methods documentation says that I only need one dll/lib package (ltkrn). How to fix it? Still I don't get differences between static and dynamic linkage and this could be the problem.
If your linker accepted the 64-bit Ltkrn_x.lib, this suggests the problem is related to how you're using LEADTOOLS and not to QT. That's why I'm posting this as suggested reply instead of a note.
When programming using LEADTOOLS with C++, you normally use one of 2 sets of headers and LIBs:
Either include L_Bitmap.H (or a bunch of headers that includes LtKrn.H) and use the Ltkrn_x, Ltfil_x, etc. set of LIB files.
Or include ClassLib\LtWrappr.h and use only one LIB file, which in your case is Ltwvc_x.lib
Although in both cases you would be using many of the same DLL files such as Ltfilx.dll and Ltkrnx.dll, the reason you don't need their LIB files when using LtWrapper is that the ClassLibrary performs late (on demand) loading of these DLLs at run-time instead of referencing their LIB files at link time.
That's also why you need to call LBase::LoadLibraries() and specify the DLLs you need before your code uses these DLLs.
So to summarize, please try this:
Remove #include "Ltkrn.h"
Remove the linker reference to Ltkrn_x.lib (although you'll need the DLL)
Keep #include "ClassLib/LtWrappr.h"
Add a linker reference to Ltwvc_x.lib
I've got 2 Question concerning exported function names.
I walked through the MSDN Example:
Creating and Using a Dynamic Link Library (C++)
Why can I access the dll function with their undecorated name? There is no .defFile. As MSDN states :
"dllexport of a C++ function will expose the function with C++ name mangling" I am wondering about why this works.
If I remove the __declspec(dllexport) resp. the macro and use instead a
#pragma comment(linker, "/EXPORT:"__FUNCTION__"="__FUNCDNAME__)
within the function body e.g.:
double __stdcall ExternalAdd(double arg1, double arg2)
{
#pragma comment(linker, "/EXPORT:"__FUNCTION__"="__FUNCDNAME__)
return arg1 + arg2;
}
I get a linker error. Why?
dumpbin /Exports on the dll shows:
ExternalAdd = #ILT+720(?ExternalAdd##YGNNN#Z)
dumpbin /Headers on the lib shows:
Symbol name : ExternalAdd
...
Name : ExternalAdd
Many thanks for your help.
I am trying to create a dll which uses the curl library for a very simple function. Everything works just fine, the only problem is, that the curl linking does not seem to work properly.
I use the same linking, preprocessordefines and include directories like in my executable project where it works just fine so i am pretty sure it´s not about my linking or binary files of the libary.
Are there any special properties to link a libary to a dll?
My minimal sample code:
C++ Mainfile:
#include "main.h"
#include <Windows.h>
#include <curlpp/cURLpp.hpp>
#include <curlpp/Easy.hpp>
#include <curlpp/Info.hpp>
#include <curlpp/Options.hpp>
#include <curlpp/Exception.hpp>
namespace CurlDll
{
void CallHost::Try()
{
curlpp::Easy request;
request.setOpt(new curlpp::options::UserAgent("Mozilla/4.0"));
request.setOpt(new curlpp::options::AutoReferer(true));
request.setOpt(new curlpp::options::FollowLocation(true));
request.setOpt(new curlpp::options::Url("http://xml.utrace.de"));
request.perform();
MessageBox(0,"lololowwwwwwwwwwwl", "wqgqwwwwwgq", MB_OK |MB_ICONINFORMATION);
}
}
BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason)
{return 1;}
Header file:
#ifdef MAIN_EXPORTS
#define MAIN_API __declspec(dllexport)
#else
#define MAIN_API __declspec(dllimport)
#endif
#include <iostream>
namespace CurlDll
{
class CallHost
{
public:
static MAIN_API void Try();
};
}
i get following linking errors #drescherjm
(47 , i will just post a few, i think that shouls be enough)
ERROR 2 error LNK2001: unresolved external Symbol
"__imp__WSAStartup#8".
ERROR 11 error LNK2001: unresolved external Symbol
"__imp__WSAGetLastError#0".
ERROR 33 error LNK2001: unresolved external Symbol
"__imp__setsockopt#20".
The linker errors are telling you that the linker cannot find definitions for these functions: WSAStartup, WSAGetLastError, setsockopt. These functions are defined in the import library Ws2_32.lib. You need to supply that import library to the linker.
This information is given in the documentation for the functions. For instance, the documentation for WSAStartup. At the bottom of the documentation topic is a table listing requirements. Note the required library, Ws2_32.lib.
The symbols WSAStartup, WSAGetLastError and setsocketopt are part of the Windows API, in Ws2_32.lib (e.g. see http://msdn.microsoft.com/en-gb/library/windows/desktop/ms742213(v=vs.85).aspx )
You should include ws2_32.lib as an additional library when you link your DLL. If you're using Visual Studio, it's likely that the search path should already find it; just add it as an additional library.
So actually, I suspect you're not using the exact same linker options compared to your .exe
If you're building a .exe or a .dll, the linker needs to ensure it can resolve ALL known symbols at link time.
I am currently trying to learn how to use premake 4 in order to apply it to the OpenGL sdk. I am currently trying to make a Visual Studio 2010 solution that constructs 2 projects, one being a static library, the other contains a single main source file, with the main method.
This project is extremely simple, and is solely for the purpose of learning premake. In the static library project, named Test, I have 2 files, Test.h and Test.cpp. Test.h contains the prototype for the method print(). print() simply prints a line to the console. Using premake, I linked the static library to the Main project, and in main.cpp I have included the Test.h file. My problem is this: in VS2010 I get this error when I attempt to build:
1>main.obj : error LNK2019: unresolved external symbol "void __cdecl print(void)" (? print##YAXXZ) referenced in function _main
1>.\Main.exe : fatal error LNK1120: 1 unresolved externals
Here is my code in the 4 files, the premake4.lua:
solution "HelloWorld"
configurations {"Debug", "Release"}
project "Main"
kind "ConsoleApp"
language "C++"
files{
"main.cpp"
}
configuration "Debug"
defines { "DEBUG" }
flags { "Symbols" }
configuration "Release"
defines { "NDEBUG" }
flags { "Optimize" }
links {"Test"}
project "Test"
kind "StaticLib"
language "C++"
files{
"test.h",
"test.cpp"
}
Test.cpp:
#include <iostream>
void print(){
std::cout << "HELLO" << std::endl;
}
Test.h:
void print();
Main.cpp:
#include <conio.h>
#include "test.h"
int main(){
print();
getch();
return 0;
}
If you are wondering why there is a getch() there, on my computer the console immediately closes once it reaches return 0, so I use getch() to combat that issue, which forces the window to wait until the user has pressed another key. Any advice on this issue would be wonderful, because I simply am not sure what the problem is. If it is something simple please dont castrate me on it, I have very little experience with premake and static libraries, which is why I am trying to learn them.
links {"Test"}
Lua is not Python. Whitespace is irrelevant to Lua, just like whitespace doesn't matter to C++. So your links statement only applies to the "Release" configuration. If you want it to apply to the project as a whole, it needs to go before the configuration statement, just like your kind, files, and other commands.
Premake4 works this way so that you could have certain libraries that are only used in a "Release" build (or Debug or whatever). Indeed, you can put almost any project command under a configuration. So you can have specific files that are used only in a debug build, or whatever.