Deploy Application in Linux
-
wrote on 27 Feb 2021, 17:29 last edited by
I have successfully deployed my application in windows using
windeployqt
and now I am looking to deploy in linux.I followed a tutorial on how to do it using
qinuxdeployqt
but I got an error about " The host system is too new" which I could get past. In the output threre was this link to one repo issue.
In the discussion there were some mentions about these two option:-unsupported-bundle-everything
and-unsupported-allow-new-glibc
but from what I read:I am open to adding options, as long as it is very clear that those options are neither recommended nor supported by me. As such, I would welcome pull requests that implement the following:
-unsupported-bundle-everything: Bundles ALL dependency libraries, down to and including the ld-linux.so loader and glibc. This will allow applications built on newer systems to run on older target systems, but it is not recommended since it leads to bundles that are larger than necessary
-unsupported-allow-new-glibc: Allows linuxdeployqt to run on distributions newer than the oldest still-supported Ubuntu LTS release. This will result in AppImages that will not run on all still-supported distributions, and is neither recommended nor tested or supportedMeaning that I couldn't get past that error with the latest release and I am not really willing to reinstall my system to the oldest still-supported Ubuntu LTS release. I found what he is trying to accomplish with that rule noble but at the same too restricted for normal use.
Anyway, I went on to try
linuxdeploy
but that one I just couldn't find how to install, not even how to build it(tried to build it at some point but I was not successful).So I went on to another alternative,
CQtDeployer
, I installed and tried to run it but don't matter how I tried it always gave me 'missing arguments' errors and there are two few examples on how to use it and no guide on how to deploy an application right from start.So, I came to find a tutorial on how to deploy using
linuxdeployqt
, in the tutorial the same errors I got was found too and was solved using an older release instead, so I did that and the error about host being too new was gone, tried to use it to deploy my app and it kept giving me this error:ERROR: ldd outputLine: "libicui18n.so.56 => not found"
I couldn't find a solution to that.
I have visited a lot of forums and followed many tutorials but every one of them suggests using one of the tree tools I mentioned above.But I think that these 3 tools are fairly new, so I ask how Qt apps were being deployed in linux before them. How can I successfully deploy my app without them.
I have spent hours trying to deploy my app with not luck.
As a last resource, I am now trying to manually copy all the dependencies into the my executable directory.
-
I have successfully deployed my application in windows using
windeployqt
and now I am looking to deploy in linux.I followed a tutorial on how to do it using
qinuxdeployqt
but I got an error about " The host system is too new" which I could get past. In the output threre was this link to one repo issue.
In the discussion there were some mentions about these two option:-unsupported-bundle-everything
and-unsupported-allow-new-glibc
but from what I read:I am open to adding options, as long as it is very clear that those options are neither recommended nor supported by me. As such, I would welcome pull requests that implement the following:
-unsupported-bundle-everything: Bundles ALL dependency libraries, down to and including the ld-linux.so loader and glibc. This will allow applications built on newer systems to run on older target systems, but it is not recommended since it leads to bundles that are larger than necessary
-unsupported-allow-new-glibc: Allows linuxdeployqt to run on distributions newer than the oldest still-supported Ubuntu LTS release. This will result in AppImages that will not run on all still-supported distributions, and is neither recommended nor tested or supportedMeaning that I couldn't get past that error with the latest release and I am not really willing to reinstall my system to the oldest still-supported Ubuntu LTS release. I found what he is trying to accomplish with that rule noble but at the same too restricted for normal use.
Anyway, I went on to try
linuxdeploy
but that one I just couldn't find how to install, not even how to build it(tried to build it at some point but I was not successful).So I went on to another alternative,
CQtDeployer
, I installed and tried to run it but don't matter how I tried it always gave me 'missing arguments' errors and there are two few examples on how to use it and no guide on how to deploy an application right from start.So, I came to find a tutorial on how to deploy using
linuxdeployqt
, in the tutorial the same errors I got was found too and was solved using an older release instead, so I did that and the error about host being too new was gone, tried to use it to deploy my app and it kept giving me this error:ERROR: ldd outputLine: "libicui18n.so.56 => not found"
I couldn't find a solution to that.
I have visited a lot of forums and followed many tutorials but every one of them suggests using one of the tree tools I mentioned above.But I think that these 3 tools are fairly new, so I ask how Qt apps were being deployed in linux before them. How can I successfully deploy my app without them.
I have spent hours trying to deploy my app with not luck.
As a last resource, I am now trying to manually copy all the dependencies into the my executable directory.
@hbatalha said in Deploy Application in Linux:
Meaning that I couldn't get past that error with the latest release
Why do you think so? The author simply states that he does not "support" these parameters, means - he does not guarantee anything. You should try.
-
@hbatalha said in Deploy Application in Linux:
Meaning that I couldn't get past that error with the latest release
Why do you think so? The author simply states that he does not "support" these parameters, means - he does not guarantee anything. You should try.
wrote on 1 Mar 2021, 07:09 last edited by@jsulm said in Deploy Application in Linux:
he does not guarantee anything. You should try.
I tried them, they are not implemented yet.
-
wrote on 1 Mar 2021, 07:14 last edited by
Just a little update, I did go to my last resource, copied all the dependencies manually, used the Qt Installer Framework to create a .run file. I was able to run installer, install the application, created desktop entry.
But, when I tried to run the program in a another machine, the machine complained about no finding the .so files even though they are there in the same folder.
So, I am looking for the solution of this problem.
Any idea, anyone?
-
Just a little update, I did go to my last resource, copied all the dependencies manually, used the Qt Installer Framework to create a .run file. I was able to run installer, install the application, created desktop entry.
But, when I tried to run the program in a another machine, the machine complained about no finding the .so files even though they are there in the same folder.
So, I am looking for the solution of this problem.
Any idea, anyone?
wrote on 1 Mar 2021, 07:19 last edited by@hbatalha said in Deploy Application in Linux:
But, when I tried to run the program in a another machine, the machine complained about no finding the .so files even though they are there in the same folder.
So, I am looking for the solution of this problem.
Any idea, anyone?
Windows does always look first next to the executable, which is not the way in Unix/Linux. When linking, either the
-rpath
option is use and then the same relative path must be used, or the libraries are simply loaded from the system (i.e./usr/lib64
or your system's equivalent), or you can specify additional directories using theLD_LIBRARY_PATH
environment variable.
If-rpath
has been used, it can be tuned afterwards (but I can't remember the tool from the top of my head). -
wrote on 1 Mar 2021, 17:09 last edited by hbatalha 3 Jan 2021, 17:43
@JohanSolo I checked and it seems to be what I need.
So I am trying it but I can't seem to get it working.
I followed this tutorial but that doesn't work when change the rpath.
My problem is in how I change the path, how to write the correct path, I visited different forums and I found people writing different syntaxes each time:- chrpath -r $ORIGIN/lib myexecutable
- chrpath -r '$\ORIGIN/lib' myexecutable
- chrpath -r '$\ORIGIN' myexecutable
- chrpath -r $\ORIGIN/lib myexecutable
- chrpath -r "$\ORIGIN/lib" myexecutable
- chrpath -r '$\ORIGIN/lib' myexecutable
These are some of the commands I tried, none worked. The files the machine is asking for are in my lib folder
-
wrote on 2 Mar 2021, 06:37 last edited by
@hbatalha
You've told us the shared libraries are in the same directory as your executable file, but now you're telling they are in your lib folder (whatever that means). So please clarify where your shared libraries are.If they are in the same folder, then you should use:
chrpath -r "$ORIGIN" myexecutable
if they are in alib
subfolder, then the command reads:
chrpath -r "$ORIGIN/lib" myexecutable
-
wrote on 2 Mar 2021, 06:54 last edited by
I recommend integrating rpath directly into the build with linker flags, not hacking on the files after they are built.
-
I recommend integrating rpath directly into the build with linker flags, not hacking on the files after they are built.
wrote on 2 Mar 2021, 06:57 last edited by@Phil-K said in Deploy Application in Linux:
I recommend integrating rpath directly into the build with linker flags, not hacking on the files after they are built.
I would recommend that too, but sometimes (we don't know the OP's situation) the libraries are in that folder at build time but will be located in this folder when deployed. In that case "hacking" the binaries is a cleaner option.
-
@Phil-K said in Deploy Application in Linux:
I recommend integrating rpath directly into the build with linker flags, not hacking on the files after they are built.
I would recommend that too, but sometimes (we don't know the OP's situation) the libraries are in that folder at build time but will be located in this folder when deployed. In that case "hacking" the binaries is a cleaner option.
wrote on 2 Mar 2021, 08:17 last edited by Phil K 3 Feb 2021, 08:18@JohanSolo If he's not building a destination tree that mirrors the way he wants to install the files, he's doing it wrong. If he is doing that, then configure the build system to use rpath and $ORIGIN with the appropriate linker flags. I would turn to
chrpath
as a last resort, not an opening idea. It's quite common also to deploy wrappers that set the library path and then run the program. There's a lot to consider all in all, it's a non-trivial rabbit hole that brings in things like licensing, rpath, runpath, origin and other considerations such as allowing the user to run a different Qt runtime, etc. -
@hbatalha
You've told us the shared libraries are in the same directory as your executable file, but now you're telling they are in your lib folder (whatever that means). So please clarify where your shared libraries are.If they are in the same folder, then you should use:
chrpath -r "$ORIGIN" myexecutable
if they are in alib
subfolder, then the command reads:
chrpath -r "$ORIGIN/lib" myexecutable
wrote on 2 Mar 2021, 13:03 last edited by@JohanSolo said in Deploy Application in Linux:
So please clarify where your shared libraries are.
Sorry for the lack of clarification, my libraries are in the lib folder, the lib folder is in the same directory as my executable.
-
I recommend integrating rpath directly into the build with linker flags, not hacking on the files after they are built.
wrote on 2 Mar 2021, 13:05 last edited by@Phil-K said in Deploy Application in Linux:
I recommend integrating rpath directly into the build with linker flags, not hacking on the files after they are built.
I did that that, but I am still not sure what the correct syntax is, that's why I tried different ones as shown above.
-
@Phil-K said in Deploy Application in Linux:
I recommend integrating rpath directly into the build with linker flags, not hacking on the files after they are built.
I would recommend that too, but sometimes (we don't know the OP's situation) the libraries are in that folder at build time but will be located in this folder when deployed. In that case "hacking" the binaries is a cleaner option.
wrote on 2 Mar 2021, 13:06 last edited by@JohanSolo said in Deploy Application in Linux:
but sometimes (we don't know the OP's situation) the libraries are in that folder at build time but will be located in this folder when deployed
Please elaborate more on this kind of situation.
-
@JohanSolo If he's not building a destination tree that mirrors the way he wants to install the files, he's doing it wrong. If he is doing that, then configure the build system to use rpath and $ORIGIN with the appropriate linker flags. I would turn to
chrpath
as a last resort, not an opening idea. It's quite common also to deploy wrappers that set the library path and then run the program. There's a lot to consider all in all, it's a non-trivial rabbit hole that brings in things like licensing, rpath, runpath, origin and other considerations such as allowing the user to run a different Qt runtime, etc.wrote on 2 Mar 2021, 13:13 last edited by@Phil-K said in Deploy Application in Linux:
If he's not building a destination tree that mirrors the way he wants to install the files, he's doing it wrong
"Building a destination tree", what exactly is meant by that in the statement. Sorry this is my first time programming in a linux environment (programming isn't the most accurate term here since I am only compiling my application in linux and trying to deploy there, all the code was written in windows environment).
-
@JohanSolo said in Deploy Application in Linux:
but sometimes (we don't know the OP's situation) the libraries are in that folder at build time but will be located in this folder when deployed
Please elaborate more on this kind of situation.
wrote on 2 Mar 2021, 13:20 last edited by@hbatalha said in Deploy Application in Linux:
@JohanSolo said in Deploy Application in Linux:
but sometimes (we don't know the OP's situation) the libraries are in that folder at build time but will be located in this folder when deployed
Please elaborate more on this kind of situation.
Depending on how you build your library and executable, they might end up all in the same output directory, e.g.
/home/johndoe/build-myproject-Qt5.15-Release
. Now, if the linker flag-rpath
was specified, the executable will try to load the shared library from/home/johndoe/build-myproject-Qt5.15-Release
, which is fine when you just run your program, but not for deployed executable. In that case, you can:- set the
-rpath
correctly when compiling your executable as @Phil-K suggested; - use
chrpath
as explained above.
If you only set the "final" path to
-rpath
(i.e.$ORIGIN/lib
), then your executable might not be able to run outside you IDE (but several paths can be specified, separated with colons, i.e.:
). - set the
-
@hbatalha said in Deploy Application in Linux:
@JohanSolo said in Deploy Application in Linux:
but sometimes (we don't know the OP's situation) the libraries are in that folder at build time but will be located in this folder when deployed
Please elaborate more on this kind of situation.
Depending on how you build your library and executable, they might end up all in the same output directory, e.g.
/home/johndoe/build-myproject-Qt5.15-Release
. Now, if the linker flag-rpath
was specified, the executable will try to load the shared library from/home/johndoe/build-myproject-Qt5.15-Release
, which is fine when you just run your program, but not for deployed executable. In that case, you can:- set the
-rpath
correctly when compiling your executable as @Phil-K suggested; - use
chrpath
as explained above.
If you only set the "final" path to
-rpath
(i.e.$ORIGIN/lib
), then your executable might not be able to run outside you IDE (but several paths can be specified, separated with colons, i.e.:
).wrote on 2 Mar 2021, 23:16 last edited by@JohanSolo said in Deploy Application in Linux:
If you only set the "final" path to -rpath (i.e. $ORIGIN/lib), then your executable might not be able to run outside you IDE
Are you saying if I use this command
chrpath -r "$ORIGIN/lib" myexecutable
on my executable then it will not run outside my IDE. - set the
-
@JohanSolo said in Deploy Application in Linux:
If you only set the "final" path to -rpath (i.e. $ORIGIN/lib), then your executable might not be able to run outside you IDE
Are you saying if I use this command
chrpath -r "$ORIGIN/lib" myexecutable
on my executable then it will not run outside my IDE.wrote on 3 Mar 2021, 10:49 last edited by@hbatalha said in Deploy Application in Linux:
Are you saying if I use this command
chrpath -r "$ORIGIN/lib" myexecutable
on my executable then it will not run outside my IDE.In my example, all binaries (i.e. executable and libraries) are located in the same directory, therefore the shared libraries won't be found when running the executable, as there is no
lib
subfolder (or it is empty). -
wrote on 5 Mar 2021, 03:20 last edited by
Sorry for the late reply, I've working on the app and I do it on windows, I go to linux only to deploy it
@JohanSolo said in Deploy Application in Linux:
@hbatalha
You've told us the shared libraries are in the same directory as your executable file, but now you're telling they are in your lib folder (whatever that means). So please clarify where your shared libraries are.If they are in the same folder, then you should use:
chrpath -r "$ORIGIN" myexecutable
if they are in alib
subfolder, then the command reads:
chrpath -r "$ORIGIN/lib" myexecutable
I am still unable to get it to work.
What I did: I compiled the programs , got its excutable(with the wrong rpath) and put it in a directory where I copied the .so files into the lib folder in that directory and changed the rpath with chrpath, then tried to run it but still asking for those .so files
-
wrote on 6 Mar 2021, 07:13 last edited by
So please, give us:
- the output of
ls -R
, run from the directory where your exe is located - the output of
ldd
, run on your exe - the output of
chrpath -l
, run on your exe
There must be something wrong or at least not understood by us in your setup, it should work.
- the output of
1/23