Linking error while using Qt static built libraries - c++

I'm developing a native C++ application using Qt 4.8.3 and VS2008. Since clients run the application on their naked machines, they need to install VC++ 2008 Redistribution package. So I decided to make it statically linked.
I changed my project settings (C/C++ > Code Generation > Runtime Library) to /MTd. Also
I compiled Qt again, this time using following commands for a static building; originally found on this blog Static Qt with static CRT (VS 2008)
1- replaced -MD with -MT in lines QMAKE_CFLAGS_RELEASE and QMAKE_CFLAGS_DEBUG in %QDIR%\mkspecs\win32-msvc2008\qmake.conf
2- nmake confclean
3- configure -static -platform win32-msvc2008 -no-webkit
4- nmake sub-src
I compiled Qt successfully. But when I tried again to compile my application, it gave me some strange errors.
1>Linking...
1>qtmaind.lib(qtmain_win.obj) : error LNK2005: "public: bool __thiscall QBasicAtomicInt::deref(void)" (?deref#QBasicAtomicInt##QAE_NXZ) already defined in QtCored4.lib(QtCored4.dll)
1>qtmaind.lib(qtmain_win.obj) : error LNK2005: "public: bool __thiscall QBasicAtomicInt::operator!=(int)const " (??9QBasicAtomicInt##QBE_NH#Z) already defined in QtCored4.lib(QtCored4.dll)
1>qtmaind.lib(qtmain_win.obj) : error LNK2005: "public: __thiscall QString::~QString(void)" (??1QString##QAE#XZ) already defined in QtCored4.lib(QtCored4.dll)
I changed some lib files but with each change, situation got worse; for example I tried to use QtCored.lib instead of QtCored4.lib because it is newly created after compilation.
I think I've missed something in building static Qt libs.

Although this question has remained unanswered since late 2012, I thought it might be a good idea to further populate the general knowledge on this issue in order for each thread to display at least one response.
The problem stems from the inclusion of the QtCored4.dll and QtGuid4.dll during the link process when building Qt statically. To exclude these from the build process, simply add QT_NODLL as a preprocessor directive when configuring Makefile. For instance, this may be achieved using the following command (for Microsoft Visual Studio 2008):
configure -static -debug -D QT_NODLL -platform win32-msvc2008
prior to running NMAKE.
A good practice when building static Qt applications using the Visual Studio IDE is to modify the project configuration type to Makefile using the Configuration Properties->General->Configuration Type drop-down menu. Once these settings have been applied, the user may also specify qmake and nmake steps to perform for Build and Rebuild All options under Configuration Properties->General->NMake.
For instance the build command-line for static debug configuration would be:
nmake debug
And the rebuild-all equivalent:
qmake app_debug.pro && nmake debug
I hope this helps!

Related

[UE4]error LNK2005 on linking libprotobuf

Having a small issue with conflicting libraries while packaging an Unreal Engine 4.27 project.
My project contains this gRPC library from google and I followed these steps to build it with CMake and after include it in my Unreal Project.
In addition my project requires enabling PixelStreaming plugin. However it seems that this plugin imported another version of protobuf which, on packaging is conflicting with the one included in gRPC.
The error is the following:
libprotobuf.lib(coded_stream.obj) : error LNK2005: "public: __cdecl google::protobuf::io::CodedOutputStream::CodedOutputStream(class google::protobuf::io::ZeroCopyOutputStream *,bool)" (??0CodedOutputStream#io#protobuf#google##QEAA#PEAVZeroCopyOutputStream#123#_N#Z) already defined in webrtc.lib(coded_stream.obj)
appearing for different objs.
I came across similar issues as such but disabling gRPC is not a feasible solution for me.
Could anyone advise on how to "instruct" the built gRPC to use the existing protobuf library from Pixel Streaming plugin?
Which steps do I need to take to properly configure these conflicting libraries?
having the same issue with GCP libs.
This issue seems to be caused by an bad commit of Protobuf (3.16.0 the branch linked by GRPC doesn't build correctly it seems)
If you build a different branch of protobuf manualy and use -DgRPC_PROTOBUF_PROVIDER=package
option when building gRPC you should be able to get this to work.
Im working in an msys environment so not 1 to 1 but my commands for building both protobuf and grpc are.
//protobuff
C:/msys64/mingw64/bin/cmake.exe -H. -Bbuild-output -G "MinGW Makefiles" -DCMAKE_MAKE_PROGRAM=C:/msys64/mingw64/bin/mingw32-make.exe -DCMAKE_C_COMPILER=C:/msys64/mingw64/bin/gcc.exe -DCMAKE_CXX_COMPILER=C:/msys64/mingw64/bin/g++.exe -DCMAKE_INSTALL_MESSAGE=NEVER -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=ON -DCMAKE_CXX_STANDARD=17 -Dprotobuf_BUILD_TESTS=OFF -Dprotobuf_ABSL_PROVIDER=package
//gprc
C:/msys64/mingw64/bin/cmake.exe -H. -Bbuild-output -G "MinGW Makefiles" -DCMAKE_MAKE_PROGRAM=C:/msys64/mingw64/bin/mingw32-make.exe -DCMAKE_C_COMPILER=C:/msys64/mingw64/bin/gcc.exe -DCMAKE_CXX_COMPILER=C:/msys64/mingw64/bin/g++.exe -DCMAKE_INSTALL_MESSAGE=NEVER -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=ON -DCMAKE_CXX_STANDARD=17 -DgRPC_INSTALL=ON -DgRPC_BUILD_TESTS=OFF -DgRPC_ABSL_PROVIDER=package -DgRPC_CARES_PROVIDER=package -DgRPC_PROTOBUF_PROVIDER=package -DgRPC_RE2_PROVIDER=package -DgRPC_SSL_PROVIDER=package -DgRPC_ZLIB_PROVIDER=package
Building protobuf 3.20.x seemed to work for me (though having issues with absl further down the line)
What solved my issue was migrating to UE5.
Using the same steps with aforementioned grpc project, in UE5 new project. Having a libprotobuf.lib in ThirdPary folder within UE5 project the packaging process worked with no LINK conflicts. Not sure why UE packaging did not complain this time but what works, works!

VS auto-linking against SDL2 libraries installed with vcpkg on Windows

To the best of my knowledge, this isn't a duplicate of an existing question. This question is specifically about Visual Studio's auto-linking SDL2 libraries.
I've installed SDL2 (x64-windows variant) with vcpkg:
vcpkg install sdl2 --triplet x64-windows
And I've made vpkg libraries available to Visual Studio:
vcpkg integrate install
My VS 2019 project is configured to use the Console subsystem, and my main program looks like that:
#define SDL_MAIN_HANDLED
#include <SDL2/SDL.h>
int main(int, char*[])
{
}
Why do I need to specify SDL_MAIN_HANDLED? It seems that auto-linking with SDLmain2.lib doesn't happen for some reason?
If I don't specify SDL_MAIN_HANDLED, linking fails:
unresolved external symbol main referenced in function "int __cdecl invoke_main(void)" (?invoke_main##YAHXZ)
I've also tried adding extern "C" on main() declaration but to no avail.
I've written many apps with SDL2 but this is the first time I'm using vcpkg to locate it.
It appears to be a deliberate decision made by those who created the package.
If you look at the package description file, you can see that SDL2main.lib is being moved into the manual-link directory. I'm not familiar with vcpkg, so I don't know how exactly you can "manually link" against it, but I assume it's possible.
Linking SDL2 manual-link libraries while using vcpkg with VS
My answer is a follow-up to #HolyBlackCat, thanks for help.
In your case, the directory is x64-windows, by default it is x86-windows.
Right-click on your project -> Properties -> Configuration Properties
First step
Go to: VC++ Directories -> Library Directories
For Debug configuration, add:
$(VCPKG_ROOT)\installed\x64-windows\debug\lib\manual-link
For Release configuration, add:
$(VCPKG_ROOT)\installed\x64-windows\lib\manual-link
Second step
Go to: Linker -> Input -> Additional Dependencies
For Debug configuration, add:
SDL2maind.lib
For Release configuration, add:
SDL2main.lib
Now you should not be bother by "main() redefinition" errors.

Including library in command-line based buidling of QT Plugin

I would like to build the QT Opc Ua Plugin for QT 5.13.2 with the security patch for the Open62541 library.
So far I managed to install the mbedTLS library and it gets recognized in the qmake step prior to nmake. Nmake then runs into a problem:
mbedcrypto.lib(entropy_poll.obj) : error LNK2019: unresolved external symbol __imp__CryptAcquireContextA#20 referenced in function _mbedtls_platform_entropy_poll
As far as I understand the issue, this is because my linker? doesnt find the library in which those functions are located, which would be advApi32.lib
Although there are many tutorials as to how to include this library with Visual Studio or with Qt Creator, i need to do this from the command line (or by manipulating dome files in the QtOpcUa directory), how would this be possible ?
I already tried adding LIBS += -ladvAPI32 to all the .pro files I could find, but it did not help at all.
I fixed it by adding AdvAPI32.lib to the win32: part of the open62541.pri file. I don't know why it's expected at this place, but I'm happy it works now.
This seems like a path issue. In the qtopcua.pro file, you can try adding the absolute path of the advapi32 library using 'LIBS +=' option and then run qmake.

Error building tensorflow C++ shared library on windows

I am trying to build tensorflow as a standalone project and have been following this tutorial
http://www.stefanseibert.com/2017/10/tensorflow-as-dll-into-your-windows-c-project-with-gpu-support-and-cmake-v1-3/
but alternatively with cpu support
My environment setup versions
protobuf 3.6.1
tensorflow 1.10.0
tf.GIT_VERSION = b'v1.10.0-rc1-19-g656e7a2b34'
Here are the steps I used to generate the shared lib
Acquired source code from https://github.com/tensorflow/tensorflow.git
Have installed the dependencies since I do not use the python bindings, there is no need for SWIG, so I installed Git (version 2.15.1.windows.2) and cmake 3.11.1
I used the 64bit tools from Visual Studio 2015 since VS2015 is necessary to build the DLL. I should be able to open the “VS2015 x64 Native Tools Command Prompt”. This is needed so VS uses the 64 bit toolset.
Navigated in the commandline to the “tensorflow/contrib/cmake” subfolder of the source code and create a directory with “mkdir build”. Afterwards navigate to the fresh build folder with “cd build”.
Create a build solution: cmake .. -A x64 -DCMAKE_BUILD_TYPE=RelWithDebInfo -Dtensorflow_BUILD_CC_EXAMPLE=OFF -Dtensorflow_ENABLE_GRPC_SUPPORT=OFF -Dtensorflow_BUILD_CC_TESTS=OFF -Dtensorflow_BUILD_PYTHON_TESTS=OFF -Dtensorflow_ENABLE_GPU=OFF -Dtensorflow_WIN_CPU_SIMD_OPTIONS=/arch:AVX -Dtensorflow_BUILD_SHARED_LIB=ON
Everything went fine till this. To build the tensorflow.dll, I issued the following command: MSBuild /p:Configuration=RelWithDebInfo tensorflow.vcxproj
This throws an error: D:\work\tensorflow\tensorflow/core/lib/core/stringpiece.h(34): fatal error C1083: Cannot open include file: 'absl/strings/string_view.h': No such file or directory (
compiling source file D:\work\tensorflow\tensorflow\core\lib\core\coding.cc) [D:\work\tensorflow\tensorflow\contrib\cmake\build\tf_core_lib.vcxproj].
I fixed the above error with this: https://github.com/tensorflow/tensorflow/issues/22007#issuecomment-424553600.
Doing the above I ended up with this error: path.obj : error LNK2019: unresolved external symbol "void __cdecl absl::base_internal::ThrowStdOutOfRange(char const *)" (?ThrowStdOutOfRange#base_internal#absl##YA
XPEBD#Z) referenced in function "class std::basic_string,class std::allocator > __cdecl tensorflow::io::internal::JoinPathIm
I am not able to proceed further. Any workaround for this? Thanks!
lnk2019 error occurs when your directly you are using in your source code are not linked properly. Please add additional dependencies to your project.
Going to project properties
select C/C++ option
Add aditional dependencies
Go to Linker Option Below C/C++
Add additional Dependencies here.
It might be help full for you from getting out to LNK2019 problem
view this to understand LNK2019 error.
I met same issue, I think tensorflow new version doesn't support CMake, but we can solve the issues.
1. Seems the absl version in project folder is out dated, so I cloned the latest version of abseil-cpp from: https://github.com/abseil/abseil-cpp
2. Use cmake to build the abseil-cpp, it will be fast.
3. Add lib path to tensorflow dependency, the needed one will be D:\git\abseil-cpp\abseil-cpp\build\absl\base\Release\absl_absl_throw_delegate.lib
4. If you meet other linking error, you can find the function name in absl sources and find the library contain it.
Hope this can help you and people who may met this issue in future.

link error on examples, when trying to compiling VTK to use static run time library

I want to compile VTK so it uses static run time library ( /Mt and /MTd in visual studio) instead of dynamic run time library (/Md and /MDd) in visual studio.
to do this, I changed the CmakeLists files that come with VTK and add these lines to it:
if (MSVC)
set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} /MT" )
set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} /MTd" )
endif (MSVC)
when I tried to build the samples, I am getting this linker errors:
Error 101 error LNK2005: "private: __cdecl type_info::type_info(class type_info const &)" (??0type_info##AEAA#AEBV0##Z) already defined in LIBCMTD.lib(typinfo.obj) C:\Local\VTK-6.2.0\build\Examples\Tutorial\Step3\Cxx\MSVCRTD.lib(ti_inst.obj) Cone3
if I remove the part that I added to cmakelists, it compiles and runs all examples.
As my application already uses static libraries, I need to make sure that VTK also uses static library.
How can I fix this problem?
The direct approach would be to ignore-default-library MSVCRTD.lib - but I would advise on understanding the issue before stomping it like that.
You can build with /VERBOSE, search the output for MSVCRTD.lib and arrive at the first location that loads it. Potentially it is a 3rd party lib used by the example, or a different project you had to switch.