Run application built on Ubuntu on CentOS

Clash Royale CLAN TAG#URR8PPP
Is there a way to deploy an application, that you built on Ubuntu, on CentOS? And if so, how?
EDIT: Sorry, I should have given some more info.
It's built on Ubuntu 15.10 with Qt 5.6, and besides Qt it has only one other dependency which is statically linked. I'm not sure if its dependencies are statically linked as well, but it's using some boost libs and nothing Ubuntu specific so I'm guessing that shouldn't be a problem.
ubuntu centos deployment
add a comment |
Is there a way to deploy an application, that you built on Ubuntu, on CentOS? And if so, how?
EDIT: Sorry, I should have given some more info.
It's built on Ubuntu 15.10 with Qt 5.6, and besides Qt it has only one other dependency which is statically linked. I'm not sure if its dependencies are statically linked as well, but it's using some boost libs and nothing Ubuntu specific so I'm guessing that shouldn't be a problem.
ubuntu centos deployment
1
Usually no problem, if the Ubuntu that was building the application has a matching or older libc6 (The CentOS libc name is glibc.) Please test this. ... Installing to CentOS : Build anrpmpackage with the app result :/usr/[??]/
– Knud Larsen
Jul 23 '16 at 12:35
1
Same architecture I assume? Also relatively similar kernel versions? In that case static compiling should help but you should edit your question to be more specific before we can give you better and definitive answers.
– phk
Jul 23 '16 at 12:45
I'm not sure about kernel versions (I'll have to check that), and the architecture is the same. I also edited the original post with more info.
– rndm
Jul 23 '16 at 13:46
add a comment |
Is there a way to deploy an application, that you built on Ubuntu, on CentOS? And if so, how?
EDIT: Sorry, I should have given some more info.
It's built on Ubuntu 15.10 with Qt 5.6, and besides Qt it has only one other dependency which is statically linked. I'm not sure if its dependencies are statically linked as well, but it's using some boost libs and nothing Ubuntu specific so I'm guessing that shouldn't be a problem.
ubuntu centos deployment
Is there a way to deploy an application, that you built on Ubuntu, on CentOS? And if so, how?
EDIT: Sorry, I should have given some more info.
It's built on Ubuntu 15.10 with Qt 5.6, and besides Qt it has only one other dependency which is statically linked. I'm not sure if its dependencies are statically linked as well, but it's using some boost libs and nothing Ubuntu specific so I'm guessing that shouldn't be a problem.
ubuntu centos deployment
ubuntu centos deployment
edited Jul 23 '16 at 13:46
rndm
asked Jul 23 '16 at 12:17
rndmrndm
113
113
1
Usually no problem, if the Ubuntu that was building the application has a matching or older libc6 (The CentOS libc name is glibc.) Please test this. ... Installing to CentOS : Build anrpmpackage with the app result :/usr/[??]/
– Knud Larsen
Jul 23 '16 at 12:35
1
Same architecture I assume? Also relatively similar kernel versions? In that case static compiling should help but you should edit your question to be more specific before we can give you better and definitive answers.
– phk
Jul 23 '16 at 12:45
I'm not sure about kernel versions (I'll have to check that), and the architecture is the same. I also edited the original post with more info.
– rndm
Jul 23 '16 at 13:46
add a comment |
1
Usually no problem, if the Ubuntu that was building the application has a matching or older libc6 (The CentOS libc name is glibc.) Please test this. ... Installing to CentOS : Build anrpmpackage with the app result :/usr/[??]/
– Knud Larsen
Jul 23 '16 at 12:35
1
Same architecture I assume? Also relatively similar kernel versions? In that case static compiling should help but you should edit your question to be more specific before we can give you better and definitive answers.
– phk
Jul 23 '16 at 12:45
I'm not sure about kernel versions (I'll have to check that), and the architecture is the same. I also edited the original post with more info.
– rndm
Jul 23 '16 at 13:46
1
1
Usually no problem, if the Ubuntu that was building the application has a matching or older libc6 (The CentOS libc name is glibc.) Please test this. ... Installing to CentOS : Build an
rpm package with the app result : /usr/[??]/– Knud Larsen
Jul 23 '16 at 12:35
Usually no problem, if the Ubuntu that was building the application has a matching or older libc6 (The CentOS libc name is glibc.) Please test this. ... Installing to CentOS : Build an
rpm package with the app result : /usr/[??]/– Knud Larsen
Jul 23 '16 at 12:35
1
1
Same architecture I assume? Also relatively similar kernel versions? In that case static compiling should help but you should edit your question to be more specific before we can give you better and definitive answers.
– phk
Jul 23 '16 at 12:45
Same architecture I assume? Also relatively similar kernel versions? In that case static compiling should help but you should edit your question to be more specific before we can give you better and definitive answers.
– phk
Jul 23 '16 at 12:45
I'm not sure about kernel versions (I'll have to check that), and the architecture is the same. I also edited the original post with more info.
– rndm
Jul 23 '16 at 13:46
I'm not sure about kernel versions (I'll have to check that), and the architecture is the same. I also edited the original post with more info.
– rndm
Jul 23 '16 at 13:46
add a comment |
3 Answers
3
active
oldest
votes
It depends on how the application was created and what dependencies it has. If it's written in for example Python then it can generally run as long as a compatible Python interpreter and modules are installed.
If it's an elf binary then it depends on if there are binary compatible libraries installed. Since some libraries might not be available, be available only as an incompatible version or have the wrong soname then you can either statically link your binary or distribute the missing libraries together with the application.
You can also use Flatpak to package your application and then use it on multiple distributions.
I'll take a look at Flatpak, thanks. Also, edited the original post with more info.
– rndm
Jul 23 '16 at 13:47
add a comment |
As others have mentioned, just installing/extracting the app straight onto the system may or may not work, depending on things like whether it's a script or compiled binary, statically vs dynamically linked, lib versions, etc.
In order to be sure that the application will run, the app needs to run within the context of the OS that it was built for. One of the simplest ways to do this is docker. It's a bit of a heavy solution, but it will essentially let you run one OS within another. So you could run an ubuntu container and put your app in it.
You could also just setup an ubuntu chroot, and execute the application in there. This is similar to what docker does, but a lot lighter.
The only thing these solutions won't solve is if the application depends on specific kernel features that are only in ubuntu. This is very unlikely though.
I would like to avoid docker if possible. Also, edited the original post with more info.
– rndm
Jul 23 '16 at 13:47
add a comment |
You can run an application compiled for one Linux distribution on any other distribution, as long as that other distribution has the required libraries available. The problem in practice is usually that different distributions ship different versions of libraries at a given point in time.
Linking libraries statically is a bad idea. It bloats the application file size (not much of a concern in most cases, except for people with little Internet bandwidth), bloats the application size in memory (that's more of a concern in practice), and means that your application will stay stuck with all the bugs from the version you linked with. Link your libraries dynamically so that your users will benefit from the bug fixes to the libraries, especially the security fixes.
Furthermore, while you can run applications, there's the problem of packaging. Installing applications manually is a pain. If you don't distribute an RPM package for CentOS, and a deb package for Ubuntu, you do your users a disservice.
So you should generate proper packages for all distributions. You can run an application built for Ubuntu on CentOS, with more or less effort depending on library requirements, but you can't deploy an application built for Ubuntu on CentOS.
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f297789%2frun-application-built-on-ubuntu-on-centos%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
It depends on how the application was created and what dependencies it has. If it's written in for example Python then it can generally run as long as a compatible Python interpreter and modules are installed.
If it's an elf binary then it depends on if there are binary compatible libraries installed. Since some libraries might not be available, be available only as an incompatible version or have the wrong soname then you can either statically link your binary or distribute the missing libraries together with the application.
You can also use Flatpak to package your application and then use it on multiple distributions.
I'll take a look at Flatpak, thanks. Also, edited the original post with more info.
– rndm
Jul 23 '16 at 13:47
add a comment |
It depends on how the application was created and what dependencies it has. If it's written in for example Python then it can generally run as long as a compatible Python interpreter and modules are installed.
If it's an elf binary then it depends on if there are binary compatible libraries installed. Since some libraries might not be available, be available only as an incompatible version or have the wrong soname then you can either statically link your binary or distribute the missing libraries together with the application.
You can also use Flatpak to package your application and then use it on multiple distributions.
I'll take a look at Flatpak, thanks. Also, edited the original post with more info.
– rndm
Jul 23 '16 at 13:47
add a comment |
It depends on how the application was created and what dependencies it has. If it's written in for example Python then it can generally run as long as a compatible Python interpreter and modules are installed.
If it's an elf binary then it depends on if there are binary compatible libraries installed. Since some libraries might not be available, be available only as an incompatible version or have the wrong soname then you can either statically link your binary or distribute the missing libraries together with the application.
You can also use Flatpak to package your application and then use it on multiple distributions.
It depends on how the application was created and what dependencies it has. If it's written in for example Python then it can generally run as long as a compatible Python interpreter and modules are installed.
If it's an elf binary then it depends on if there are binary compatible libraries installed. Since some libraries might not be available, be available only as an incompatible version or have the wrong soname then you can either statically link your binary or distribute the missing libraries together with the application.
You can also use Flatpak to package your application and then use it on multiple distributions.
answered Jul 23 '16 at 12:48
My KarlssonMy Karlsson
1011
1011
I'll take a look at Flatpak, thanks. Also, edited the original post with more info.
– rndm
Jul 23 '16 at 13:47
add a comment |
I'll take a look at Flatpak, thanks. Also, edited the original post with more info.
– rndm
Jul 23 '16 at 13:47
I'll take a look at Flatpak, thanks. Also, edited the original post with more info.
– rndm
Jul 23 '16 at 13:47
I'll take a look at Flatpak, thanks. Also, edited the original post with more info.
– rndm
Jul 23 '16 at 13:47
add a comment |
As others have mentioned, just installing/extracting the app straight onto the system may or may not work, depending on things like whether it's a script or compiled binary, statically vs dynamically linked, lib versions, etc.
In order to be sure that the application will run, the app needs to run within the context of the OS that it was built for. One of the simplest ways to do this is docker. It's a bit of a heavy solution, but it will essentially let you run one OS within another. So you could run an ubuntu container and put your app in it.
You could also just setup an ubuntu chroot, and execute the application in there. This is similar to what docker does, but a lot lighter.
The only thing these solutions won't solve is if the application depends on specific kernel features that are only in ubuntu. This is very unlikely though.
I would like to avoid docker if possible. Also, edited the original post with more info.
– rndm
Jul 23 '16 at 13:47
add a comment |
As others have mentioned, just installing/extracting the app straight onto the system may or may not work, depending on things like whether it's a script or compiled binary, statically vs dynamically linked, lib versions, etc.
In order to be sure that the application will run, the app needs to run within the context of the OS that it was built for. One of the simplest ways to do this is docker. It's a bit of a heavy solution, but it will essentially let you run one OS within another. So you could run an ubuntu container and put your app in it.
You could also just setup an ubuntu chroot, and execute the application in there. This is similar to what docker does, but a lot lighter.
The only thing these solutions won't solve is if the application depends on specific kernel features that are only in ubuntu. This is very unlikely though.
I would like to avoid docker if possible. Also, edited the original post with more info.
– rndm
Jul 23 '16 at 13:47
add a comment |
As others have mentioned, just installing/extracting the app straight onto the system may or may not work, depending on things like whether it's a script or compiled binary, statically vs dynamically linked, lib versions, etc.
In order to be sure that the application will run, the app needs to run within the context of the OS that it was built for. One of the simplest ways to do this is docker. It's a bit of a heavy solution, but it will essentially let you run one OS within another. So you could run an ubuntu container and put your app in it.
You could also just setup an ubuntu chroot, and execute the application in there. This is similar to what docker does, but a lot lighter.
The only thing these solutions won't solve is if the application depends on specific kernel features that are only in ubuntu. This is very unlikely though.
As others have mentioned, just installing/extracting the app straight onto the system may or may not work, depending on things like whether it's a script or compiled binary, statically vs dynamically linked, lib versions, etc.
In order to be sure that the application will run, the app needs to run within the context of the OS that it was built for. One of the simplest ways to do this is docker. It's a bit of a heavy solution, but it will essentially let you run one OS within another. So you could run an ubuntu container and put your app in it.
You could also just setup an ubuntu chroot, and execute the application in there. This is similar to what docker does, but a lot lighter.
The only thing these solutions won't solve is if the application depends on specific kernel features that are only in ubuntu. This is very unlikely though.
answered Jul 23 '16 at 13:38
PatrickPatrick
50.4k11129180
50.4k11129180
I would like to avoid docker if possible. Also, edited the original post with more info.
– rndm
Jul 23 '16 at 13:47
add a comment |
I would like to avoid docker if possible. Also, edited the original post with more info.
– rndm
Jul 23 '16 at 13:47
I would like to avoid docker if possible. Also, edited the original post with more info.
– rndm
Jul 23 '16 at 13:47
I would like to avoid docker if possible. Also, edited the original post with more info.
– rndm
Jul 23 '16 at 13:47
add a comment |
You can run an application compiled for one Linux distribution on any other distribution, as long as that other distribution has the required libraries available. The problem in practice is usually that different distributions ship different versions of libraries at a given point in time.
Linking libraries statically is a bad idea. It bloats the application file size (not much of a concern in most cases, except for people with little Internet bandwidth), bloats the application size in memory (that's more of a concern in practice), and means that your application will stay stuck with all the bugs from the version you linked with. Link your libraries dynamically so that your users will benefit from the bug fixes to the libraries, especially the security fixes.
Furthermore, while you can run applications, there's the problem of packaging. Installing applications manually is a pain. If you don't distribute an RPM package for CentOS, and a deb package for Ubuntu, you do your users a disservice.
So you should generate proper packages for all distributions. You can run an application built for Ubuntu on CentOS, with more or less effort depending on library requirements, but you can't deploy an application built for Ubuntu on CentOS.
add a comment |
You can run an application compiled for one Linux distribution on any other distribution, as long as that other distribution has the required libraries available. The problem in practice is usually that different distributions ship different versions of libraries at a given point in time.
Linking libraries statically is a bad idea. It bloats the application file size (not much of a concern in most cases, except for people with little Internet bandwidth), bloats the application size in memory (that's more of a concern in practice), and means that your application will stay stuck with all the bugs from the version you linked with. Link your libraries dynamically so that your users will benefit from the bug fixes to the libraries, especially the security fixes.
Furthermore, while you can run applications, there's the problem of packaging. Installing applications manually is a pain. If you don't distribute an RPM package for CentOS, and a deb package for Ubuntu, you do your users a disservice.
So you should generate proper packages for all distributions. You can run an application built for Ubuntu on CentOS, with more or less effort depending on library requirements, but you can't deploy an application built for Ubuntu on CentOS.
add a comment |
You can run an application compiled for one Linux distribution on any other distribution, as long as that other distribution has the required libraries available. The problem in practice is usually that different distributions ship different versions of libraries at a given point in time.
Linking libraries statically is a bad idea. It bloats the application file size (not much of a concern in most cases, except for people with little Internet bandwidth), bloats the application size in memory (that's more of a concern in practice), and means that your application will stay stuck with all the bugs from the version you linked with. Link your libraries dynamically so that your users will benefit from the bug fixes to the libraries, especially the security fixes.
Furthermore, while you can run applications, there's the problem of packaging. Installing applications manually is a pain. If you don't distribute an RPM package for CentOS, and a deb package for Ubuntu, you do your users a disservice.
So you should generate proper packages for all distributions. You can run an application built for Ubuntu on CentOS, with more or less effort depending on library requirements, but you can't deploy an application built for Ubuntu on CentOS.
You can run an application compiled for one Linux distribution on any other distribution, as long as that other distribution has the required libraries available. The problem in practice is usually that different distributions ship different versions of libraries at a given point in time.
Linking libraries statically is a bad idea. It bloats the application file size (not much of a concern in most cases, except for people with little Internet bandwidth), bloats the application size in memory (that's more of a concern in practice), and means that your application will stay stuck with all the bugs from the version you linked with. Link your libraries dynamically so that your users will benefit from the bug fixes to the libraries, especially the security fixes.
Furthermore, while you can run applications, there's the problem of packaging. Installing applications manually is a pain. If you don't distribute an RPM package for CentOS, and a deb package for Ubuntu, you do your users a disservice.
So you should generate proper packages for all distributions. You can run an application built for Ubuntu on CentOS, with more or less effort depending on library requirements, but you can't deploy an application built for Ubuntu on CentOS.
answered Jul 23 '16 at 14:05
GillesGilles
534k12810791596
534k12810791596
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f297789%2frun-application-built-on-ubuntu-on-centos%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Usually no problem, if the Ubuntu that was building the application has a matching or older libc6 (The CentOS libc name is glibc.) Please test this. ... Installing to CentOS : Build an
rpmpackage with the app result :/usr/[??]/– Knud Larsen
Jul 23 '16 at 12:35
1
Same architecture I assume? Also relatively similar kernel versions? In that case static compiling should help but you should edit your question to be more specific before we can give you better and definitive answers.
– phk
Jul 23 '16 at 12:45
I'm not sure about kernel versions (I'll have to check that), and the architecture is the same. I also edited the original post with more info.
– rndm
Jul 23 '16 at 13:46