Is there any way I can ignore all the java components that Install4J uses? For example not requiring the user to have java installed? I have a very simple executable that I would like the user to install onto their machine and I would like the user to be able to enter some input for things like port.
The issue is that Install4J requires you to have java downloaded, and it also installs a ton of unnessary items that I don't need for this project.
Reason I'm using Install4J is my company has a license for it, and its very clean and easy to use unlike something like Inno where its windows only and I would need to learn how to script it.
The project is a javascript nodejs file thats already been packaged. I just need a neat installer so that all the client needs to do is enter some information such as port and have the program read the xml file for the needed input.
Thanks.
EDIT: Seems to not be possible. See: Can you use nodejs with install4j
This may be a noob question, but I have been stuck trying to work out how to statically build my qt project on linux. I tried doing what it said on http://doc.qt.io/qt-5/linux-deployment.html , but I do not understand the 1st step. When I cd to the location of my qt project and run
cd /path/to/Qt
./configure -static -prefix /path/to/Qt <otherparameters>
make
it says no such file or directory. Am I misunderstanding what paths I need to use? I want to make my qt project a stand alone executable which doesnt require the computer it is on to have qt. I have read about dynamically linking the libraries, but I dont really know what to do with that either. The deploy option is greyed out in qtcreator, is there a way to use this?
Thanks
/path/to/Qt should be the path to Qt's sources, not your project's. That section of the documentation is about building Qt statically, which you must do before trying to statically link your application to Qt. For example, if you downloaded/cloned the sources to /home/jxb458/qt5, then you'd replace /path/to/Qt with that:
cd /home/jxb458/qt5
./configure -static -prefix /home/jxb458/qt5/qtbase
make
Static linking is great when it works, but it can be an effort - I have found especially when using GUI. As Mitch said you need to actually re-build the Qt source code
I made some notes back when I was building statically quite a bit here: Notes on static building (derived from many sources) they should at least point you in the right direction - you can probably ignore the part about installing Ubuntu - the notes assume a new install.
However I have more recently returned to the dynamic linking deployment since I feel this is a better way to deploy now. You don't need to install Qt on the target machine you just need to collect the qt dlls and copy them with your application (using ldd executable-name which produces a list of dlls you need - but just take the Qt ones not the system/generic ones). For plugins you need to do a bit more (but its fairly simple). I even wrote a bash script to do this automatically (i'll send it to you if you need it), in windows there is a qt script called windeployqt (not sure why there is not a linux variant).
If I where to start again looking into deployment I would go for dynamic linking. Maybe try with a simple project to start with (like a hello world proj).
I am trying to build VTK from sources as it is a dependency to PLC library which I am trying to build.
I use ccmake.. to select all relevant groups to be built (including Group_imaging), and I can build VTK with no particular problems.
Though, I cannot find vtkImageLoader2.h (and many other headers) anywhere in the system. As these files are required by PCL, this is a problem.
I checked that the original file exists inside the source tree, and it is indeed inside IO/Image.
I can't understand why the file is not being build and deployed to /usr/local/include, I made sure all modules (groups) are ON in ccmake.
Is this file deprecated, or am I missing the way to deploy it?
EDIT: I discovered that the file belongs to module vtkIOImage that is part of the "StandAlone" group. The StandAlone group is set "ON" when i run ccmake. Is this a bug in the build scripts of VTK?
I am getting into a position where I have to use other people code for projects, for example openTLD. I want to change some of the code to give it more functionality and use it in a diffrent way. What I have found is that many people have packaged their files in such a way that you are supposed to use
cmake
and then
make
and sometimes after that
make install
I don't want to install the software on my system. What I am looking to do is get these peoples code to a point where I can add to it in Eclipse or even just using Nano and then compile it.
At what point is the code in a workable/usable state. Can I use it after doing cmake or do I need to also call make? Is my thinking correct that it would be better to edit the code after calling cmake as opposed to before? I am not going to want my finished code to be cross platform supported, it will only be on Linux. Is it easer to learn cmake and edit the code befor running cmake as opposed to not learning cmake and using the code afterwards, if that is possible?
You question is a little open ended.
Looking at the opentld project, there is a binary and a library available for use. If you are interested in using the binary in your code, you need to download the executables(Linux executables are not posted). If you are planning to use the library, you have two options. Either you use the pre-built library or build it during your build process. You would include the header files in your custom application and link with the library.
If you add more details, probably others can pitch in with new answers or refine the older ones.
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)