How to make C++ projects computer independent. Detailed instructions needed.
 

Title says it all. I have "le project" that I want to compile on my computer. Send it to a friend on a different computer but same OS (linux) and it work. Most of the time it will say "Cannot Run this program!". It would also be good to know if there was any way to make it OS independent, but Windows will most-likely complain. So just this for now. How to package a system independent C++ program.

C++ is not intended for that...Java is. Dotnet should be, but...I dont trust it...at all.
What you need is a runtimer that is made for the target OS/platform and program against that...
The thing lies in the compile...at compile time, the links get made for the OS/platform in use at compile time.
Just what program is it, by the way?

Thor

If you compile it with static libraries there's a good chance your Linux friend will be able to run it (possibly 32-bit with static libs if you're running a 64-bit OS and he's not). Getting it to run on another OS is another matter entirely though, and needs a cross-platform language more like Java (as mentioned above).

depends on the project itself. Creating GUIs will make it really hard, probably you will need wxWindows or similar.
You cannot have system independent packages, because all the installable packages are designed for a specific os. Linux and MS Windows are really different.
You can also try wine on linux

Mmm...well anything is possible. I understand Java is better at this than C++, but C++ does things that Java won't be able to do. It would be good to know how to do this later on when the program gets more complicated. No GUI is yet implemented. Do you have an example of a runtimer that I could use with the default packages? Its a multi-utility program, including a study tool, advanced calculators, file editing, and so on.

How would I use static libraries. Include the files with the program that it compiles from? Running on another OS is later to be implemented.

I am eventually going to use GTK for GUI, not wxWindows. Again, the OS is later to be decided.

Set "-static" in the compiler flags

another issue not mentioned is that between windows, mac, linux, bsd etc.. they all use different executable formats

linux,bsd and a lot of *NIX operating systems uses the ELF binary format,
mac uses the Mach-O format
windows uses the PE (portbale exececutable) format

so right there, you would still have to compile the program for the target system, not to mention each system has a different API, which would require porting the program.

You will get the best portability with using something like Java or .NET/Mono.
If you want to stick with C++ you should try to use an application framework that is available on all platforms you want to provide your software for, for example Qt. You still will have to compile for any platform you want to use, but the work need to port to a different platform should be as minimal as possible if you want to use C++.

The best ways to have an application that runs on multiple operating systems and distros:

• Write as much of it as you can in a standardized language, isolate code for OS-specific things (like GUIs), and compile/link a version for each OS or distro. Or, provide the source code and hope someone is enterprising enough to compile it for Windows and provide it for download.
• Write the application using a framework that has already done that, e.g. Python, Java, etc.

Static linking isn't a scalable solution because it will give you massive binaries. Also, although static linking is feasible in theory, in practice it's a huge headache and it almost never works like you want it to. That's because static "libraries" are merely archives of .o files, so you have to specify them in the right order and you have to specify every dependency recursively. Dynamic linking doesn't have that problem because a library you link to references its dependencies. Lastly, some functionality simply isn't available for static linking.

Some people just write their code for Linux and require that the user run it with cygwin. That's acceptable for some things, but it's not a very graceful solution in most cases. It's really meant for software that from the beginning wasn't intended to run on Windows.

As a final point, remember how much of a pain it is to even have the capability of compiling C++ code on/for Windows and OS X, regardless of if your code can compile for those OSes.

Kevin Barry

"Title says it all" - no, it doesn't.

Did you mean OS-independent ? CPU architecture independent ?

Mhm...that is why I put text in my thread along with the title, for people like you.

That would be nice, but OS independent is NOT what I am looking for.

CPU architecture may be what I am looking for. What I am looking for specifically is a way to make C++ projects that are built on linux OS to run other linux OS's, different computers, different systems, different, but the same general linux OS. I don't understand what is confusing to you here.


Thank you suicidaleggroll. This is good information, I will try this.


NOT looking for OS independence.


Thanks for everyone that has replied. Again, I am not looking for OS independence, NOT Windows to Mac to Linux and back, No. Just Linux to linux. One compilation that will work for most linux computers. I, again, I UNDERSTAND that Java and other languages have already done this, that is why I am trying to make it work for C++. Its a headache and painful, yes, but someone should figure out how to do it, thats what I am trying to do.

You make it sound MUCH worse than it is in reality. In fact your post makes it sound completely impractical for almost any application, when I have found quite the opposite to be true. In fact I have yet to run into a problem statically linking any program I've written so it can run on multiple Linux machines, and I have never run into the problem you describe here:

you have to specify them in the right order and you have to specify every dependency recursively

While what you say may be true for certain massive applications with hundreds of dependencies, or applications that are linking in other static libraries that you've compiled, that are based on other static libraries that you've compiled...I think that's more the exception than the rule.

Given that we've have had the exact opposite experiences here, I'd say it's debatable at best. I'm sure we just write completely different types of software.That's actually the opposite of what it sounded like in your other two posts, so confusion is understandable.

Kevin Barry

That sounds likely. I mostly write analysis and data processing software that's all command line driven and uses a limited set of libraries (lapack, gpstk, etc). I'm sure GUI software is quite a bit different.

You apparently misunderstand English.

I have a laptop and a desktop computer. One is Intel-based, the other - AMD-based. Choosing 'i586' architecture during compilation makes my program run on both computers. So, on the set of the two computers the program is computer-independent.


OTOH, your program might need, say, 16GB of virtual memory. And two computers with identical motherboards and identical CPUs may be different from the point of the program - because in one of them there will be not enough virtual (let alone physical) memory.