I have to compile my QT and cpp applications and deliver the binary that will run on various distros.

Please guide me for following:
1. Which g++ version should I use? (backword compatibility should provide)
2. Which OS/Distro should I use for development?

I think the libraries that you link to are more important than the compiler version, elf has been standardized, and the gnu compilers follow the standards, so if I were you I would take the latest stable g++ version. Since there really is no excuse to not have the latest libraries, I would recommend compiling against the latest stable versions of the libraries involved. For optimal portability you might want to link to 32-bit libs, those can be used on 32 and 64-bit distros.
The one that you like best. There is no 'best' distro for anything (cue angry posts from slackers), just keep using what you are using now, although it would of course be a good idea to use kde.
The best way to ensure interdistributional portability is freely-licensed distribution of uncompiled source code, preferably on a location of prominence, such as sourceforge or github for that ensures the maintainers of the distributions will be able to package and compile your stuff in such a way that it is optimized for their distros.

Thanks for reply...

When I compile my sample program on SuSE 7.3 machine and run on Fedora 16 and above it says libstdc++-libc6.2-2.so.3 not found.

When I compile sample program on Fedora 16 and try to run on SuSE 7.3 it says floating point exception.

Now I need to run this sample application on almost all major Linux distribution. I am going to release binary only no source.

How i will get backward compatibility with latest version of library?
Suppose i used g++ 4.6.2 or such latest version then does in future i will get backward compatibility?

FYI:
SuSE 7.3: kernel: 2.4.10-4GB g++: 2.95.3 20010315 (SuSE)
Fedora 16: g++ version 4.6.2 20111027 (Red Hat 4.6.2-1) (GCC)

Hi nil_fergi!

My understanding is that there is a substantial range of different levels of hardware and software technology in use throughout the World. So I feel that trying to achieve a degree of backward compatibility is admirable. But trying to be backward compatible, all the way back to technology that was new when "puppies were the oldest animals"/"Dinosaurs ruled the Earth", might be a little overly ambitious.

You mentioned SUSE 7.3, yet AFAIK, the paid SUSE Linux distros. are at least in version 11.*, and openSUSE is in the 12.* versions. I was buying SUSE Linux up through at least the 8 or 9 series, and I'm currently running 11.* and 12.* openSUSE distros. If I recall correctly, at some point, support was dropped for some of the older CPU's, and if you try to go back from 2.6 kernel versions to 2.4 and such, I believe you'll find some meaningful differences.

I would suggest trying to target the least common denominator, so to speak, try to get cross-distro. compatibility with some of the more recent distro's first. Depending on how wide a range of distros. you want to include, you might find that even that is a rather substantial job.

Given the wide range of capabilities pre-built for different distros., I feel one rather effective approach for cross-distro. support, can be providing full source and using something like a configure command.

So if you're not going to release source, there can be some unfortunate technical issues.

Also, if your source makes use of open source binaries, including some libraries, there can be some potential legal issues.

Since so many distros./etc., have their own directions, emphasize so many different concepts, have so many different "tweaks"/"extensions", you might want to try to use a rather minimal/vanilla Linux on which to get your application working. Perhaps a fairly simple LFS ( Linux From Scratch ) set up. If you can get your program working in a simple environment, so it doesn't depend on the extensions, you might have the best chance of it working with the widest range of distros.

Of course that's only valid if your application isn't intended to work with some extension as a base! At the general level at which you've asked you're question, it's rather hard to give specific advice. If your program is somewhat general purpose like a GUI-based calculator, you may have a good chance of wide compatibility. If instead you're trying to write the ultimate auto-magical System Administration program, you'll be forced to handle all the environment-specific issues.

HTH.

Expecting the 2010 and 2000 versions of a compiler to do exactly the same things is over-optimistic! This is just Unix-land; unlike Windows-land, we expect people to have up-to-date software: after all, it doesn't cost them anything.

And that's another reason for not releasing binary only. If you've got the source code, at the best it will compile to give something usable on the user's system, at the worst someone can work out a patch to solve the problem. If it's binary, it'll be of limited use.

1 members found this post helpful.