Julian Elischer wrote:
Kris Kennaway wrote:
Carl Shapiro wrote:
FreeBSD Hackers,
I have a general question about the compatibility of FreeBSD binaries
within major releases. If I build a binary for a given release of
FreeBSD can I make a reasonable guarantee that the binary will run on
both previous and subsequent minor releases of the same major release?
In other words, if I build on FreeBSD 6.3 and do not rely on anything
unique to 6.3 (such as the presence of specific version strings) how
certain can I be that the code will or will not run on 6.2, 6.1 etc.?
Also, is this documented anywhere on the FreeBSD web site? The
closest thing I could find is the following guidance for driver
vendors which falls just short of answering my question:
http://wiki.freebsd.org/VendorInformation
(Too bad the fancy illustration is missing.)
Binaries compiled on a certain version of FreeBSD will continue to run
on later versions, but are not guaranteed to run on earlier versions
(and in fact *will* not run depending on the binary). This is because
over time the system libraries and kernel grow new features which may
be used by applications, so they will therefore fail to run if
executed on old systems that do not provide these features.
If your goal is to provide an application that runs on a range of
FreeBSD versions, then either build it for the oldest of these
versions, or provide multiple versions if there is a reason to do so
(e.g. if there have been major improvements in the OS that are
relevant to your application).
I agree in general, however we do make an attempt to keep ABI
compatibility within a release line, so that there is a high
probability that a binary compiled on a later one will run on
an earlier one as long as it does not rely on new features.
Actually we don't attempt to keep this form of ABI compatibility
(running 6.3 binaries on 6.0, for example), because it basically
precludes ever adding new functions to libc within a branch, or new
syscalls to the kernel. You are correct that often binaries will not
notice these accumulated changes though, or can be carefully constructed
to avoid them.
Kris
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
