I'm building an application using Qt 5.8 and setting up for static builds (since this seems to be the best way to get OpenSSL working when deploying the application to other computers). However, we also have a dependency on WebEngine which cannot be built statically.
Is it possible to build the application using a statically built Qt5.8 but still dynamically link the WebEngine libraries when compiling?
I can get the application working with a fully dynamic build - so will it simply dynamically link any libraries that weren't built into the static compiler? Obviously, I will still need to provide the dynamic library with the executable when deploying.
Yes you can. Almost all build systems used in Qt (qmake, cmake, qbs) provide easy options for linking both static and dynamic libraries.
What build system are you using?
Yes, you can do it. I had to build Net-SNMP which gave me a ./configure file in which I mentioned the shared and static library, wherein the system libraries were dynamically linked and OpenSSL was statically linked.
You can go through ./configure file post downloading Net-SNMP and go through the file which does the same task and tweak the values according to your usage and environment.
Additionally, go through link 1 and link 2 which will give you a brief idea about how to create a shared and dynamic library.
Related
Hello when I build my wxWidgets GUI application on Linux the build goes fine. I can even run it and it works as expected. When I copy the binary to another Ubuntu computer and try to run it I get this error:
./app2: error while loading shared libraries: libwx_baseu_unofficial-3.1.so.0: cannot open shared object file: No such file or directory
Even when copying the lib across I still get an issue. Why is it dependent on external libraries and how can I solve this problem as I don't want other computers to require this library to be installed? I suppose I could try to statically link it but others recommend you do not do this.
You need to install the entire wxWidgets runtime/shared library on any machine you copy your binary onto. This is the whole point of using aptitude -- each binary package has a list of dependencies that get installed along with it.
To overcome this you need to statically link your binary. You are currently using shared linking, which relies on, as you note, external libraries. ".so" means Shared Object. You'll have to link against static archive libraries, often ending in ".a". Typically development packages provided by aptitude do not provide these, so you will probably have to compile wxWidgets yourself to provide these. Just make sure to also statically link and compile all of wxWidgets downstream dependencies as well. This is the major downside of static linking.
You can also look into something like Holy Build Box.
I'm developing a c++ program on Ubuntu 16.04 using cmake, compiling with g++5 and clang++-3.8.
Now I'd like to make this Program availabile for 14.04, too, but as I'm using a lot of c++14 features I can't just recompile it on that system. Instead, I wanted to ask if/how it is possible to package all dependencies (in particular the c++ standard library) in a way that I can just unpack a folder on the target system and run the app.
Ideally I'm looking for some automated/scripted solution that I can add to my cmake build.
Bonus Question:
For now, this is just a simple command line program for which I can easily recompile all 3rd party dependencies (and in fact I do). In the long run however, I'd also like to port a QT application. Ideally the solution would also work for that scenario.
The worst part of your contitions is an incompatible standard library.
You have to link it statically anyway (see comments to your answer).
A number of options:
Completely static linking:
I think it's easiest way for you, but it requires that you can build (or get by any way) all third-party libs as static. If you can't for some reason it's not your option.
You just build your app as usual and then link it with all libs you need statically (see documentation for your compiler). Thus you get completely dependencies-free executable, it will work on any ABI-compatible system (you may need to check if x86 executable works on x86_64).
Partially static linking
You link statically everything you can and dynamically other. So you distribute all dynamic libs (*.so) along with you app (in path/to/app/lib or path/to/app/ folder), so you don't depend on system libraries. Create your deb package which brings all files into /opt or $HOME/appname folder. You have to load all dynamic libs either "by hand" or ask compiler to do it on linking stage (see documentation).
Docker container
I don't know much about it but I know exactly it requires that docker be installed on target system (not your option).
Useful links:
g++ link options
static linking manual
Finding Dynamic or Shared Libraries
There are similar docs for clang, google it.
I'm preparing to build crypto++ libraries on debian system, although debian repositories provide them via apt-get I want to to do it from source to make sure that the compiled libraries are the latest one and to build with certain options only.
The default makefile is configured to build a static library, release build, and I want to modify makefile for my needs and to add some other stuff there.
Basically I'll use these libraries only for learning, no release programs of any kind, so my question is whether I need release build or debug for learning, also I'm not sure if it's better to build shared or static libraries for learning purposes?
I suppose this question sounds funny but I'm unsure why would I need debug libraries, to debug simple programs? or to debug libraries it self?
Difference between a debug and a release lib is that the debug usually have more internal checks to ensure that you are using the lib correctly, the counterpart is that the lib is also heavier and slower. That's why release build are done with the release lib.
Static linking(Copy): one large exe file, more comfy for development. You move the parts of the librairy you use into your binary.
Dynamic linking(Reference): a small exe file plus one or more .so/.dll files. Your executable use reference to the librairy, so X programs using the same lib only refer to the same instance of the lib. It doesn't duplicate code as static linking does.
I have a simple project that uses a single library in order to run.
For example, my program is called "myApp", and I have a library that I have have built and coded myself called libspoonybard. The makefile for libspoonybard is set up so that both a shared object (.so) and a static library (.a) file is generated for this library.
-myApp
--libspoonybard
What would I specify at build time (either via command-line flags or a makefile) so that I can build "myApp" both as a "static" version (ie: forced to use libspoonybard.a) and a "dynamic" version (forced to use libspoonybard.so at run time).
I have already attempted several searches for a similar topic on StackOverflow, but all the results seem to be focused on how to create a static vs dynamic library as opposed to how to specify which one to link against. Sorry if this is a repost.
Thank you all in advance for your assistance.
"-static" vs "-shared" can be used under GCC:
http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#Link-Options
You can use -static flag, specify .so or .a file directly etc.
A short introduction:
3.2 Shared libraries and static libraries (Stallman/Gough)
I've compiled Boost and it works just fine. I would like to to copy specific .dll's and .libs into my project for deployment. The problem is I'm having a hard time finding which packages contain the libraries I need. I've looked around but haven't seen any documentation on what's actually inside the compiled libraries.
For instance, if I wanted to use boost:asio and boost::prt_vector in my project, which .dll/.libs should I copy over?
The entire library folder is over 1.2 GB so I'd rather not use the entire thing. I'm using Windows, vs2008.
Any ideas?
Are you deploying your application as an executable or as a project to be compiled by the user? If it is the former, you shouldn't need to send static libraries, as they're linked into your executable. If you build Boost libraries as dynamic libraries, you will need them of course.
But if you're deploying your app as something to be compiled, or if you have Boost DLLs, then as martiall said, you should use BCP.
You can use the bcp which is bundled in Boost
BCP Docs