Hello, Creating a cross-platform application in any binary language requires you to recompile for each native OS. This is all good and well, and I have no problem compiling for each and every native OS I wish to support. But there are loads of distros of linux, is there anyway i can create a binary/library that runs on the greater majority of these? Is there any way to make it compatable with ALL of these? I have seen netscapes installer for instance, which appears to run on most distros without any need to compile. Releasing the source code to commercial applications is not an option, so I cant just compile during installation. Thanks Richard

Usually if something runs in one distro, it will run on another.

without the need for a recompile? Then how come incrementing the clib or kernal oftain times breaks apps?

There''s an entire forum dedicated to Unix-like systems. Use it.

Moved to Everything Unix.

quote: Original post by PaulCesar
without the need for a recompile? Then how come incrementing the clib or kernal oftain times breaks apps?

It does not.

The kernel is always ABI compatiable.

glibc is also.

There were two notable exceptions in recent memory:

the libc -> glibc transition (not likely to happen again)

the C++ ABI transition (COULD happen again, but avoidable by staticly linking any C++ libraries you need, and still not horribley hard to deal with jsut by releasing two binaries)

Thanks for all your help, sorry about the forum choice.

There''s two things to pay attention to for Linux user apps rights now. The glibc version (almost all are glibc23 today) and whether it''s a LinuxThreads or NPTL system.

The 2.4 kernel uses LinuxThreads and the 2.6 kernel (with a rebuilt system) can use NPTL. RedHat is a patched 2.4 kernel with a NPTL build.

Sorry for hijacking the thread. But what/when was the C++ ABI transition? Is this referering to libstdc++ 3.4 transition??

Wrt to kernel ABI...
Was there ever one? I thought kernel modules between kernel versions were binary incompatible?

quote: Original post by ugenn
Sorry for hijacking the thread. But what/when was the C++ ABI transition?

When GCC changed from 2.x to 3.x the C++ ABI was completely changed to follow a new industry standard (the previous ABI had some quirks, so it a change was necessary even there there wasn''t a standard to follow). Any application or library using the new ABI cannot link with anything using the old ABI. Since just about everything written in C++ for the platforms where GCC is commonly used should use the newer 3.x ABI, it''s not really an issue anymore. C programs and libraries are/were not affected.

quote: Original post by ugenn
Is this referering to libstdc++ 3.4 transition??

No, multiple versions of libstdc++ can coexist. As long as the libstdc++ binaries are using the 3.x ABI, everything else using the 3.x ABI can utilize them.

quote: Original post by ugenn
Wrt to kernel ABI...
Was there ever one? I thought kernel modules between kernel versions were binary incompatible?

Yes, Linux itself doesn''t have any guarantees about binary compatibility. I suppose what could have been meant was that your application shouldn''t normally need to do anything with the kernel itself and should therefore not be affected by changes in the kernel. Modules and such that "run" in kernel-space have it harder, since they obviously do need to interact with the kernel.

quote: Original post by Null and Void
When GCC changed from 2.x to 3.x the C++ ABI was completely changed to follow a new industry standard (the previous ABI had some quirks, so it a change was necessary even there there wasn''t a standard to follow). Any application or library using the new ABI cannot link with anything using the old ABI. Since just about everything written in C++ for the platforms where GCC is commonly used should use the newer 3.x ABI, it''s not really an issue anymore. C programs and libraries are/were not affected.

I experienced broken behavior / missing symbols when upgrading from 3.3.x -> 3.4 (libstdc++.so.6)