4

I built library by following instructions of link. In order to link that library to Visual Studio I used the following methods but none of them cannot link to that I built .lib file.

  1. Windows system variables add dynamic library path (Environment variables -> Path)

    • Set to; C:\Users\venushka\Desktop\libxbee3-win32\lib

  2. Visual Studio ( to include header and source files C++)

    • Configuration properties -> C/C++ -> General -> Additional include directories set to C:\Users\venushka\Desktop\libxbee3-win32

  3. Link the library

    • Configuration properties -> Linker -> General -> Additional Library directories set to
    • C:\Users\venushka\Desktop\libxbee3-win32\lib

  4. Add name of object library file

    • Configuration properties -> Linker -> input -> Additional Dependencies I added there as libxbee3.lib

  5. For linking purpose I added

    • Add -> Existing item (project properties) both .dll & .lib files but that thing also didn't make any difference still keep the same errors.

  6. Finally I add 

    #pragma comment (lib, "libxbee3.lib")
#pragma comment (lib, "libxbee3.dll")

I'm getting unresolved external errors which says that I couldn't link that library successfully. Any help is appreciated.

I have attached the screenshot Screenshot

Error log

Error   1   error LNK2019: unresolved external symbol _xbee_setup referenced in function _wmain C:\Users\venushka\documents\visual studio 2013\Projects\xbeetest\xbeetest\xbeetest.obj
Error   2   error LNK2019: unresolved external symbol _xbee_shutdown referenced in function _wmain  C:\Users\venushka\documents\visual studio 2013\Projects\xbeetest\xbeetest\xbeetest.obj
Error   3   error LNK2019: unresolved external symbol _xbee_conGetTypes referenced in function _wmain   C:\Users\venushka\documents\visual studio 2013\Projects\xbeetest\xbeetest\xbeetest.obj
Error   4   error LNK2019: unresolved external symbol _xbee_errorToStr referenced in function _wmain    C:\Users\venushka\documents\visual studio 2013\Projects\xbeetest\xbeetest\xbeetest.obj
Error   5   error LNK1120: 4 unresolved externals   C:\Users\venushka\documents\visual studio 2013\Projects\xbeetest\Debug\xbeetest.exe 1
Niall
  • 30,036
  • 10
  • 99
  • 142
VenushkaT
  • 1,152
  • 2
  • 19
  • 42
  • 2
    DLL's are not part of the build process, so why are you referring to them in your set of instructions? DLL's are only used when you run your program, not when you build it. – PaulMcKenzie May 28 '16 at 04:50
  • @PaulMcKenzie yap. You're correct i removed the import dll thank you. But still i couldn't compile the program. – VenushkaT May 28 '16 at 06:16

3 Answers3

6

You have covered most of the basic issues and "usual" suspects in the OP, such as library location, names etc.

Further issues could include;

  • Mixing x86 and x64 builds
  • The symbols are being exported from the dll (can be checked with dumpbin /exports)
  • Name mangling (although this should be fine here, it is a C API)
  • Incompatible symbol export annotations (mixing GCC and MSVC)

Given the sample code provided (linked in the comments), the link to the built lib and dll, I have been able to verify (using VS2015 update 2);

  • The symbols are being exported from the dll (as you have built it)
  • The names do not appear mangled, the extern "C" appears to be correctly applied
  • And a simple #define EXPORT __declspec(dllimport) added before the inclusion of the "xbee.h" file was added.

Given the above, and the x64 lib and dll, I can compile and link the sample code.

It leaves the x86 vs. x64 targets. By default, the VS wizard targets the x86 for a command line application. Using these defaults, I am able to reproduce the error.

To add the x64 platform;

  1. Open the "Configuration Manager" (Build > Configuration Manager)
  2. From the "Active Solution Platform" drop down menu, select
  3. Select x64 from the drop down for the new platform
  4. (Optionally) Select the settings to be copied from the x86 platform (these can be modified later as required)
  5. Check the box to "Create new project platforms" and click OK

Once added, in the build menus, select the x64 platform targets and rebuild the sample application.

If the x86 platform is the intended target, the libxbee3 library will need to be rebuilt to target the x86 platform and not the x64 platform.

Side note; VS2015 warns about the mismatched x86 and x64 targets (tested on update 2).

On the incompatible symbol export annotations.

You mention in the bounty notes that you;

That library was make from the source files of git ( make GNU for windows)

Most likely, the compiler used here is gcc. This is supported in the linked code base that the attribute used to export the symbols is;

#define EXPORT __attribute__((visibility("default")))

A search for the MSVC symbols used to achieve a similar result, __declspec(dllexport), produces no results.

To import symbols from the dll (and use them is your project), the MSVC compiler requires the corresponding __declspec(dllimport) on the desired symbols.

