There are many open-source libraries that can be compiled with Visual Studio. I'm porting a program from Linux to Windows, but it depends on a number of libraries. I don't know what the best practices regarding libraries are on Windows.
On Linux, these libraries are typically part of the distribution. To use sqlite on Debian, for example, you need only to install libsqlite3-dev and the include files and libraries (both static and dynamic) are automatically installed and available to your program.
If you need a different version than your distribution supplies, you can compile it in your home directory, install it to ~/include and ~/lib, and set the appropriate environment variables so that your compiler includes those directories in its search path.
What is the best way to use libraries that are distributed as source on Windows? If I link dynamically rather than statically, is there an easy way to copy required DLLs into the output directory to ease redistribution (assuming license requirements are met)?
Option 1 - Projects that have binary distributions for windows / do not build in DevStudio.
E.g. OpenSSL.
Projects like OpenSSL are best downloaded to their own folder and built using their own scripts. OpenSSL typically installs itself to C:\OpenSSL on windows builds, so one done, you can add C:\OpenSSL\include and C:\OpenSSL\lib to your project environment to access the OpenSSL headers and Libs. The actual dll files you will need to copy from C:\OpenSSL\bin into your projects staging folder (normally your SolutionDir\Debug or Release).
Once youve gone through the hassle of building OpenSSL once, you don't want to do it again. Or, if you've downloaded the binary distribution, its best left alone. Just document to others which binary distribution you used so they can set up their Visual Studio build environment appropriately.
Option 2 - Small libraries that are easy to create Visual Studio Projects for (or already have). Lua and sqllite fall into this category.
For projects that are small enough, it is not inconvenient to simply add them to your solution in a sub folder. This way you can get their outputs built directly to the solutions output folder, and you do not have to bundle pre-build binary files in your solution making it far easier to share the project with others.
Option 3 - As an alternative you could create your own standardized folder for the products of open source projects. Create C:\oss\include, c:\oss\lib, c:\oss\bin etc, add these paths to DevStudios lib and include paths, add c:\oss\bin to the systems PATH variable, as you build each OSS project, copy the appropriate files to these locations.
Again, while convenient, this setup makes it diffucult to replicate the build environment on a 2nd PC, so you might want to keep the entire C:\oss tree in source control as well.
On windows the easiest way is to build your own DLLs and include them in the program directory.
Yes it uses a bit more space, but HD are large these days and avoids a lot of headaches of incompatible versions (DLL hell). Windows also suffers a few more wrinkles with versions of libs built with different compilers so shipping your own builds is safest
Related
We are building an audio plugin that can be loaded by a various number of audio production softwares. To make it as compatible as possible to all common softwares, we actually build three versions of it (Steinberg VST2 format, Steinberg VST3 format, Avid AAX format), which is achieved by wrapping our core plugin code with wrappers for those three APIs. All three versions are installed in the standard location as specified for each format.
Our plugin now depends on the Microsoft onnxruntime, which we want to dynamically link against. Now, what is the right way of deploying and handling this dependency? As the plugin is loaded by the users host software of choice at runtime, placing the dll dependency next to the executable is no option, since we don't know which host software the user will use and which of the three plugin formats this software will chose.
Being a macOS developer, I'm unfamiliar with Windows best practice here.
Ideally we would like to install the dll into a custom location. But this would need us to modify the systems PATH variable to ensure that the dll is found for all users when a host loads one of our plugins, right? I'm not sure if this is a clean solution?
Another option could be to install the dll into C:\Windows\System32 but my research revealed that there is no versioning information on the dlls located there, so in case some other application installed onnxruntime there as well (or if it's a never windows installation that already ships with onnxruntime), how could we ensure that its version is equal or greater than the version needed by our plugin (in which case we wouldn't overwrite it) or below our minimum needed version (in which would replace it)? This generally seems like bad practice as well to me.
So what's common best practice on Windows for such scenarios? Am I overlooking a proper solution?
Forgive me before I start, as I'm not a C / C++ etc programmer, a mere PHP one :) but I've been working on projects that use some others sourced from online open source repos, such as svn and git. For some of these projects, I need to install libraries and then run "./configure", "make" and then "make all" (as an example) and I do this on a "build" virtual machine to get the binaries that I need to use within my project.
The ultimate goal of some of my projects is to then take these "compiled" (if that's the correct term) binaries and place them onto a virtual machine which I would then re-distribute (according to licenses etc).
My question is this : when I build these binaries on my build machine, with all the pre-requisities that I need in order to build them in the first place ("build-essential" and "cmake" and "gcc" etc etc) - once the binaries are on my build machine (in /usr/lib for example) are they self-contained to the point that I can merely copy those /usr/lib binary files that the build created and place them in the same folder on the virtual machines that I would distribute, without the build servers having all the build components installed on them?
With all the dependencies that I would need to build the source in the place, would that finally built binary contain them all in itself, or would I have to include them on the distributed servers as well?
Would that work? Is the question a little too general and perhaps it would all depend on what I'm building?
Update from original posting after a couple of responses
I will be distributing the VMs myself, inasmuch as I will build them and then install my projects upon them. Therefore, I know the OS and environment completely. I just don't want to "bloat" them with unnecessary software that's been installed that I don't actually need because the compiled executables I will place on the distributed VMs in for example /usr/local/bin ...
That depends on how you link your program to libraries it depends on. In most cases, the default is to link dynamically, which means that you need to distribute your executable along its deps. You can check out what libraries are required to run the file using ldd command.
Theoretically, you can link everything statically, which means that library code would be compiled into executable. Thus, executable would really be self-contained, but linking statically is not always possible. This depends on actual libraries you are using and probably require playing with ./configure args when building them.
Finally, there are some liraries that always linked dynamically, such as libc. The good thing is that machine you are distributing to would surely have this library. The bad thing is that versions of these libraries may differ, and you might face ABI mismatch.
In short, if your project not huge and there is possibility to link everything statically, go this way. If not, read about AppImage and Docker.
The distribution of built libraries and headers (binary distribution) is a possible way and should work. (I do it in my projects always.)
It is not necessary that all of the libraries you built are installed into /usr/lib. To keep your target machine clean you can install it in other folder to, e.g.
/usr/local/MYLIB/lib/libmylib.so
/usr/local/MYLIB/include/mylib.h
/usr/local/MYOTHERLIB/lib/libmyotherlib.so
/usr/local/MYOTHERLIB/include/libmyotherlib.so
Advantages:
Easy installation, easy remove
All files within one subfolder, no files are missing, no mix with other libs
Disadvantage:
The loader must know the extra search path
Case in point, a have a program that needs to be able to load dynamic libraries from runtime created arbitrary source files. The program is licensed under GPL. The program should ship as a package free of any external dependencies, ie. run out of an unzipped package.
Ideally, it should work as a portable, platform independent IDE (different binaries for different targets of course). Targets in mind are OSX 10.8++ and Windows, both in 32 and 64 bit formats. I need it to support C and C++ only.
I envision it as GCC placed in a subdirectory and invoked from a platform-supported script (like .bat files and bash etc.) with the goal of producing a dynamic library that can be loaded right away (ie. a DLL or a dylib) - through a classic commandline. The script will be fed with input / output files and include directories.
Can i use GCC for this - and how can i obtain/create such a package? Would this be legal from a license context? How about the standard library source files?
Any help with this project is hugely welcomed.
How do you configure (i.e. set paths/libs/whatever) for libraries you use in your project (big ones, like boost/qt, which you can't just include in the project files) in Visual Studio when you work with other team members through e.g. SVN? I mean, everyone can have their libraries installed in different paths on their computers, so how do you configure all that to work everywhere?
Right now I'm working on a C++ project so I would like to know about C++ but probably the problem is general.
Basically two options:
Put path to them into an environment variable, you can use then it in project properties
Create a VS user macros with predefined name with path to installed libraries, again it can be used in project properties
To me #1 seems to be simpler and more universal, but no clear winner.
You may also want to include library version into name of variable, so that information about required version of third-party components is versioned as well instead of "whatever is installed on computer".
I'm writing an NSIS installer for a project that requires the PyOpenGL package, however installation of this package fails because my system doesn't contain mscvr71.dll (VS C runtime lib). According to KB326922, this library should have been packaged with PyOpenGL.
My question is, what is the safest way to correct this so I can install the PyOpenGL dep within my installer? I certainly don't want to have to drop the file into system32 during installation, and I'm not aware of any update that includes this file (other than VS itself).
EDIT:
I can't easily re-package PyOpenGL to include the missing dll. I don't have VS installed and am unsure how to rebuild the package and installer.
You can put the library in the same directory as the installer for PyOpenGL, which is first in the dll search path. mscvr71.dll is included with other applications, like the Java JRE, so you may have a safe copy to use in your Program Files directory (don't use dll's from untrusted sources).
Assuming that you have mscvr71.dll in your References, right-click on the mscvr71.dll file, select Properties, and change the Copy Local property to True.
See the py2exe tutorial, which I augmented last year to describe exactly which version of which DLL files you need for different versions of Python, where to get them from, and how to include them (especially for the tricky newer versions, which require manifest files and the like):
http://www.py2exe.org/index.cgi/Tutorial#Step5