File: versions.txt
base-0	patch-1
Line 1	Line 1
Version Skew, Version Lock, and The Reason For HEAD and STABLE	ABI Compatibility or Why We Have STABLE And HEAD
GNU libc has recently had a major change in the way symbols are	GNU libc has recently had a major change in the way symbols are
exposed to programs. There are numerous sources where you can learn the details of what's changed, but for purposes of this rant, this is all you need to know: * The dynamic linker from GNU libc 2.2.x cannot load libc.so from GNU libc 2.3.x * The dynamic linker from GNU libc 2.3.x cannot load libc.so from GNU libc 2.2.x GNU libc 2.2.x vs. 2.3.x is the only pair of library version we've encountered that causes trouble, but the problem is a general one. We refer to this sort of mismatch as *version skew*. If the version skew between your build host and the libraries you are building is too much, then your build /will/ fail. As a result, the LNX-BBC source tree has to build a version of GNU libc which matches the version installed on the build host. This is *version lock*, and there is no known workaround. Many systems still use GNU libc 2.2.x, including gargoyle.lnx-bbc.org, which is where our nightly builds take place. However, a growing number of platforms have switched to GNU libc 2.3.x, including Debian testing, which many of the LNX-BBC developers use. Because of this, the LNX-BBC source was branched on March 29th. CVS checkouts from HEAD will build an LNX-BBC which uses libc 2.3.1, which means that HEAD can only be built on systems running libc 2.3.x. The new branch, STABLE, will build an LNX-BBC with libc 2.2.5 on systems running libc 2.2.x. To complicate matters, recent versions of GNU libc and GCC have a codependent relationship. GCC 2.95.x cannot build GNU libc 2.3.x, and GCC 3.2.x cannot build GNU libc 2.2.x. HEAD and STABLE therefore also build different versions of GCC. If you are trying to build from HEAD on a system with GNU libc 2.2.x, stop. If you are trying to build from STABLE on a system with GNU libc 2.3.x, stop. Fixing this is a long-term goal. *long-term*. I can't stress this fact enough... ----8<---- _ ___ _ _ ____ _____ _____ ____ __ __ | | / _ \| \ | |/ ___| |_ _| ____| _ \| \/ | | | | | | | \| | | _ _____| | | _| | |_) | |\/| | | |__| |_| | |\ | |_| |_____| | | |___| _ <| | | | |_____\___/|_| \_|\____| |_| |_____|_| \_\_| |_| ----8<---- If you want to attempt to solve the version skew problem, understand that you are undertaking a task which pushes the limits of operating systems research. If you try it at all, do it in an office... at university... with grant money in your pocket. Do not try this at home.	exposed to programs. Version 2.2 of glibc was the last one which used unversioned symbols. The new glibc, version 2.3, uses versioned symbols. As a result, glibc 2.2's dynamic linker is unable to load glibc 2.3's libc and vice versa. The LNX-BBC build system as it existed in March 2003 (and is still the case today in the STABLE branch) relied on the dynamic linker in /lib to perform symbol resolution for all shared libraries as binaries were built. This meant that we could not expect our build system, gargoyle.lnx-bbc.org, to build glibc 2.3 and then successfully link binaries against it. We created the STABLE branch at that time which retains the older version of glibc (and also gcc, for similar reasons). This has freed us to try out whatever changes might eventually solve the problem in the HEAD branch. The solution we have settled on is to cross-compile the entire LNX-BBC, allowing us to treat the LNX-BBC ISO as an embedded system. Using this cross-compilation scheme, we have been able to build and link *some* binaries against glibc 2.3 on systems using glibc 2.2. However, many other packages use faulty mechanisms to determine whether or not they are being cross-compiled, or simply don't support cross-compilation, and so it will probably be a while before we can resolve this issue. Until then, be aware that if you are attempting to build an LNX-BBC ISO on a system which uses glibc 2.2.x, a cvs checkout from the HEAD branch will *definitely not work*. A checkout from STABLE may or may not work, but we can as least provide reasonable suggestions that might make it work. If you are building on a system running glibc 2.3.x, please use the HEAD branch but be aware that certain packages are currently failing, and you will not get an ISO.