Visual Studio 2012, C++ project.
My project has a dependency to external library (includes its headers). Library is large and should not be stored in source-controlled repository itself. Each developer may keep the library sources in different locations (Dev1 will keep it on C:\libs, Dev2 somewhere else).
Is there a way to keep the dependency in the project, but yet to avoid committing VC++ Project file with my own path to remote repository? I was thinking about adding to "Include" directories environment variable that each developer would have to set properly on their machines, but maybe there are some better solutions?
If you only include header files, you can use
#include <header>
instead of
#include "header.h"
That way, the compiler will take the header from the standard include path, eg VS2012/VC/include.
Other developers may have different standard paths.
For further information see:
http://www2.informatik.uni-halle.de/lehre/c/c_includ.html
Related
This is possibly the dumbest question ever, but I've downloaded the jsPDF library from here: jsPDF. It's not offered through the NuGet packages, so how do I then use it in my .NET MVC project solution? Do I need to move the downloaded folder to the "Packages" folder in my project's directory? Do something else?
Obviously, I'm a total newbie to this, so please keep your answers uncomplicated if possible. Thanks!
A Nuget package is literally just a zip file of a compiled project. If it's C# code, it's a collection of DLLs, but depending on the project, it could have static resources like CSS, JS, etc. It could also have views or other resources. The long and short, is that all of this is just pretty much dumped into your project when you include a Nuget package, much as if you had simply added it yourself.
The slight exception is with DLLs, which are placed in packages simply to keep them organized, and then simply referenced by the project they were added to. Therefore, in order to add something not available as a Nuget, you simply just add all the stuff to your project. If there's JS/CSS and such, then just drop that somewhere in your project. If there's DLLs, create some place to house those on your filesystem, and then add a reference to them in your project. I would not recommend sticking them in the packages directory, because that's managed by Nuget, and it could clobber your DLLs if you put them there.
For a website of mine I'm trying to make wkhtmltopdf(Link) work. The website is hosted on a shared hosting, which are a bit troublesome when using libraries not installed.
After a few tries with multiple version of the library(some where supposed to be static but I still got error about shared library not being found) I ended up contacting the provider, who told me that it would work if I have a static version of the library.
Problem is, my linux knowledge is very limited.
If I understand correctly, a static library would be a version of wkhtmltopdf, one single file, including all dependencies ?
As the official site mention are the followings : zlib, fontconfig, freetype, X11 libs (libX11, libXext, libXrender)
Second question is, could you point me to where I could find a step by step guide to build such library ? as my research are unsuccessful so far..
my linux knowledge is very limited
I will assume you are more or less familiar with windows dlls, which are similar to linux .sos (shared objects).
A shared object can be shared (hence the name) between different programs. In most cases, when the executable is loaded, the library is loaded in memory too. You can see such dependencies with ldd.
A static library (or statically linked library, or static executable, or whatever) is a library that is embedded in the executable at compile time. To statically link your library, you need to rebuild your executable, and link with a .a static library file, which is similar to .lib files on windows (with the visual studio compiler, at least, IIRC).
This can be troublesome and time consuming. That's why I advise you to take another route:
On windows, .dll files that share the same folder as the executable are given a higher preference than the one on the path (IIRC). On Linux (and generally UNIX), this is regarded as a security flaw, as someone could easily drop a rogue .so file and alter the program's behavior. You can however control this behavior with two environment variables: LD_LIBRARY_PATH and LD_PRELOAD. The second one is a bit more powerful, and is just some kind of "dll" injection. The first one, however, controls the path in which .so files will be searched.
So, I advise you to look for the required dependencies with ldd, and do it once again on your server if you can. Look for every missing .so file. You could do so by issuing the command ldd wkhtmltopdf | grep not found.
Once you have this list of missing libraries, bundle them together and send them on your server (be aware that they can have some dependencies too). You can probably find them on a local Linux installation of matching architecture, but I encourage you to try to match the distribution with the one of your provider.
Then, issue the wkhtmltopdf call after setting the LD_LIBRARY_PATH environment variable. You can do it like so:
LD_LIBRARY_PATH='/home/me/my_libs':$LD_LIBRARY_PATH /home/me/programs/wkhtmltopdf
Note that I append the old LD_LIBRARY_PATH variable at the end. It is rarely set out of the box, but at least you shouldn't have any problem if you do it this way.
To answer your comment: it is indeed a bit like modifying the PATH on windows (just to make this clear once again: on Linux, you have the same PATH environment variable, but it only works for executables' search path; so we're changing another LD_LIBRARY_PATH environment variable to specify the libraries search path).
Please note that in the above example, I didn't change it system-wide, but only for calling wkhtmltopdf. On windows, there are multiple ways to change the PATH environment variable. You can open the dedicated gui, which will change the path variable in the registry. But you can also override it locally in a command prompt or batch script. This is exactly what I did here.
Once LD_LIBRARY_PATH is exported, it will be used for every program you call, so it might be dangerous to set it system wide, if you have some incompatibilities. Moreover, whatever you try, you won't be able to set it system-wide if you don't have root access. So, you will at most affect only your programs.
As a final note, you might pull a lot of dependencies with this project, since it is Qt-based. If you want to rebuild it statically, you have to build Qt first with -static. Next time, you might be interested in some containerization technology, such as docker (or even appimages/flatpack/snap), which is designed to work around this kind of problems.
For further reading on dynamic link libraries on Linux, you might be interested in this resource or similar.
I use third party static library (provided as a .LIB file without source code) in my project. For linking purposes it is enough to add it via "Properties/Linker/Input->Additional Dependencies"
This library is not used in any other project in the solution.
I wonder if I should add it as an item to project file itself. The advantages that I see: it will be immediately obvious that this project uses it and one wouldn't have to add it to version control system manually (anything that is a part of the project/solution is added automatically if you use something like AnkSVN).
The project in VCS must be buildable. It is impossible without the lib. So you should add it.
I want to create my own user configuration utility targetted for WinCE6 in C++. All the NTLM functions (such as this one) require ntlmssp.lib which I cannot find. I have searched my Platform Builder directories but can only find the dll file not the lib.
Can anyone shed some light on how I actually access these functions, or find the lib file?
The lib is probably generated (the DEF is in public\common\oak\lib) when you build your platform to only include the entry points you've selected in your design. For example, I do see ntlmssp.lib in my release directory for a couple designs.
The proper way to do this is to roll and install an SDK based on your OS Design, then you'll get that installed in the right place on your dev machine (or make your utility as a subproject of your OS Design, which will then look in the release folder for the LIB).
I am developing cross-platform Qt application.
It is freeware though not open-source. Therefore I want to distribute it as a compiled binary.
On windows there is no problem, I pack my compiled exe along with MinGW's and Qt's DLLs and everything goes great.
But on Linux there is a problem because the user may have shared libraries in his/her system very different from mine.
Qt deployment guide suggests two methods: static linking and using shared libraries.
The first produces huge executable and also require static versions of many libraries which Qt depends on, i.e. I'll have to rebuild all of them from scratches. The second method is based on reconfiguring dynamic linker right before the application startup and seems a bit tricky to me.
Can anyone share his/her experience in distributing Qt applications under Linux? What method should I use? What problems may I confront with? Are there any other methods to get this job done?
Shared libraries is the way to go, but you can avoid using LD_LIBRARY_PATH (which involves running the application using a launcher shell script, etc) building your binary with the -rpath compiler flag, pointing to there you store your libraries.
For example, I store my libraries either next to my binary or in a directory called "mylib" next to my binary. To use this on my QMake file, I add this line in the .pro file:
QMAKE_LFLAGS += -Wl,-rpath,\\$\$ORIGIN/lib/:\\$\$ORIGIN/../mylib/
And I can run my binaries with my local libraries overriding any system library, and with no need for a launcher script.
You can also distribute Qt shared libraries on Linux. Then, get your software to load those instead of the system default ones. Shared libraries can be over-ridden using the LD_LIBRARY_PATH environment variable. This is probably the simplest solution for you. You can always change this in a wrapper script for your executable.
Alternatively, just specify the minimum library version that your users need to have installed on the system.
When we distribute Qt apps on Linux (or really any apps that use shared libraries) we ship a directory tree which contains the actual executable and associated wrapper script at the top with sub-directories containing the shared libraries and any other necessary resources that you don't want to link in.
The advantage of doing this is that you can have the wrapper script setup everything you need for running the application without having to worry about having the user set environment variables, install to a specific location, etc. If done correctly, this also allows you to not have to worry about from where you are calling the application because it can always find the resources.
We actually take this tree structure even further by placing all the executable and shared libraries in platform/architecture sub-directories so that the wrapper script can determine the local architecture and call the appropriate executable for that platform and set the environment variables to find the appropriate shared libraries. We found this setup to be particularly helpful when distributing for multiple different linux versions that share a common file system.
All this being said, we do still prefer to build statically when possible, Qt apps are no exception. You can definitely build with Qt statically and you shouldn't have to go build a lot of additional dependencies as krbyrd noted in his response.
sybreon's answer is exactly what I have done. You can either always add your libraries to LD_LIBRARY_PATH or you can do something a bit more fancy:
Setup your shipped Qt libraries one per directory. Write a shell script, have it run ldd on the executable and grep for 'not found', for each of those libraries, add the appropriate directory to a list (let's call it $LDD). After you have them all, run the binary with LD_LIBRARY_PATH set to it's previous value plus $LDD.
Finally a comment about "I'll have to rebuild all of them from scratches". No, you won't have to. If you have the dev packages for those libraries, you should have .a files, you can statically link against these.
Not an answer as such (sybreon covered that), but please note that you are not allowed to distribute your binary if it is statically linked against Qt, unless you have bought a commercial license, otherwise your entire binary falls under the GPL (or you're in violation of Qt's license.)
If you have a commercial license, never mind.
If you don't have a commercial license, you have two options:
Link dynamically against Qt v4.5.0 or newer (the LGPL versions - you may not use the previous versions except in open source apps), or
Open your source code.
The probably easiest way to create a Qt application package on Linux is probably linuxdeployqt. It collects all required files and lets you build an AppImage which runs on most Linux distributions.
Make sure you build the application on the oldest still-supported Ubuntu LTS release so your AppImage can be listed on AppImageHub.
You can look into QtCreator folder and use it as an example. It has qt.conf and qtcreator.sh files in QtCreator/bin.
lib/qtcreator is the folder with all needed Qt *.so libraries. Relative path is set inside qtcreator.sh, which should be renamed to you-app-name.sh
imports,plugins,qml are inside bin directory. Path to them is set in qt.conf file. This is needed for QML applications deployment.
This article has information on the topic. I will try it myself:
http://labs.trolltech.com/blogs/2009/06/02/deploying-a-browser-on-gnulinux/
In a few words:
Configure Qt with -platform linux-lsb-g++
Linking should be done
with –lsb-use-default-linker
Package everything and deploy (will
need a few tweaks here but I haven't yet tried it sorry)