How to to build C++ code into both .so and .dll - c++

I am trying to find a way where I can build C/C++ code into both .dll and .so when needed. Either through Visual Studio, CMake or any other tool. I need to also need to reference third party libraries depending on which extension I'm building.
I have tried looking into CMake but it seems to build the respective extension type to your Operating System, so since I'm using Windows it seems to only build .dll and not .so.
I don't think Visual Studio can switch easily between the two especially referencing the third party .dll or .so respectively. I haven't looked at Eclipse yet.
What I am trying to do is to build a C/C++ library to be used on Android phones (which uses .so files) but I would like to test my C/C++ code my Windows PC as a sort of unit test before deploying onto the phone.
Any suggestions?

Related

Cross Compiling with Cmake. What should I expect from cross compiling

I also want the code I developed for Linux to work on Windows. I wrote simple Hello world code for this. I was able to create the .exe file with minGW using Cmake. When I run the .exe file directly on Windows, I got the error "libstdc++-6.dll not found" even though it exists on my computer. When I deleted the contents of the /build folder in Windows and built it with Cmake, the newly created .exe file worked. When I compile directly with minGW without using Cmake, the .exe worked without problems.
Is it a mistake to transfer the .exe file with its source codes to the Windows environment and expect it to work directly? I want to understand the logic of this concept properly.
If you use libraries that are not part of Windows itself, you will generally need to distribute the DLLs for those libraries in the same directory as the EXE in order for your EXE to work on another computer.
Alternatively, many cross-compilers support a -static argument that you can pass at link time in order to statically link these libraries into your executable. I favor that approach, but the licensing requirements for it are stricter.
(Make sure you follow the license terms for any software you redistribute that isn't your own, open source or otherwise.)

Statically linking Visual Studio dlls to dynamically linked sfml project

I have an SFML, Visual Studio project that needs to be linked using the /MT option in the runtime library settings because I want to avoid having to install the microsoft redistributable to every computer that runs the program.
When I added sfml to the project, it appeared to work fine in its dynamic form. However, when I tried the program on another computer, it told me that I had missing visual studio dlls.
I understand that in order to link sfml statically to the project I would have to rebuild it with different runtime libraries. My question is why would it be able to correctly compile with sfml dynamically linked to the project and have the project set to /MT at the same time if it failed to statically link the necessary visual studio dlls to the project?
After discussions in the comments, we agreed on this:
It is not uncommon to link some libraries statically and still link dynamically to others, like the language runtime. So the compiler should not complain about this.
To get a single executable containing everything, the program must link all libraries statically and they must, in turn, also link statically to all their dependencies.
Otherwise, if we have one dynamic library, like SFML, that library will likely in turn link dynamically to the runtime library. And that will still require the runtime DLLs.
This is possible, you'll just have to build SFML yourself (which isn't that hard to do).
Just make sure that you set the CMake variable SFML_USE_STATIC_STD_LIBS to TRUE so SFML uses the static runtime, no matter whether you're actually creating static or shared libraries.
In short:
Clone the official repository.
Install CMake. (If you're using Visual Studio 2017, you can also directly open the source directory as a Folder, but setting the variables is a bit more tricky this way.)
Create a build directory, go there and run CMake: cmake -DSFML_USE_STATIC_STD_LIBS=TRUE -DCMAKE_INSTALL_PREFIX=C:/path/where/to/install/SFML C:/path/to/the/cloned/source/repository
Once done you'll find a Visual Studio solution and projects.
Just build the INSTALL project for the Debug/Release targets and you'll get your shared SFML using the static runtime.

How to link opencv and other dll files to output exe of visual studio 2013

I am new with visual studio, opencv.
I am using visual studio 2013, opencv and c++ for my project.
I configured (copied path) the opencv and other library to my computer environment system.
After run the project in visual studio, normally, there will be an exe file in the project.
I can copy the exe file in the project folder and copy to other place in my computer and it will run normally.
This is because my computer environment systems are configured with opencv and other library.
I want to do the same thing with other computers BUT I do not want to manually configure each computer with opencv and other libraries.
Are there any ways that I can do to link everythings all in exe file after run the project in visual studio 2013 so that I can run the exe without depend on the path of libaries and opencv?
EDITED
I use opencv installer opencv2.4.7.exe
In the current VS2013 my project, i configured my project and opencv installer as this link
http://www.anlak.com/using-opencv-2-4-x-with-visual-studio-2010-tutorial/
question : Can i use the library in folder C:\opencv\build\x64\vc11\staticlib come from the opencv installer no need create my own library from source opencv?
question : In case i need to generate new library from opencv source (http://docs.opencv.org/doc/tutorials/introduction/windows_install/windows_install.html) or use lib in static folder of opencv installer, if i want to include it all to exe files, do i need to create new project and reconfigure?
Thank you.
First you need to rebuild openCV to generate static libraries instead of dynamically linked ones. This way all code that your application uses is thrown together in one single exe-file (which will probably be significantly bigger). This exe-file you can move to other computers and they should still work there, provided they have an architecture that is at least compatible with yours. So if you build it on an x86 perconal computer (32-bit), it should basically work on any other personal computer. If you build it on a x64 computer (AMD 64-bit), it will only run on other x64 machines. At least this is true assuming both systems use the same syscall API (Windows NT, POSIX...).
For openCV you do this by setting the BUILD_SHARED_LIBS build flag to false (see OpenCV as a static library (cmake options), the following line is taken from there):
cmake -DBUILD_SHARED_LIBS=OFF ..
Once you have done this, you will see that the openCV folder looks very similar to the one you have now, except that in your 'lib' folder there will now be .lib-files instead of .dll files (at least if you are working on Windows, which I assume you do since you are using Visual Studio).
Next step is to go to your project settings and set your linker to link with the static libraries instead of the dynamically ones. If you have used openCV's local method for linking, you can go to project settings -> linker -> input -> Addtional dependencies. There you change the extension of all the openCV libraries from .dll to .lib.
Now you should be able to rebuild your application and the resulting exe-file should have all dependent libraries contained in it.

Should i use MinGW for C++/CMake project to minimize dependencies of MS's DLLs?

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).

Using a DLL with unmanaged code in Visual Studio 2010?

I'm fairly new to C++ and an trying to figure out to use the TagLib library for a project I am working on. I'm working with unmanaged C++ in Visual Studio 2010 on Windows 7 64bit. I've never used an external library before so I'm very confused on how to go about this.
From this blog entry I got the libtaglib.a and taglib.dll files. I ran across this SO question on how to use TagLib, but it deals with QT Creator, not Visual Studio and I'm not knowledgeable enough about the subject to understand what is being said to translate it into what needs done for Visual Studio.
So, some questions:
Is it even possible to do this with unmanaged code?
What exactly is the function of a .a file?
Most importantly, how do I go about using the taglib.dll in my program??
I've been all over Google looking for a way to do this, but my major problem is that everything I run across is over my head. Please let me know if more info is required. Any help is very much appreciated! Thanks!
I seem to have gotten it working successfully. Here's a rough outline of what I did:
1.) I used CMake to generate the Visual Studio solution.
2.) I attempted to build the tag project in the VS solution, but it failed.
3.) I made the corrections to a few source files as outlined here: http://old.nabble.com/taglib-fails-to-compile-with-MS-VC%2B%2B-2010-td29185593.html
4.) I built the tag project again in release mode. This time it was successful.
5.) I copied the resulting dll, def, and lib files to the same directory as the source files for my project.
6.) I copied the header files from the taglib source to a subdirectory in my project (not sure if this entirely good practice)
7.) In my project settings, I set the subdirectory with the header files as an additional include directory.
8.) I added the dll, exp, and lib files to my project by just going to Add>Existing Item.
9.) I added some code from the taglib examples and built it. Everything worked so I think I got it.
One caveat I ran into, since the DLL was built in release mode, my project had to be run in release mode or it would crash. I'm guessing that if I replaced the DLL with one built in debug mode I could run my program in debug mode, but I have not tried this.
You cannot use libraries specific to GCC (you can tell because they have .a extensions) with Visual Studio. You will have to build the library from source in order to use it with MSVC. Once you have done that it's a simple matter of adding the .lib generated from the build process to your project and things should work out of the box. (Note that it's a .lib you need whether you're compiling for dynamic linking or not -- doesn't matter in msvc land)
EDIT -- after looking at TagLib itself --
In order to compile TagLib you'll need to get the CMake build system, and TagLib itself, and have CMake build you a visual studio solution. Using that solution you'll be able to build the .libs and .dlls you need. Note that because TagLib is a KDE library, you'll probably need to also build some QT bits in order for everything work work successfully. However, I don't have specific experience with the library so I'm not going to be all that helpful here.
Yo do not have to recompile the source (to create the .lib file) if you have the .dll file. With dumpbin /exports and lib (both came with Visual Studio) yo can create a lib that you can link with your application. In this link you can see a nice explanation: http://www.coderetard.com/2009/01/21/generate-a-lib-from-a-dll-with-visual-studio/
But as Billy Said, probably you would need other parts of QT to use this library.