The typical (for MSVC) library side preprocessor block for this is;

#ifdef BUILDING_MY_DLL
#define MY_DLL_API __declspec(dllexport)
#else
#define MY_DLL_API __declspec(dllimport)
#endif

The above block is usually included in a header and the exported symbols are marked MY_DLL_API. When building the library, the define BUILDING_MY_DLL is defined either on the commandline or in some internally included header. When building the exe (or the client), the define BUILDING_MY_DLL is not made and hence the symbols are marked for importing.

To resolve the import/export symbol problem, there are some basic approaches.

The first is modifying the code and rebuilding the dll with MSVC and to use the dllexport and dllimport as above;

#ifdef BUILDING_LIBXBEE3
// define BUILDING_LIBXBEE3 on the command line when building the dll...
#define EXPORT __declspec(dllexport)
#else
#define EXPORT __declspec(dllimport)
#endif

The second, extracting the function signatures (and types) required, into a private header, to be used and annotating them alone with the correct dllimport.

extern "C" {

// ... other definitions required

__declspec(dllimport)
xbee_err xbee_setup(struct xbee **retXbee, const char *mode, ...);

} // extern "C"

A third would be to just define the EXPORT already used as __declspec(dllimport) and make sure that the define appears before inclusion of any of the library's header files. Basically add; 

#define EXPORT __declspec(dllimport)

To a file such as "stdafx.h" before any includes of "xbee.h"

Community
  • 1
  • 1
Niall
  • 30,036
  • 10
  • 99
  • 142
  • Thank you so much for your answer. But i feel its too complex to understand . But i tried to edit my code what i have learnt from your answer. But still i'm getting the same errors. Could you please kind enough to mention me what i have done wrong there. Thank you. https://drive.google.com/open?id=0BzXV5sHD5fcrWWZWNXJPUWIwMzg – VenushkaT Jun 01 '16 at 02:48
  • I've taken a look at the sample you uploaded, I've also clarified the answer a bit - you would only really need the `#define EXPORT __declspec(dllimport)` part. I haven't been able to build the library from source. You don't mention what build environment you use, but minnow-w64 doesn't work with the master nor the windows branches. I don't have cygwin to attempt that. Can you upload the dll and lib as well and I can try diagnose it from there. – Niall Jun 01 '16 at 09:38
  • could you please kind enough the following thank you so much. https://drive.google.com/open?id=0BzXV5sHD5fcrWVRfN21QUDByM0U – VenushkaT Jun 01 '16 at 10:34
  • @VenushkaT. I believe you are mixing the x86 and x64 targets in the binaries, these are incompatible and will produce the errors you have. – Niall Jun 01 '16 at 12:04
  • 1
    i used win32 branch. Anyway i will try 64 branch(since my machine is 64) and accept you're answer. thank you so much for your help. – VenushkaT Jun 02 '16 at 07:16
0

Possible cause of error:

  1. There was a header not included in xbeetest.cpp
  2. You included the dll file to the project, but not to the linking process.
  3. The linker went haywire.

Possible methods:

  1. use LoadLibrary().
  2. Not use dll and just use the whole source code
  • could you please explain it using code. Possible methods part i didn't get it. thank you. – VenushkaT May 28 '16 at 06:17
  • 1
    What is `#using`? That's something out of managed code, nothing to do with native C++. Irrelevant in this case, he's linking to a native library. Your answer is also not especially helpful, considering it is as generic as the error message the linker is already giving him. – Cody Gray - on strike May 28 '16 at 11:30
  • #using is used to include a dll file. –  May 28 '16 at 14:56
  • https://www.google.co.kr/search?q=%23using&oq=%23using&aqs=chrome.0.69i59j0l5.1844j0j7&sourceid=chrome&ie=UTF-8 –  May 28 '16 at 14:56
  • 1
    You linked me to a page of search results confirming that `#using` is from C++/CLI, which is a managed language. Nothing to do with native C++. The search results also suggest not using it even in .NET projects. Please avoid posting answers if you don't understand the question or the technologies involved. – Cody Gray - on strike May 30 '16 at 13:04
0

This is probably not full answer - but let's start from analyzing what you have inside your library.

How to See the Contents of Windows library (*.lib)

Can you run DUMPBIN /SYMBOLS libxbee3.lib and see what function symbols .lib exposes.

Visual studio 2015 run-time dependencies or how to get rid of Universal CRT?

Also I remember that "__imp_" function prefixes should be something that is imported / exported from .dll - may be your calling conversion is somewhere incorrect - so you need to ensure that __declspec(dllexport) on dll side and __declspec(dllimport) on caller side, and exported function entries starts from __imp_.

Community
  • 1
  • 1
TarmoPikaro
  • 4,723
  • 2
  • 50
  • 62