My question is as the topic.
I am currently using Mingw32 compiler in Qt creator to compile my application. The problem is that I include a .lib static library and header file which compiled from Visual Studio 2017 in my application.
When I further run or compiled my application in Qt. I would be facing the error code, unrecognized file format pointing to the .lib file.
I reasonably doubt that: For example, I can not use compiler 1 to compile other libraries compiled from compiler 2.
I follow the instruction here:libwdi Installation and Compilation to compile the "libwdi.lib" file.
FYI, the reason that I use Visual Studio to compile the .lib library(libWdi) is because it's easier to achieve on my Windows OS after I tried using wingw32-make from Qt5 Tool. It is such a pain since I can not even run ./autogen.sh to generate the makefile for Mingw32 on Windows.
Appreciate any step-by-step information on how to build a workable .lib file for Qt creator, including using VS, mingw, and cross-compilers.
If the target library uses c++ features in its public interface then it is likely this is not going to work regardless of what machinations you go through. Even different versions of the same compiler often have problems in that situation.
Pure C on the other hand will usually work (on Windows non-MS tool sets will be made to at least consume the MS intermediate object format, even if not used by the compiler/linker normally).
Related
I hope to use windows COM components in GO, such as IFileDialog, IFileSaveDialog, IFileOpenDialog.
I have tried the following ways:
Use the vc++ compiler to compile the code and generate the .lib static library file. However, because GO uses the GCC compiler as a call bridge for the C language, and the .lib file generated by the VC++ compiler, GCC cannot be linked. fail.
Use the vc++ compiler to generate .dll files, and dynamically load the .dll files through the LoadLibray and GetProcAddress functions in windows.h. fail. The syscall.LoadLibray and syscall.GetProcAddress functions of the GO language have the same result. They run well for the .dll files generated by the GCC compiler, but they all fail for the .dll files generated by the VC++ compiler.
Use the GCC compiler to compile the code, because MinGW lacks the latest Windows com SDK, such as IID_IFileOpenDialog. fail.
I'm trying to link to the OpenAL soft library as compiled with the Media Autobuild Suite, and I'm getting the following error from Visual Studio:
libopenal.a(source.cpp.o) : fatal error LNK1143: invalid or corrupt file: no symbol for COMDAT section 0xA
My application is in C++ and compiled directly in Visual Studio 2019 (however, with the VS2017 toolset). OpenAL soft is written in C++ but exposes a C interface, and the MAB Suite compiles using MinGW/gcc and generates a libopenal.a static library file.
I've read from multiple other questions such as From MinGW static library (.a) to Visual Studio static library (.lib) and How to use libraries compiled with MingW in MSVC? that object files compiled with different compilers are generally not compatible for C++ due to name mangling, but often are compatible with C linkage. Because C does not use name mangling, and because the ABI is (usually) OS-dependent, libraries with a C interface compiled on the same platform are generally compatible.
Nevertheless, I've been running into linker errors, namely the LNK1143 above. I've confirmed that the included headers use extern "C" { to hint C linkage and that the target platform (x64) is the same for both builds. I also linked to libgcc.a as this answer recommends, and did not get any linker errors for it.
Does this mean the claim that C interfaces are generally compatible across compilers is not true? Or is this a special case in which it's not working? If the latter, what could be causing the linking to fail? Would I have better luck if I recompiled as shared libraries (dlls) instead of static libraries (even if I still use MinGW's .a files instead of .lib)?
I cannot change compilers from MSVC for my main app. I intend to use more libraries from the MAB Suite in the future, so I'd prefer to stay with MinGW for those dependencies if possible because I don't want to recompile all 70+ by hand.
Any help is appreciated. Thanks in advance.
Mixing compilers is tricky and prone to issues.
In some very simple cases it may work, but there are definitely a number of cases where you will run in to issues, for example:
if the different components use different runtime libraries
if memory management is being mixed (e.g. forget about freeing memory allocated with malloc() in MSVC using free() in MinGW)
when using exception handling in C++
My advice to do it all with the same compiler (and even the same version of this compiler).
Specifically in your case OpenAL can be built with MinGW-w64. So maybe you should look into that instead of downloading some prebuilt version from the web.
Or - somewhat easier - use MSYS2 and use its pacman package manager to get its own MinGW-w64 build of OpenAL.
I figured out what works for me, so I'll share.
I was not able to link a static library between compilers as I originally attempted. My understanding is that the extra info kept in the lib to allow link-time code generation is compiler-specific. Brecht Sanders's answer outlines a few possible reasons why the code wouldn't be compatible.
I was, however, able to link to a shared library, with a few extra steps.
Using the same suite (see the question), I compiled as shared and got libopenal.dll, libopenal.dll.a, and libopenal.def. In my case, the .def file was generated by the suite. Accoding to this answer, you can generate a .def file with gcc using:
gcc -shared -o your_dll.dll your_dll_src.c -Wl,--output-def,your_dll.def
Trying to link to libopenal.dll.a still gave me errors (I don't know exactly why, and I already discarded the logs.) What I did instead was generate a .lib file from the .def file. In Visual Studio's built-in terminal:
lib /machine:x64 /def:libopenal.def
This generated a libopenal.lib file in the working directory. Linking to this file worked perfectly, and I was able to successfully load the dll at runtime.
I've tested this same method with many other MinGW-compiled libraries from the suite, including libavformat, libavcodec, libavutil, libavdevice, swresample, and swscale, and thus far all of them have worked.
Kind of convoluted, but it seems to work well for me, so I hope this helps anyone else with the same problem.
I make use of a vendor supplied library in a C++ program. All the vendor supplies is a .lib, .dll and the header files.
This library was first used in MSVC++ 6 and now in MSVC 2010.
It appears they support mingw, qt, etc. I have had no problems with using it in either debug or release mode.
I have recently added another dependency to the project, yaml-cpp, an open-source project that provides no binaries. I am able to build yaml-cpp using cmake and MSVC 2010 as a static library and can link it to my project successfully.
In order to do this I must link to the debug and release versions of the .lib respectively as I have run in to weird Microsoft CRT/linker issues I am just learning about.
I am curious, how does the vendor of my first library (libXl if you are curious) provide a .lib and .dll that works on a range of compilers without worrying about the CRT version?
How do you write code that allows this or is it the linking process? yaml-cpp is a cross platform library, is it possible for me to compile it in a similar way that would allow me to use a single .lib within my project?
I am not sure what resources to look for to learn more about it. How do people learn about this kind of stuff? Thanks!
The reason that a .lib and dll can work with a variety of compilers is down to ensuring that there are no compiler-specific dependencies in your code. .lib and .dll are not recompiled so once they are made they should be stand-alone if so coded, and their functionality can be accessed from anywhere with the ability to use a .dll or a .lib.
There is some discussion on the pros and cons of dll and lib here which you may find interesting.
Let me know if you need more info and I will do my best to oblige.
I want to know a programming language that doesn't require a runtime/dependency to be installed on the target system. My primary target is Windows XP and above.
I tried Autohotkey but it dosent have many advance functions.
Firstly, please confirm that does 'C++' requires to install a runtime/dependency on the target system is is Win XP or later. Secondly, please suggest me an alternative to C++ that doesnt require a dependency to be installed.
UPDATE: I will be using CodeBlocks! Does the C++ code compiled with that requires a dependency?
UPDATE: Sorry for the misconception, by CodeBlocks I mean the default compiler of CodeBlocks (ie: GNU GCC Compiler or MinGW).
Everything usually depends on the project, not the language. For example, programs compiled in Visual Studio's C++ uses some runtime libraries to work properly. However, you can configure the project in such way, that these libraries are included in the executable file, thus not needing additional dependencies. Delphi works similarly.
Here's the setting for Visual Studio Project:
If you choose option with "DLL", your program will require runtime DLLs. Otherwise it will be standalone, the runtimes will be incorporated into your binary file.
Edit: In response to question edit
I'll repeat myself: it depends on project, not the compiler or IDE.
If you want to create a program that does not require anything else in order to run, except for base operating system (no .NET, no Java, no Perl, no runtime libraries, etc), then your best bet is to use C or C++ and compile your program as single statically compiled executable.
It is rather difficult to achieve in practice, but it can be done.
Codeblocks is not a compiler, but an IDE, that can use different compilers.
The most common one is MinGW.
To complie with minGW so that all the standard libraries are statically linked you shold configure your project (see "project settings") so the the linker options include the -static flag.
You can even be more specific by stecifying
-static-libgcc
-static-libstdc++
How do you port C++ programs with makefile made from GNU C++ in Linux to Visual C++?
One thing I can suggest is to use CMake. If you implement your build system with CMake to auto-generate the makefiles for GCC on Linux, it takes only minor modifications to auto-generate projects and solutions for VC++.
Of course, this means learning a whole new build tool, so it may not be for you. It's only a suggestion.
I don't know about an easy way to simply convert from one to another, but..
Assuming you use only ANSI C/C++ features, usually you don't need to convert the makefile, just look which .c/.cpp files are in it and add them to the VS project; you'll also have to check about compiler options and defined macros, to put them inside the VS project. I've done this to compile libs like expat, freetype, agg and others, without problems.
Porting the build system: You could use a Windows port of GNU make, and change the makefile to invoke the Visual C++ command line tools (cl.exe, link.exe, lib.exe, etc.) when building on Windows and the GNU compiler tools when building on Linux. The difficulty of this approach depends on the complexity of the makefiles.
Porting the code: This depends on what APIs and libraries you are using, and what compiler warnings/errors/quirks you will encounter. For a more specific answer, ask a more specific question.
CMake was mentioned. I have used CMake and successfully compiled the resulting Visual Studio project. I found the CMake documentation very unhelpful -- I had to ask an existing user -- and the official manual (which costs money) was out of print at the time. Further, the Visual Studio project it produced was very rigidly formatted according the template preferred by whoever wrote the converter. I was unable to figure out how to customize project options or group source files.
I regularly cross-compile on Visual Studio and G++. For the most part, you just need to add all of the source files and header files into a Visual Studio project ('Add Existing Files', and add your entire source tree) and then compile it. Usually you'll get errors, so you start fixing bugs from there. If you used platform-specific libraries, you may be stuck porting to an alternative or removing features.
One further word of caution: Visual Studio and G++ have different compiler quirks. For the most part, they both conform excellently to the C++ standard, but slightly off-standard code which works in one may not work in the other. I have found this to be particularly true when dealing with templates, with Visual Studio being bizarrely permissive of syntax errors in many cases.
CMake has the nicety of generating visual studio project.
If you do not need that, I suggest Meson build system. Much nicer, similar proposal. Requires python3 and ninja, but noone is perfect. :)