Link Errors with VS2017 (I think it is something simple) #550
Comments
|
Are you linking dynamically or statically? |
|
Just recently upgraded to VS2017. Did not find anything special that one uses to do a static bind. These are the options I see included.Seems like it gets the other .lib files.
These are all my current library settings:
|
|
The decision about using dynamic vs. static linking is made at CMake configuration time. If you use CMake in your own project, and just import our CMake project, all should work out of the box. If you're doing your own thing, then you need to be aware of specific CPP flags to match your build. If you're using a static build (.LIB without a .DLL) you need to use -DNNG_STATIC_LIB in your compilation... This causes the headers not to use the _declspec() imports. If you're using a dynamic build, then this isn't used, and the nng.h header file will use _declspec() to import symbols by default. (When building the shared library the symbols are set up with the appropriate export version of _declspec(). It's unfortunate that there's not just "one" smart way to make this all work right on Windows. Windows DLLs are a bit of a nightmare. |
|
VS2007 uses your CMAKE, It seems to build like a charm. I have attached the static .lib that it created. I really like what you are doing here, and I want to be a help (and as distraction as possible). I.e. a contributor and not a distractor. Shown below is the results of the CMAKE. But I still suspect the simple culprits, like that VS2017 is just not finding the .lib on its libpath: /LIBPATH:"D:\Source\LinkWareMessageBus\nng\lib" it is called nng.lib, Is there a setting I need there in file properties? Do I need to make it part of the project? I attached the log of the cmake. |
|
I am attaching a dumpbin.exe of the symbols that I have in the nng.lib |
|
So yeah, you've built a static version of the library, which is fine. But you need to add a definition before #include of nng.h -- specifically NNG_STATIC_LIB needs to be present. I recommend adding -DNNG_STATIC_LIB to your compiler options. Normally importing the CMake project should have done this -- if it hasn't, then it is either a bug in my CMakeLists, or in the tool that's doing the import. Looking at my CMakeLists, I think it is doing the right thing here by doing the necessary: I don't use Visual Studio's IDE, so I can't be of much use to you there. (I use cmake and Ninja at the command line on Windows.) The other thing that could be an issue is if your CMake version is too old. A quick workaround for any of the above issues is simply to #define NNG_STATIC_LIB at the top of your own C files, before the #include <nng/nng.h>. |
|
The #define in the client that uses the nng.lib did not work. I get the same missing link errors. I am clueless about CmakeLists files. I modded the top level one at line 281 to look like this, but I am not seeing a switch added for NNG_STATIC_LIB |
|
You need to change /NNG_STATIC_LIB to /DNNG_STATIC_LIB -- or possibly -DNNG_STATIC_LIB I think either way will work with modern Visual Studio. |
|
If you look at the cmake.log file that I attached 5 notes earlier. You will see that that flag was already being added yesterday -DNNG_STATIC_LIB as in [26/274] "D:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.14.26428\bin\HostX64\x64\cl.exe" /nologo -DNNG_HAVE_BUS0 -DNNG_HAVE_CONDVAR=1 -DNNG_HAVE_PAIR0 -DNNG_HAVE_PAIR1 -DNNG_HAVE_PUB0 -DNNG_HAVE_PULL0 -DNNG_HAVE_PUSH0 -DNNG_HAVE_REP0 -DNNG_HAVE_REQ0 -DNNG_HAVE_RESPONDENT0 -DNNG_HAVE_SNPRINTF=1 -DNNG_HAVE_STRNLEN=1 -DNNG_HAVE_SUB0 -DNNG_HAVE_SURVEYOR0 -DNNG_LITTLE_ENDIAN -DNNG_PLATFORM_WINDOWS -DNNG_PRIVATE -DNNG_STATIC_LIB -DNNG_SUPP_HTTP -DNNG_TRANSPORT_INPROC -DNNG_TRANSPORT_IPC -DNNG_TRANSPORT_TCP -DNNG_TRANSPORT_WS -D_CRT_RAND_S -D_CRT_SECURE_NO_WARNINGS -D_WIN32_WINNT=0x0600 -ID:\Source\nng\src /DWIN32 /D_WINDOWS /W3 /MDd /Zi /Ob0 /Od /RTC1 /showIncludes /Fosrc\CMakeFiles\nng.dir\core\pollable.c.obj /Fdsrc\CMakeFiles\nng.dir\nng.pdb /FS -c D:\Source\nng\src\core\pollable.c The version for CMAKE I am seeing is 3.11.1804.2018 |
|
Right, but those are the build when building the core NNG library. Those flags may not be present when compiling your program. You need the -DNNG_STATIC_LIB flag to be present when compiling your own .c files. Probably modifying my (the NNG) CMakeLists is not going to help you. Instead you need to figure out where your compile definitions are located. Now it might actually be easier for you to build NNG as a dynamic library, since that's the default. In that case, you would need to rebuild NNG with the CMake option BUILD_SHARED_LIBS=ON. I really need to find a better way to deal with DLLs vs. static libs on Windows. |
|
What you say makes a lot of sense. OK. All I have is one .cpp file , so I have a define at the very top: I also added this switch on the compile in the project properties. I really want this to be a static library, since what I am going to do is create a single .DLL that is supposed to be loaded as a plugin to a mission simulator (something like Unity, Unreal) and I don't think they allow a plugin to be spread over two dlls (or it will think it is full plugin). One thing that gets my attention is that VS2017 is saying the unresolved symbol is no longer Funny, but the dumpbin.exe /headers says that is defined. I have an office mate who is giving all sorts of advice. Here is one of his: My two bits on static libs built using CMAKE then using MSVC. Static libraries are essentially glorified archive files (think "zip-file") containing the object files. When you do a TARGET_LINK_LIBRARIES(myStaticLib someOtherLib), CMake remembers that dependency internally and will add "someOtherLib" to all the link-lines where "myStaticLib" is used, but it can't possibly embed that information into the static library. If your downstream projects are CMake, you can tell CMake to "export" the myStaticLib target along with its dependencies to a special file which then can be imported by the downstream project. If it isn't, on Linux Mac and other Unix platforms (MinGW, Cygwin, etc.) you would write a pkg-config file which contains that information. With pure MSVC I don't think that this is possible, so IMHO you'll have to add the dependencies manually. |
|
I no longer say this is simple. But I did get further, and maybe you can help get over the finish line. Even though I was telling VS2017 where to find the nng.lib (the path and the name). I tried also putting it in with the kernel32.lib user32.lib and the other mandatory libs. OK. I am now no longer getting the errors about the nng_xxxx symbols. Rather it is now complaining about symbols that nng.lib is looking for. See below: |
|
Here is the verbose log of the link from VS2017: |
|
So it looks at least like winsock is missing. The cmake exported project
file would include those imports as your colleague suggests. Take a look in
the demo directory for an example of how to use.
…On Thu, Jun 21, 2018, 1:45 PM Dr. YSG ***@***.***> wrote:
Here is the verbose log of the link from VS2017:
verboseLink.txt
<https://github.com/nanomsg/nng/files/2125272/verboseLink.txt>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#550 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABPDfUzWWwh6yzrNcm08DXmRwFxuRAoYks5t_AXugaJpZM4Uv7m2>
.
|
|
Also if you email me directly with a us contact phone I can call and try to
walk you through it.
…On Thu, Jun 21, 2018, 2:40 PM Garrett D'Amore ***@***.***> wrote:
So it looks at least like winsock is missing. The cmake exported project
file would include those imports as your colleague suggests. Take a look in
the demo directory for an example of how to use.
On Thu, Jun 21, 2018, 1:45 PM Dr. YSG ***@***.***> wrote:
> Here is the verbose log of the link from VS2017:
>
> verboseLink.txt
> <https://github.com/nanomsg/nng/files/2125272/verboseLink.txt>
>
> —
> You are receiving this because you commented.
>
>
> Reply to this email directly, view it on GitHub
> <#550 (comment)>, or mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/ABPDfUzWWwh6yzrNcm08DXmRwFxuRAoYks5t_AXugaJpZM4Uv7m2>
> .
>
|
|
The libraries you would need to add for windows are: ws2_32 If you've included TLS or ZeroTier support when you build NNG (not default), then there will be others as well. |
|
that solves it. Fantastic support and responses. |
|
Not sure if this is related, but when I tried to do a build of nng on VS2019 I got an "unresolved external" error for basically all of the test projects that were generated. The nng library itself built fine (shared dll). The unresolved external was WSAPoll that is called on line 70 of stubs.h under windows. The issue is that the other projects aren't including the ws2_32 library as a dependency. adding the line |
Hi, I got a same issue like yours, can you tell me how you slove it, preciate. |
|
Have same issue here. I'm able to embed NNG (with source code) into my project with CMake+MSVC, but when I compile NNG as a static library (with |
I am trying to build a nanomsg next gen (https://github.com/nanomsg/nng) on a windows box. I am using VS2017 (windows 10) The CMAKE worked like a charm.
I am getting link errors. I have verifed that the nng.lib file is located at:
D:\Source\LinkWareMessageBus\nng\lib
Dumbin.exe says the symbols are all in place (and there were no compile or link errors)
that the Linker/General/Additional Library Directories is: D:\Source\LinkWareMessageBus\nng\lib
The .h files are read fine. But I am getting the following link errors:
The text was updated successfully, but these errors were encountered: