Problem:
I would use a MinGW library in Visual Studio project.
How my system is built:
I downloaded ZBar library for my Windows 10 system ( zbar-0.23.91-win_x86_64-DShow.zip
This is the link: https://linuxtv.org/downloads/zbar/binaries/).
I have these files in the folder of lib and bin:
libzbar.a
libzbar.dll.a
libzbar.la
libzbar-0.dll
Error when build:
error LNK2019: unresolved external symbol __mingw_vsnprintf referenced in snprintf
My question
Do libraries compiled with MinGW work with MSVC?
No, libraries compiled on MinGW can't be used with MSVC. The main reasons are:
Lack of ABI compatibility. That is to say that in binary, the way things can be laid out are different depending on the compiler.
Difference in how the standard library is implemented. The standard library can be implemented in many ways. The C++ Standard just says how functions should behave and does not force compiler developers to implement them in the same way.
In general, things compiled with one compiler aren't compatible with another compiler.
The problem is that the libraries have been compiled with mingw while I need to compile them in an mscv project.
The solution was to rebuild the library with Visual Studio.
It was possible to use everything without problems.
You can use C-lion because It has direct support of MinGW.
A sample tutorial for how to select MinGW as a toolchain in C-lion is given in this link.
https://www.jetbrains.com/help/clion/how-to-create-toolchain-in-clion.html#custom-targets-toolchain
Using this you will have direct access to all the libraries available for MinGW directly.
No it can't. A library compiled with MinGW will only work with MinGW. You need to compile it from source code with MSVC.
I haven't used windows much and hardly used visual studio. But you can use MinGW on visual studio ide if you want.
Using MinGW with Visual Studio IDE
Related
I'm doing some experiments with Mingw-w64 and it works great compiling regular C code, linking to the Windows system MSVCRT.DLL C library. But, if I compile C++ code, then mingw's g++ links to what looks like the GNU libstdc++ library. Why? This doesn't happen with regular C binaries. I see commerical Windows software all the time including the Microsoft "C++ redist" package, which I guess matches the version of Visual C++ they use to develop their software. So it seems like there's actually no C++ library by default on Windows. I'd like to use the "system" C++ library and not use the GNU one if possible to reduce the size of the binaries mingw is compiling. But, I also don't want a separate C++ redistributable that needs to be installed. Am I stuck with the GNU library?
MinGW/MinGW-w64 build do use system standard libraries, that are part of Windows.
Visual C++ redistributable and runtime packages are only needed when sources are compiled with MSVC.
If your MinGW/MinGW-w64 build isn't statically linked you may need to ship libstd DLL files, but you can just put them in the same place as your .exe and/or .dll files, along with any other dependancy .dll files.
I actually love the fact that MinGW/MinGW-w64 builds don't need Visual C++ redistributable for several reasons:
The user doesn't need to install yet another Visual C++ redistributable.
The binaries are compact and don't depend on other Microsoft libraries except the ones in the operating system, which increases the chance of your software running well on different Windows versions.
Install (and uninstall) instructions (or installer code) are easier as the Visual C++ redistributable dependancy doesn't need to be installed. In fact you can even run your software as a portable app without installer.
I need to integrate the Intel RealSense C++ library (legacy 2016 R3 not the current 2.0 SDK) to an already existing application built with Qt MinGW g++ 32-bit (installed by Qt5.11 offline installer)
basically, they provide the headers and some .lib files to compile and link applications
when I try to compile the Segmentation example in Visual Studio, they work, (they provide a .props file that I can add to the Visual Studio Solution's Project's Property Manager, btw, I am using Visual Studio Community 2017 on Windows 10 Home 64-bit), but, the application I am developing was made using QtCreator so I need to be able to compile with QtCreator, and migrating the build to Visual Studio might not be a viable solution
if I try to compile the Segmentation example with MinGW (32-bit) in QtCreator (installed by Qt5.11 offline installer) I get error messages like this one
C:\src\Debug\app\main.cpp:34: error: undefined reference to `UtilCmdLine::UtilCmdLine(Intel::RealSense::Session*, int)'
and even if I try to use MSVC (64-bit) in QtCreator (installed by Qt5.11 offline installer) (which is not really a great option)
I get error messages like this one
C:\src\Debug\app\main.cpp.obj:-1: error: LNK2019: unresolved external symbol PXCSession_CreateFromPath referenced in function "public: static class Intel::RealSense::SenseManager * __cdecl Intel::RealSense::SenseManager::CreateInstance(wchar_t const *)" (?CreateInstance#SenseManager#RealSense#Intel##SAPEAV123#PEB_W#Z)
for several symbols
has anyone solved a similar problem?
MinGW I think I understand not working, because of MSVC symbol mangling and a general different ABI, and because the tools to work with .lib files in MinGW are no longer being available (at least not in the official website), but why is MSVC not working? am I missing something that Visual Studio has that QtCreator does not?
would there be a way to make something like a wrapper library in visual studio so that I can use in MinGW? I saw some people who had similar problems with .lib files being told to use a COM style interface if they could
I saw that being the
just to clarify, I'm not sure if it's a problem introduced by the Qt libraries but there is some of the application's code just doesn't compile correctly with MSVC, so for now, I'd prefer a way to compile with MinGW in QtCreator, though we might eventually get it to work with both compilers (or at least try to)
I have made a sudoku solver using SDL (for GUI) on VCpp 2010 IDE.
The program compiles without errors and runs fine. However, i cannot pass the compiled executable on to some people because they don't have msvc dll on their pc.
I thought i could use devc++ that compiles with GCC but this IDE is kinda buggy and just won't let me include some header files.I also have some problems setting up SDL expansions.
So, is there a way to change VisualStudio compiler to GCC?
I really need to stay with VS because it is easy to use and there is a lot of online support.
Short answer: no, you cannot change cl.exe (MS cc compiler) with gcc. Or mingw. (You can with a compatible compiler, like Intel C compiler)
Long answer: you don't need to to that. Use the static linked runtime library, and you don't have a dependency ms dlls anymore (see this answer: How do I make a fully statically linked .exe with Visual Studio Express 2005?)
Or redistribute the VC++ runtime with your app. It's free (http://www.microsoft.com/en-us/download/details.aspx?id=26999)
You don't need to change compiler - they need to download the Visual Studio 2010 redistributable:
http://www.microsoft.com/en-gb/download/details.aspx?id=5555
In short: no. You can't simply use the GCC compiler in Visual Studio.
The long version: you can use a Makefile project to run GCC, but then you lose some of the benefits of using Visual Studio.
I'm not sure when this became a feature in Visual Studio (probably wasn't one in 2013), but it is now possible to change the "Platform Toolset" - and thus the compiler - used by Visual Studio to other compilers like Clang/LLVM and GCC. I have been happily using Clang with VS2017 ever since the MSVC++ compiler bugged up with some 3rd party libraries.
Microsoft made a blog post on the installation instructions and how to switch.
Is it possible to compile the sourcecode from ffmpeg in visual studio 2010? Is it difficult?
Just looking for some advice (and instructions) if possible. :-)
Cheers,
Pete
Apparently someone at Google has written a C99 to C89 "downconverter" in part to get ffmpeg to compile with Visual Studio:
http://blogs.gnome.org/rbultje/2012/09/27/microsoft-visual-studio-support-in-ffmpeg-and-libav/
The tool they wrote is currently only in source code form. Although that tool is written in C, it uses some compiler specific includes, specific to the Clang compiler, so you currently need clang to compile it. I had to get all the pieces to Clang (which relies on llvm) and compile with VS2010. OK, got that figured out, so now I have the two tools compiled: c99wrap.exe and c99conv.exe.
The blog does not mention two important things that are mentioned here:
http://libav.org/platform.html#Microsoft-Visual-C_002b_002b
First, you have to ensure the link.exe you use is the Visual C linker and not the mingw linker. Also, the msvc toolchain under msys does not yet support shared DLL builds, it only supports static lib builds at this time, so --enabled-shared fails to link.
It is not possible because ffmpeg makes extensive use of C99 features (with good reason), and MSVC doesn't support nearly enough nook and crannies of the standard.
You can however, use the C library built by MinGW for use with Visual Studio projects. See the following links for all the information you need:
Information about building/using the library on Windows with Visual Studio: http://ffmpeg.arrozcru.org/wiki/index.php?title=Main_Page
Downloads: http://ffmpeg.arrozcru.org/autobuilds/
Of course it is possible
To use FFmpeg SVN libraries with your Microsoft Visual C++ project,
you must first make sure your Microsoft Visual C++ build system has
the inttypes.h and stdint.h include files.
How do I know if I have those files? Well... unless you already did
this and know you have that file, you don't have it. MSVC++ does not
adhere to the C99 standard, where that file is specified, so you're on
your own here.
Alexander Chemeris was nice enough to make such files for Microsoft
Visual C++, so they can be found here
Download latest archive from link above and unpack it to the folder to
which you installed FFmpeg's include files. The default path is
/usr/local/include, which is, in this guide for Windows,
C:\msys\local\include.
Inttypes C99
Visual Studio 2013 provides the support for C99 which was missing earlier. With this ffmpeg can now be built using Visual Studio 2013. You can read more about the new language/libraries features here.
Also, try out Visual Studio 2013 RC here.
According to the documentation it is not possible.
I need to modify the C runtime which ships with VS2010 because the 2010 CRT relies on functions released in Windows XP SP2, and I need to be able to deploy to Windows 2000.
Specifically, I need to remove any and all calls to EncodePointer and DecodePointer.
The source for the C runtime is included in C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\crt\src, so it seems like it should be possible to build the runtime after slightly modifying the source.
Oh, I don't need to be able to build the dynamic versions of the runtime -- static versions only. (I cannot rely on the user installing the CRT on their system either).
With VS2008 and earlier, there was a tutorial in MSDN describing how to build the CRT, but I can't seem to find it for 2010.
Is such a thing possible?
Here's an MSDN link. It looks like you have to do it yourself in VS2010.
You can use the following compiler and linker options to rebuild the MFC, CRT, and ATL libraries. Starting in Visual C++ 2010, scripts for rebuilding these libraries are no longer shipped.
If it is a option, I would consider using the VC++ 2008 toolset within VS2010 instead of building a custom CRT. The procedure is explained here.
"Oh, I don't need to be able to build the dynamic versions of the runtime -- static versions only."
Since you only need static linking, you can try this trick to provide implementations of EncodePointer and DecodePointer.