I complied boost library by using vc 12 but my visual studio has vc 11. when I try to run boost sample program which is used boost (c++ library ) visual studio 2013 shows cannot open file 'libboost_regex-vc110-mt-gd-1_54.lib my libray path -(..\boost_1_54_0 2\stage\lib) im having libboost_regex-vc120-mt-gd-1_54 . think that issue I can solve by changing visual studio complier vc11 to vc12. how do I do that please help me.
Unless there is compiler or OS related dependency, you can solve it by linking with appropriate library. Check the setting of your project. Where, it was expecting vc110 library, change it to corresponding vc120 library.
If it does not work (because of some other issues like compiler specific problem, platform specific problem, or duplicate symbols as it was linked with different C runtime library), you can try the following:
Rebuild boost but with dynamic CRT library (instead of static library) (check /MD or /MT option). In this way, you need not to change either of compiler.
If nothing works, build both application and library using same compiler.
Related
I am attempting to use Hunspell DLL in C++ Builder but have nothing but troubles.
So I try to resort to compiling as static library. But even that doesn't go smooth. The steps I did so far:
downloaded the latest Hunspell from https://github.com/hunspell/hunspell/releases
unzipped and created in C++ Builder - New / Other / Static Library
right clicked and added all *.cxx files from src/hunspell folder
Clicked Build
The error which comes up is:
[BCC32 Error] cwchar(33): E2141 Declaration syntax error
cwchar is a file which is part of C++ Builder and not Hunspell as it seems (which only includes it).
Any help in building static hunspell lib (or even DLL) from C++ Builder appreciated.
Thanks in advance!
Edit: I was able to progress further by using more recent C++ Builder Berlin (the above error was in 2010 version) but it still reported linker errors, so I ended up using the DLL - see the answer.
As Remy Lebeau and Rudy Velthuis pointed out it turned out to be easier to use DLL instead. I've also discovered a few more tricks along the way which I will describe below.
1) when trying to create static lib file using C++ Builder (Berlin), it turned out that the current hunspell-1.6.2.zip is not compiling without errors. However, the hunspell-master.zip which is a clone of the SVN master, it at least compiled, although there were some linker errors - but I figured that master version is better to use as a base for building the DLL. So I used the current master version (https://github.com/hunspell/hunspell).
2) used Visual Studio 2015 Community to build the DLL - libhunspell.dll. To avoid dependencies, I used the /MT option in the compiler. I had many problems using the version of the DLL which was dependent on VC++ 2015 Redistributable ("Access Violation" errors immediately after calling some DLL functions), so statically linking the Redistributable to remove the dependency, all of these problems magically disappeared. Even though the compiler reported some warnings which is probably another question, it did manage to build the DLL.
3) created import library using implib -a -c -f libhunspell.lib libhunspell.dll
4) finally, linked to the .cpp file using #pragma comment(lib, "libhunspell.lib") (for older RAD Studio versions) or #pragma comment(lib, "libhunspell") for newer RAD Studio versions which support 64bit compiler). Another option is to add the lib to the project instead of the #pragma statement.
I am using Visual Studio 2013 to develop c++ static libraries *.lib. I got a request to compile the library using Visual Studio 2010 compiler, however I do not have it installed on the developer machine.
When compiling dynamic library *.dll it is possible to use switch /MT that will pack the C runtime into dll. The dynamic library thus becomes larger. However, when I use the /MT switch the static library becomes smaller (5MB -> 4.9MB) which is against what I would expect.
Question:
1. Can I build static library in Visual Studio 2013, so that it can be later used by Visual Studio 2010 compiler?
2. Is the /MT switch the right way to do it?
Static libraries are in general only compatible with the toolset that built them. This is especially true of any use of the Standard C++ Library / STL, which is why newer versions of VS have the _MSC_VER stamp embedded for any use of the STL headers that will generate link-time errors if you attempt to mix them.
It is also important that static libraries be built with the same CRT settings (/MT, /MD, /MTd, /MDd) as the project that is consuming them.
DLLs using C or COM exports using the CRT DLL are really the only 'stable' library that can be mixed with different versions of the compiler safely.
Otherwise, you should obtain the toolset for every version you want to support and build all desired flavors of the .lib.
c++, windows (in my case windows phone 8, arm & x86 for emulator). I've compiled boost libraries with mingw. as a result I have such files for ex "libboost_random-mgw48-mt-sd-1_53.a".
Is there any possibility to include this static library in visual studio c++ project? Maybe compile with special options... or convert this ".a" file to a visual studio compatible ".lib" file.
I've tried to rename .. but I receive some 'undefined reference' errors.. so they're not directly compatible.
please note that this library (boost) cannot be compiled with visual studio. I've an open question that still has no answer: https://stackoverflow.com/questions/23831050/compile-boost-as-static-library-for-windows-phone-8-arm
You can't use the g++ object files with visual c++. However, you can use all the header only modules of boost without building anything. For the rest, such as Boost filesystem, build it with visual c++ for use with visual c++.
Re
“please note that this library (boost) cannot be compiled with visual studio”
that's incorrect.
When i use Visual Studio, my executables depends on microsoft redistributable package - the package that deploys MS's runtime DLLs. That is annoying to me. What disatwantages my executable would have if i would use MinGW?
I also want to try link with lib- avcodec/avformat, that are built by MinGW and i have no my own mind power to build them in VS from src.
In case of using MinGW you will depend on DLLs that are shipped with mingw. It is not big deal to change one vendor to another.
If you already have MS project, review possibility to statically link MS libraries (it is option is provided for some of VisualStudio projects on creation time in project options)
You can link everything statically with MinGW. Use the -static linker flag.
No need for redistributing any DLL's, but you have to make sure that in the c++, there's no exceptions being passed over DLL boundaries (so make sure every C++ library is linked statically in this case).
I've downloaded and compiled an open-source C++ application, Frhed.
When I run the version I've compiled, it demands MSVCR100 and few other dll files (part of Visual C++ redistributable). However, when I run the original precompiled Frhed executable, it runs without any C++ redistributable package installed.
Do I have to modify any compilation options in order to unlink the program from the C++ redistributable libraries?
The original program is probably statically linked, whereas you are trying to dynamically link your executable, which results in a smaller file, but a dependency on functions inside MSVCR100.dll (v10 of the Microsoft C Runtime Library), which would have been included inside the executable if you were statically linking.
To statically link DLLs, go into your project properties and change the build mode from MD to MT. In Visual Studio 2010/2012, that project property is C/C++ -> Code Generation -> Runtime Library.
The short answer is yes, the longer answer is, well, longer.
The library msvcr100.dll is the 10.0 version (i.e., Visual Studio 2010 version) of the DLL implementation of the C run-time which you probably requested by using the /MD compile option. To avoid using the dynamically linked version of the run-time you can use the /MT option instead and statically link the run-time.
Alternatively, you can redistribute msvcr100.dll (and other files) along with your program.