'LIBCMT' conflicts with use of other libs + unresolved external symbols
Asked Answered
R

2

27

I have a program using OpenGL 3.2(+libs) and FreeType2. Then an other program with Boost and OpenSSL. The OpenGL side was to make sure text could be rendered and the boost/openssl program is to do a secure login/game server.

Both programs work fine by them selfs.

However adding Boost and OpenSSL to the game(GL + freetype) project caused it to fail to link.

I have linked the following libs as well as including there includes folder.

glimg.lib glutil.lib glfw.lib opengl32.lib freetype.lib glew32.lib user32.lib libeay32.lib ssleay32.lib

The linker error is.

1>LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library
1>libeay32.lib(cryptlib.obj) : error LNK2001: unresolved external symbol __imp__DeregisterEventSource@4
1>libeay32.lib(cryptlib.obj) : error LNK2001: unresolved external symbol __imp__ReportEventA@36
1>libeay32.lib(cryptlib.obj) : error LNK2001: unresolved external symbol __imp__RegisterEventSourceA@8
1>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol __imp__DeleteDC@4
1>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol __imp__DeleteObject@4
1>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol __imp__GetBitmapBits@12
1>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol __imp__BitBlt@36
1>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol __imp__GetObjectA@12
1>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol __imp__SelectObject@8
1>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol __imp__CreateCompatibleBitmap@12
1>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol __imp__GetDeviceCaps@8
1>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol __imp__CreateCompatibleDC@4
1>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol __imp__CreateDCA@16
1>.\BasicTexture.exe : fatal error LNK1120: 13 unresolved externals

Runtime Library is set to Multi-threaded DLL (/MD)

I have no idea what to do I would really appreciate any help.

Remembrancer answered 3/1, 2013 at 23:23 Comment(2)
The unresolved externals are due to not linking against required libraries (Advapi32.lib and Gdi32.lib). The first warning indicates that your project and some of the libraries you are linking against have incompatible linker settings with respect to the CRT. Apart from that it appears that you are not compiling a Unicode build. Is there a reason for that?Parchment
Thanks Tim. Not sure on the unicode stuff I just used premake4 to make the vs solition and changed anything I needed(I have selected yes for unicode). Would you like it make that an answer because you have fixed it! the build succeeded. THANK YOU VERY MUCH! :)Remembrancer
P
31

Unresolved external error messages are produced when the compiler generates code referencing externally defined objects or functions and the linker fails to find those. To generate code invoking a function call the compiler only needs a declaration:

extern "C" BOOL DeregisterEventSource ( HANDLE hEventLog );

This is enough information to produce a call instruction (except for the target address). The extern keyword informs the compiler that the implementation is defined elsewhere. Consequently it cannot know the target address which has to be filled in later. When the compiler is done it is the linker's job to connect the pieces together. It uses the information gathered from the import libraries to look up the required offsets.

Windows API calls are easily spotted in the error log. They have an __imp__ prefix and sometimes an A or W postfix followed by @<n> where <n> indicates the number of bytes required for the arguments. In the case of a Windows API call you can then look up the function in the MSDN (like DeregisterEventSource). Towards the bottom are the Requirements where you can find the import library name.

The conflict warning indicates that not all of the modules use the same runtime library. Even though this is just a warning it is a serious issue and should be resolved. You get this warning if you mix /MD and /MT compiler switches, but also, if you mix release and debug runtime libraries (like /MD and /MDd). To diagnose this message you can use the /VERBOSE:LIB linker switch to determine which libraries the linker is searching. Additional information on this warning can be found at this MSDN link.

Parchment answered 4/1, 2013 at 13:33 Comment(1)
+1 for the insight that the imp prefix implies a Windows API call. I've seen that prefix before in linker errors but didn't know why it was prefixed to the symbol.Kulun
B
36

You are trying to compile with /MD, which is probably the right choice, but some code (probably one of the libraries) was built with /MT, and you can't have it both ways in the same program. You need to figure out which library was built with /MT and rebuild it with /MD.

Bucharest answered 4/1, 2013 at 0:47 Comment(2)
or, if you don't have source for the culprit lib, link your project with /MTHeavyduty
Thanks for the reply, The issue was solved by Tim in the comment on the question about an hour. I would like to give him the answer accept. However +1. Because I did check that everything was MD threaded before posting the question.Remembrancer
P
31

Unresolved external error messages are produced when the compiler generates code referencing externally defined objects or functions and the linker fails to find those. To generate code invoking a function call the compiler only needs a declaration:

extern "C" BOOL DeregisterEventSource ( HANDLE hEventLog );

This is enough information to produce a call instruction (except for the target address). The extern keyword informs the compiler that the implementation is defined elsewhere. Consequently it cannot know the target address which has to be filled in later. When the compiler is done it is the linker's job to connect the pieces together. It uses the information gathered from the import libraries to look up the required offsets.

Windows API calls are easily spotted in the error log. They have an __imp__ prefix and sometimes an A or W postfix followed by @<n> where <n> indicates the number of bytes required for the arguments. In the case of a Windows API call you can then look up the function in the MSDN (like DeregisterEventSource). Towards the bottom are the Requirements where you can find the import library name.

The conflict warning indicates that not all of the modules use the same runtime library. Even though this is just a warning it is a serious issue and should be resolved. You get this warning if you mix /MD and /MT compiler switches, but also, if you mix release and debug runtime libraries (like /MD and /MDd). To diagnose this message you can use the /VERBOSE:LIB linker switch to determine which libraries the linker is searching. Additional information on this warning can be found at this MSDN link.

Parchment answered 4/1, 2013 at 13:33 Comment(1)
+1 for the insight that the imp prefix implies a Windows API call. I've seen that prefix before in linker errors but didn't know why it was prefixed to the symbol.Kulun

© 2022 - 2024 — McMap. All rights reserved.