[SOLVED] How to make C++ projects computer independent. Detailed instructions needed.
ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Then make sure you are using a standard-compliant C++ compiler and make sure in the programs you use only standard C++ library - its contents and behavior are mandated by the C++ standard and thus is computer-independent.
Then make sure you are using a standard-compliant C++ compiler and make sure in the programs you use only standard C++ library - its contents and behavior are mandated by the C++ standard and thus is computer-independent.
That ensures that the source code is computer-independent, but not that the compiled binary is computer-independent.
That ensures that the source code is computer-independent, but not that the compiled binary is computer-independent.
Correct - but, as stated earlier. different operating systems have different libraries and different executable file formats.
Yes, static linking is the way, but, again, as stated earlier, it is not in practice always possible; also in practice sometimes part of the program remains dynamically linked.
Yes, static linking is the way, but, again, as stated earlier, it is not in practice always possible; also in practice sometimes part of the program remains dynamically linked.
Yes, sometimes a statically linked executable still won't run on a user's distro, and sometimes a program is so convoluted that compiling it with static libs isn't possible, but shouldn't we wait to see if that's even a problem for the OP before dismissing it outright? He's not looking for a way to compile any program so that it can run on any OS, he's looking for a way to compile one specific program so that it can run on his computer and his friend's computer (also running Linux). That's it. It doesn't need to be any more complicated than that. If it's a relatively simple program (which he has stated it is) and both machines are running relatively modern OSs (released in the last 5 years), then I see no reason why compiling with static libs and in 32-bit (if necessary) won't solve his problem.
Last edited by suicidaleggroll; 06-13-2013 at 09:17 PM.
... He's not looking for a way to compile any program so that it can run on any OS, he's looking for a way to compile one specific program so that it can run on his computer and his friend's computer (also running Linux). That's it. ...
Then both the OP and the friend should install g++ and compile from source. That's it.
Then both the OP and the friend should install g++ and compile from source. That's it.
lol, an engineer's reply
Being an engineer myself I appreciate the irony, and I could see myself giving the exact same answer to a similar question in another situation, but it sounds like the OP is looking for a single executable he can give to his friend to run.
I have several pieces of software under my control that are used to interface with proprietary hardware, that need to be distributed to customers running any number of Linux setups. Obviously offering the source with a makefile they can use to build it for their system would be ideal, but it's not an option since the source code is controlled. Building it with static libs in 32-bit and distributing the resulting binary covers 99% of the use-cases, and I deal with the exceptions on an individual basis (of which there have been exactly zero).
... it's not an option since the source code is controlled. ...
Deviating from the OP's question - you can distribute assembly produced by gcc/g++. Binary can be disassembled anyway, so you retain the same level of control, but let your customers link locally.
Yes, sometimes a statically linked executable still won't run on a user's distro, and sometimes a program is so convoluted that compiling it with static libs isn't possible, but shouldn't we wait to see if that's even a problem for the OP before dismissing it outright? He's not looking for a way to compile any program so that it can run on any OS, he's looking for a way to compile one specific program so that it can run on his computer and his friend's computer (also running Linux). That's it. It doesn't need to be any more complicated than that. If it's a relatively simple program (which he has stated it is) and both machines are running relatively modern OSs (released in the last 5 years), then I see no reason why compiling with static libs and in 32-bit (if necessary) won't solve his problem.
THANK YOU! Finally someone understands! Honestly, going to far with a question is the problem here. I did not want him to have to run compilations, mainly because he now has my source-code. The static options worked for my situation, it may not work for other programs though, this works for now, yes, IT DOES WORK. That's all, marking as solved.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.