I am developing a C++ program which is using 6 different libraries (like Boost, OpenCV, Protobuf etc). I've compiled and installed all required libraries on my development PC. I want to export the program to work in another computer standalone. I can copy all the shared libraries to a folder and put the executable next to it but it will be really useful as my program's size would be enormous. Is it possible that MSVC++ exports all the shared libraries (and maybe the include files too) which are used in compilation?
Edit: Let me make clear the question.
I've libraries & header files all around in my PC (Like C:\boost\lib, D:\Workspace\opencv\lib etc..)
I don't use most of the libraries in these folders in my application.
I want to run my application at another computer.
I don't want to install all the libraries to the new computer.
I want only that MSVC export the required(used) shared libraries to another folder that I specify so I can copy only 1 folder containing only required libraries in it.
Is it possible?
Related
While exploring about the platform setup for OpenCASCADE, I came to know about WOK commands which arent needed for CMake build system to use with OpenCASCADE
However another option of genproj tool (for which I havent yet found any exe but DLLs..) to be used with MSVC+ in built compiler so that we dont need any gcc installation
Whats the difference between the twos and which one is better and easier??
Also suggest me how to download and install and setup genproj on windows
OCCT project provided the following build systems:
CMake. This is the main building system since OCCT 7.0.0.
It allows building OCCT for almost every supported target platform.
WOK. This was an in-house building system used by OCCT before 7.0.0 release.
The tool handled classes defined in CDL (CAS.CADE definition language) files (WOK generated C++ header files from CDL) and supported building in a distributed environment (e.g. local WOK setup builds only modified source files and reused unmodified binary / object files from local network). WOK support has been discontinued since OCCT 7.5.0 and unlikely will be able building up-to-date OCCT sources (although project structure remains compatible with WOK).
genproj. This is a Tcl script allowing to generate project for building OCCT using Visual Studio (2010+), Code::Blocks, XCode and Qt Creator. This script has been initially extracted from WOK package (where it was implemented as command wgenproj in it's shell) and now maintained independently from it.
qmake. Experimental adm/qmake solution can be opened directly from QtCreator without CMake plugin (the project files will be generated recursively by qmake). Although header files generation (filling in inc folder) still should be done using genproj (qmake scripting capabilities were found too limited for this staff).
genproj doesn't require any DLLs or EXE files - it comes with OCCT itself and requires Tcl interpreter. On Windows platform it can be executed with genconf.bat and genproj.bat batch scripts in the root of OCCT source code folder. At first launch it will ask to put a path to tclsh.exe.
While CMake is the main building tool for OCCT project, genproj remains maintained and used by (some) developers - mostly due to personal habits and hatred to CMake. They differences of genproj from CMake that could be considered as advantages in some cases:
Generated project files can be moved to another location / computer without necessity to re-generate them.
Simplified 3rd-party dependency search tool genconf with GUI based on Tcl/Tk.
Batch-script environment/configuration files (env.bat and custom.bat), although CMake script in OCCT emulates similar files.
Generated Visual Studio solution contains Debug+Release and 32bit/64bit configurations.
Running Draw Harness and regression tests can be started directly from Visual Studio (without building any INSTALL target).
No problems with CMakeCache.txt.
Limitations of genproj:
No CMake configuration files. Other CMake-based projects would not be able re-using configuration files to simplify 3rd-party setup.
Regeneration of project files should be called explicitly.
Out-of-source builds are not supported (however, each configuration is put into dedicated sub-folder).
No INSTALL target.
No PCH (pre-compiler header file) generation.
It should be noted, that several attempts have been done to make compiler / linker flags consistent between CMake and genproj, but in reality they may be different.
We have Matlab R2017a installed on a RHEL 7.3 machine and I can provide verbose installation instructions if necessary. We have the Matlab library paths saved in /etc/ld.so.conf.d/matlab.conf and have run ldconfig to make sure the paths get picked up. Matlab works and everything is functional. However, Matlab seems to come bundled with it's own versions of libraries such as libstdc++, libicui18n, and others.
I'm trying to build and link a non-Matlab executable with the two libraries mentioned above and it's linking against Matlab's and not the system. How can I tell the linker to use the system provided libraries? I'm pretty sure this isn't a Matlab-specific problem, but that happens to be the environment I'm working in. Any thoughts would be greatly appreciated.
Here is what our /etc/ld.so.conf.d/matlab.conf file looks like. Based on some testing, it does look like all three of these are necessary.
/opt/MATLAB/R2017a/bin/glnxa64
/opt/MATLAB/R2017a/runtime/glnxa64
/opt/MATLAB/2017a/sys/os/glnxa64
There are libraries installed in the runtime that depend on libraries installed in sys/os. The libraries in sys/os are the ones conflicting with the RHEL system libraries (such as libstdc++).
I created a haxe project using openfl. I can build and run the project on my own desktop using lime test windows.
Now how do I actually ship this project to other users?
I tried simply zipping the binary output created by running the command above. When I then unpack this zip on a different computer and start the executable file it will complain that I'm missing certain .dll files (more specifically the libstdc++-6.dll file).
Although this is not a direct answer to your question, a solution to this issue would be to compile through another software/tool, such as FlashDevelop.
For a few versions already, FlashDevelop includes an App manager feature that allows you to easily install the latest versions of Haxe, Lime & OpenFl (in an all-in-one package), and compile for all the Haxe/Lime/OpenFl targets seamlessly by just switching a value in a drop-down menu.
This allowed me to compile without any problems native C++ or Neko versions of my projects, thus embedding all the necessary files that could be zipped and sent to other computers.
I have two different Qt projects, one of which needs to be compiled with Qt 4.8 and the other being compiled with Qt 5.4. Both need to use the library QDeviceWatcher compiled in accordance to their versions (i.e. the app under Qt 5 should have QDeviceWatcher compiled for Qt 5 and the one using Qt 4.8 needs QDeviceWatcher compiled with Qt 4.8).
The problem is that, under Linux, the .so library files are supposed to be located in the same "global" folder, /usr/local/lib. Since I'm working on both projects, I'ld have to have both groups of .so files located in that folder - what simply is not possible given that they have the same name and the last addition would simply overwrite the previous one.
As for now what I'm doing is each time I change the project to be compiled, I update the library files with the compilation I need, but that is obviously undesirable.
Is there any way to counter this problem?
The only two ways I came across was to create a fake new version of the library (currently is 2.0.0, so I could create version 2.0.1) and compile each lib version for one different Qt version (but of course that would be messy, I mean, it's a fake version!) or to locate the .so files in a directory close to the project so the files would be looked after there instead of in the global dir /usr/local/lib. But that, seems to me, breaks down the whole idea of having the library available globally for all and new applications. And Google didn't help me with this.
Given that QDeviceWatcher is a 3rd party app what I would do is install it outside of the /usr/local/lib folder and into the project directory instead, and update my .pro to point to it directly.
I have windows dynamic linked library which I want to access from Linux environment. I don't have the source code of that library, so I cannot build .so file.
Is there a way by using Winelib or any other library or tool for converting library file to .so file, so that I can call functions defined in that library?
There is no easy way to do it, because the DLL cannot run in Linux enviromnemt all by itself. It will probably rely on user32.dll msvcrt.dll and friends at runtime, so you'll have to provide those files as well.
You can use winelib, but it doesn't just convert a .dll to an .so. You'll have to link the whole project that wants to call the DLL against winelib, and include the DLL itself with your app at runtime. If you are trying to port a Windows app to Linux, winelib will be able to convert your makefile for you, but it's far from automatic for complex projects.