For anything that is more complex than a statically linked hello world, the answer is probably no.
Without testing it on distribution X, assume the answer is no for X.

• a few popular distributions for the field of use of your software (desktop, server, embedded, ...)

• the latest version of each

• The package of a tool/library you need is named differently across distributions and even versions of the same distribution

• The libraries you need are too new or too old (wrong version). Don't assume just because your program can link, it links with the right library.

• The same library (file on disk) is differently named on different distributions, making linking impossible

• 32bit on 64bit: some non-essential 32bit library is moved into an extra package apart from the 32on64 environment, so you have an extra dependency just for this case.

• Shell: don't assume your version of Bash. Don't assume even Bash.

• Tools: don't assume some non POSIX command line tool exists anywhere.

• Tools: don't assume the tool recognizes an option just because the GNU version of your distro does.

• Java: are you really sure your program runs on IBM's JRE as shipped with SLES without testing it?

Is linking statically (or: include all the libraries you need) a solution? Unfortunately, the answer is probably no either.

• Security: you shift the responsibility to update the libraries from the user of your software to yourself.

• Size and complexity: just for fun try to build a statically linked GUI program.

• Interoperability: if your software is a "plugin" of any kind, you depend on the software which calls you.

• Library design: if you link your program statically to GNU libc and use name services (getpwnam() etc.), you end up linked dynamically against libc's NSS (name service switch).

This answer was first written for the more general question "will my binary run on all distros", but it addresses statically linked binaries in the second half.

For anything that is more complex than a statically linked hello world, the answer is probably no.
Without testing it on distribution X, assume the answer is no for X.

• a few popular distributions for the field of use of your software (desktop, server, embedded, ...)

• the latest one or two versions of each

• The package of a tool/library you need is named differently across distributions and even versions of the same distribution

• The libraries you need are too new or too old (wrong version). Don't assume just because your program can link, it links with the right library.

• The same library (file on disk) is differently named on different distributions, making linking impossible

• 32bit on 64bit: the 32bit environment might not be installed or some non-essential 32bit library is moved into an extra package apart from the 32on64 environment, so you have an extra dependency just for this case.

• Shell: don't assume your version of Bash. Don't assume even Bash.

• Tools: don't assume some non POSIX command line tool exists anywhere.

• Tools: don't assume the tool recognizes an option just because the GNU version of your distro does.

• Kernel interfaces: Don't assume the existence or structure of files in /proc just because they exist/have the structure on your machine

• Java: are you really sure your program runs on IBM's JRE as shipped with SLES without testing it?

Is linking statically (or: bundling all the libraries you need with your software) a solution? Even if it works technically, the associated costs might be to high. So unfortunately, the answer is probably no either.

• Security: you shift the responsibility to update the libraries from the user of your software to yourself.

• Size and complexity: just for fun try to build a statically linked GUI program.

• Interoperability: if your software is a "plugin" of any kind, you depend on the software which calls you.

• Library design: if you link your program statically to GNU libc and use name services (getpwnam() etc.), you end up linked dynamically against libc's NSS (name service switch).

• Library design: the library you link your program statically with uses data files or other resources (like timezones or locales).

For all the reasons mentioned above, testing is essential.

• Get familiar with KVM or other virtualization techniques and have a VM of every Distribution you plan to support. Test your software on every VM.

• Use minimal installations of those distributions.

• Create a VM with a restricted instruction set (e.g. no SSE 4).

• Statically linked or bundled only: check your binaries with ldd to see whether they are really statically linked / use only your bundled libraries.

• Statically linked or bundled only: create an empty directory and copy your software into it. chroot into that directory and run your software.

For anything that is more complex than a statically linked hello world, the answer is probably no.
Without testing it on distribution X, assume the answer is no for X.

If you want to ship your software in binary form, restrict yourself to

• a few popular distributions for the field of use of your software (desktop, server, embedded, ...)

• the latest version of each

Otherwise you end up with houndreds of distribution of all sizes, versions and ages (ten year old distribution are still in use and supported).

Test for those. Just a few pointer on what can (and will) go wrong otherwise:

• The package of a tool/library you need is named differently across distributions and even versions of the same distribution

• The libraries you need are too new or too old (wrong version). Don't assume just because your program can link, it links with the right library.

• The same library (file on disk) is differently named on different distributions, making linking impossible

• 32bit on 64bit: some non-essential 32bit library is moved into an extra package apart from the 32on64 environment, so you have an extra dependency just for this case.

• Shell: don't assume your version of Bash. Don't assume even Bash.

• Tools: don't assume some non POSIX command line tool exists anywhere.

• Tools: don't assume the tool recognizes an option just because the GNU version of your distro does.

• Java: are you really sure your program runs on IBM's JRE as shipped with SLES without testing it?

Bonus:

• Instruction sets: binary compiled on your machine does not run on older hardware.

For anything that is more complex than a statically linked hello world, the answer is probably no.
Without testing it on distribution X, assume the answer is no for X.

If you want to ship your software in binary form, restrict yourself to

• a few popular distributions for the field of use of your software (desktop, server, embedded, ...)

• the latest version of each

Otherwise you end up with houndreds of distribution of all sizes, versions and ages (ten year old distribution are still in use and supported).

Test for those. Just a few pointer on what can (and will) go wrong otherwise:

• The package of a tool/library you need is named differently across distributions and even versions of the same distribution

• The libraries you need are too new or too old (wrong version). Don't assume just because your program can link, it links with the right library.

• The same library (file on disk) is differently named on different distributions, making linking impossible

• 32bit on 64bit: some non-essential 32bit library is moved into an extra package apart from the 32on64 environment, so you have an extra dependency just for this case.

• Shell: don't assume your version of Bash. Don't assume even Bash.

• Tools: don't assume some non POSIX command line tool exists anywhere.

• Tools: don't assume the tool recognizes an option just because the GNU version of your distro does.

• Java: are you really sure your program runs on IBM's JRE as shipped with SLES without testing it?

Bonus:

• Instruction sets: binary compiled on your machine does not run on older hardware.

Is linking statically (or: include all the libraries you need) a solution? Unfortunately, the answer is probably no either.

• Security: you shift the responsibility to update the libraries from the user of your software to yourself.

• Size and complexity: just for fun try to build a statically linked GUI program.

• Interoperability: if your software is a "plugin" of any kind, you depend on the software which calls you.

• Library design: if you link your program statically to GNU libc and use name services (getpwnam() etc.), you end up linked dynamically against libc's NSS (name service switch).