Hi, a while back I recall if I build a C++ project on Centos it won't run on SuSE. Is there a way to specify the build options when running "g++" such that the final executable will run on all flavors of Linux, or specific distro of Linux?

There is no binary compatibility between linuxes. That's why developers distribute source packages.

I wouldn’t phrase it this way. In principle something compiled for Cent OS will also run on openSUSE – as long as it’s the same CPU type. We bought several applications as binaries only and they run without problems. Missing libraries (or a wrong version of it) is one issue seen often. But it can be solved.

With more subtleties between CPU types, it can be necessary to chose a common factor during compilation. E.g. SSE4 is different between AMD and Intel as far as I know. In this case telling the compiler to use only 64bit commands but no SSE4 at all can help.

Mozilla seem to do OK packaging Firefox to run on different distros. Don't they do this by including the majority of the library files required in the package?

I would consider much more than just the CPU type in the matter of cross-architecture compatibility. There are all kinds of layers of software, as well (kernel + drivers, standard C library, threading models, userspace libraries, etc). It's true that binaries are often cross-platform compatible, but that isn't guaranteed. Someone mentioned that Mozilla distributes cross-platform binaries as an example of compatibility. I would also point out that Mozilla browsers are by far the least reliable software I use on Linux. I don't know if there is a connection or not.

--- rod.

I think you're either unlucky or projecting some subconscious selection bias. That's not to say Mozilla products don't have problems, just that all software has problems and I've been using the Nightly build of Firefox on both 32 bit and 64 bit for a long while now with no reliability issues at all.
I think of it more that applications are written against a set of libraries and any distro with those libraries (and perhaps some going forward) can then run the application. Where the library is proprietary or a fixed version ought to be used it's bundled with the application.
There are far too many applications available which are not distro specific to go around saying things like:The above is demonstrably not true.

But there are different versions/revisions of libraries, and by definition, those are not all the same. Yes, it mostly works, but there are no guarantees. I have seen occasions where it demonstrably does not work. It would be reasonable to imagine that there are even more cases where applications appear to work, but either subtly misbehave under certain conditions, or crash without evidence of the cause.

--- rod.

Therefore libraries have a major and minor revision number – or better: should have. This way you can have several versions installed, and the correct one is found by the compiled in soname to get the correct number of the major version used during compilation. Unfortunately are not all libraries following this scheme.

In general, compiling your application with static libraries and in 32 bit will let it run on the VAST majority of regular Linux distros on standard hardware (not ARM, etc). Dynamic libraries and 64/32 bit incompatibilities are often what get you into trouble when distributing a pre-compiled binary.

I have a code that I compile for distribution in 32 bit with static libs. I've run it on RHEL, Fedora, CentOS, OpenSUSE, Ubuntu, Mint, Debian, and probably one or two more that I'm forgetting. The only machine I've found to date that won't run it is an old Fedora 4 box, because, according to the error, the kernel is too old.

FYI: linux runs on dozens of different achitectures/processors, so binary compatibility is an illusion...

Your statement is a platitude.
Of course, without a virtual machine, a program written for one architecture will not work on a other. However, that does not mean that "binary compatibility is an illusion" it means that you compile for an architecture.
The original post may have been a little uspecific but your posts are meaningless and trite.

The OP didn't ask about compiling for different architectures, he specifically asked about compiling for different distributions. You're "answering" a question that was never asked.

I didn’t dare to mention it before, but if we are getting into it: I was thinking of mentioning Mac OS X inherited fat binaries from NeXTSTEP to include PowerPC and Intel code. Nowadays it’s used to have 32 and 64 binaries in one binary for the Intel architecture (selectable with “open in 32 bit mode” in the info window of a file, and some even show “open with Rosetta” in addition for the PowerPC code).

And it looks like discussions about fat binaries are going on for Linux too.

Maybe this could also be used to include binaries for different versions of the kernel for one and the same architecture or a binary for Intel/AMD64/SSE4 in different flavors.

Okay guys, you won, you certainly know better than me what 'all flavors on linux' in the original post means. EOF.