I am dealing with the following setup:
A C++/CLI dll links to a static lib, which itself links against a static build of libboost_thread.
Without linking against libboost_thread the .exe, that loads the dll, runs fine.
I can even link to libboost_system and it still all runs fine.
At the very moment that I am linking against libboost_thread, the application always crashes with an access violation on startup before even entering any of my code.
This even happens if I am not including any boost header, I don't have to use anything from boost. Just linking against boosts threading library is enough to let the app crash.
I am using boost 1.53.0 and the prebuilt windows libs from http://boost.teeks99.com/ (especially libboost_thread-vc110-mt-gd-1_53.lib in both,the 32 and the 64bit version, tirggers this issue).
Any idea, what can cause that?
Related
I have read that incremental linking and non-incremental linking should be functionally equivalent, but I have recently found a situation where this is not the case, and it's kind of baffling me. It that out that my project's build is unable to explicitly load one DLL (out of many) that contains a wxWidgets GUI element during runtime without incremental linking (/INCREMENTAL) enabled.
To give a little context, I have the following targets built by my project:
main.exe
core.dll
foo.dll
bar.dll
core.dll contains general functions that are used by all other projects. main.exe is a desktop GUI application (using wxWidgets) that explicitly loads foo.dll and bar.dll at runtime via "LoadLibraryW". "GetProcAddress" is then used to request GUI elements from within the DLLs to be displayed, which is all done asynchronously via wxEvent. This has worked as intended for the most part. However, I have found that an issue arises when the main.exe is not incrementally linked.
Specifically, when main.exe is not linked with a core.dll that was linked with /INCREMENTAL, and when my project is implicitly linked to the release build of wxWidgets (which is not incrementally linked), foo.dll crashes at runtime on allocation of a new wxPropertyGrid, or wxPropertyGridManager (have tried both). The exception is thrown within "wxmsw30u_propgrid_vc_x64_custom.dll", which is clearly the property grid DLL. Since the debug version of wxWidgets is incrementally linked and does not crash, I was unable to get further information than this.
That is to say, when using the Release DLL version of wxWidgets, my project works if and only if a core.dll is linked with /INCREMENTAL and then linked into main.exe, regardless of whether or not main.exe is linked incrementally. foo.dll can be linked with a core.dll that was linked with /INCREMENTAL:NO and still be opened correctly by main.exe so long as that condition is satisfied. There are no problems with the Debug DLL version of wxWidgets, which is built with /INCREMENTAL.
That summarizes my specific problem. Since the actual code spans several files long, I've decided to reduce this question to the fundamental problem: how could incremental linking enable what I presume to be a faulty build to run successfully? I'd like some insight into this question in particular since it is truly baffling to me.
EDIT: Specifically, I am using wxWidgets-3.0.4 on Visual Studio 2019 targeting the latest Windows 10 SDK. The machine architecture is x64. I am building the project with CMake and have experienced no such issues on Linux when linking with g++-6.3.0 and using dllopen in place of LoadLibraryW.
Libraries built with Mingw-w64 require those dll:
libwinpthread-1.dll
libstdc++-6.dll
libgcc_s_seh-1.dll
I wonder what's up with that, what each dll does? Especially libgcc_s_seh, is that structured exception handling? I thought mingw couldn't work with seh.
Why mingw requires to always bring those dll with your exe?
I wonder if I'm just wasting my time by not just using visual studio as a windows compiler. It's so bloated though, 9 gb for installation.
Especially libgcc_s_seh, is that structured exception handling? I thought mingw couldn't work with seh.
Newer versions of GCC (4.8+ if I'm correct) should support SEH on MinGW.
I wonder what's up with that, what each dll does?
They provide the runtime and standard library.
libwinpthread: PThreads implementation on Windows (Threading)
libstdc++: C++ Standard Library (C/C++ library functions etc.)
libgcc_s_seh: Exception handling (SEH)
Why mingw requires to always bring those dll with your exe?
Because your program uses them. If you write a program without threads, standard library and exception and any OS interaction you wont need them.
These DLL's bring everything you need to run your program. Btw. this is not a MinGW only thing, and happens on other systems / compilers too. Often you just don't note this because the OS already ships the libraries, eg. MSVC libraries are very likely on a Windows machine. Dynamic linking always requires some sort of library files, that are .dll on Windows and .so on Linux.
If you have it available on your system use ldd <your application> to see what libraries are dynamically linked.
You can install these MinGW libraries into the system libraries or somewhere where the OS can find it. This enables your programs to use it and you no longer have to ship it with every application (what avoids duplication).
On the other side another option is to static link them. Unlike dynamic linking, you don't need any DLL; on the downside is a increase of you applications size (as now the three libraries are baked into the exe now).
I wonder if I'm just wasting my time by not just using visual studio as a windows compiler.
This depends on your situation. But probably my answer will give you some more insight.
My C++ (MFC) application is statically linked and loads a number of statically linked DLLs using LoadLibrary(). All had worked fine using VS2013 but since moving to VS2015 I have seen a number of strange _com_error exceptions being raised in a variety of locations.
In my test setup I have 56 DLLs being loaded and I see these exceptions. If I reduce this to 53 all seems to work fine.
I am assuming it is related to: Working around fls limitations with too many statically linked CRTs?
But what I am wondering is if something specific has changed from VS2013 to VS2015. I note a lot of work has been done on the CRT in this version of Visual Studio (https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/)
Note: I am compiling for Vista+ operating systems (_WIN32_WINNT_VISTA)
I can get things to work by recompiling the DLLs to use dynamic linking but was under the impression this is not a good idea if the main application is using static linking (I don't want to change this setting).
For a cross-platform software project that builds on Linux and Windows we have distinct ways to handle third-party libraries. On Linux we build and link against the versions distributed with the CentOS/RHEL distribution, which means we link against release builds, whereas on Windows we maintain our own third-party library "packages" and on Windows we build two versions of every library - a release version that links msvcr100 and msvcp100 and a debug version that links msvcr100d and msvcp100d.
My question is simply whether it is necessary to build the debug version of the third-party dependencies on Windows or can we simply use /nodefaultlib:msvcr100 when building debug builds of our own software.
A follow up question: Where can I learn about good practices in this regard. I've read the MSDN pages about the msvc runtime, but there is very little there in terms of recommendations.
EDIT:
Let me rephrase the question more concisely. With VS2010, what is the problem with using /nodefaultlib:msvcr100 to link an executable build with /MDd when linking with libraries that are compiled with /MD.
My motivation for this is to avoid to have to build both release and debug version of third party libraries that I use. Also I want my debug build to run faster.
From the document for /MD, /MT, /LD (Use Run-Time Library):
MD: Causes your application to use the multithread- and DLL-specific version of the run-time library. Defines _MT and _DLL and causes the compiler to place the library name MSVCRT.lib into the .obj file.
Applications compiled with this option are statically linked to MSVCRT.lib. This library provides a layer of code that allows the linker to resolve external references. The actual working code is contained in MSVCR100.DLL, which must be available at run time to applications linked with MSVCRT.lib
/MDd: Defines _DEBUG, _MT, and _DLL and causes your application to use the debug multithread- and DLL-specific version of the run-time library. It also causes the compiler to place the library name MSVCRTD.lib into the .obj file.
So there is no documentation for any difference done to the generated code other than _DEBUG being defined.
You only use the Debug build of the CRT to debug your app. It contains lots of asserts to help you catch mistakes in your code. You never ship the debug build of your project, always the Release build. Nor can you, the license forbids shipping msvcr100d.dll. So building your project correctly automatically avoids the dependency on the debug version of the CRT.
The /nodefaultlib linker option was intended to allow linking your program with a custom CRT implementation. Quite rare but some programmers care a lot about building small programs and the standard CRT isn't exactly small.
Some programmers use the /nodefaultlib has a hack around a link problem. Induced when they link code that was built with Debug configuration settings with code built with Release configuration settings. Or link code that has incompatible CRT choices, /MD vs /MT. This can work, no guarantee, but of course only sweeps the real problem under the floor mat.
So no, it is not the proper choice, fixing the core problem should be your goal. Ensure that all your .obj and .lib files are built with the same compiler options and you won't have this problem. If that means that you have to pester a library owner for a proper build then pester first, hack around it only when you've discovered that you don't want to have a dependency on that .lib anymore but don't yet have the time to find an alternative.
How does the Visual C++ program load dll's before entering the main function in visual studio express 2008? In a project developed by others a dll was loaded by "a.ext:native" but I don't know how is this configured.
There are different ways to instruct the OS to load a DLL. The most common way is to link to a .lib file (through the project's linker settings), where the .lib is a build-time stub associated with the DLL. When the linker finds this .lib file during the linking stage, it knows that the DLL is required, and modifies the EXE internally to tell the operating system that the DLL must exist in order for the program to run.
When the program is later run, the operating system first looks for all required DLL's - even before beginning to execute the code for the program. If any of these DLL's are missing, the operating system throws an error, an error box pops up, and the program will not run.
It's also possible to dynamically load a DLL, but this isn't all that common.