File: versions.txt
base-0	patch-1
Line 4	Line 4
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	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.	glibc 2.3's libc because it can't resolve the library's versioned symbols and 2.3's linker can't load the 2.2 library because it expects to find versioned symbols in the library. This is a specific example of a class of problem that has come up before, which we've been calling /version skew/.
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.	Version skew with GNU libc is a major problem for us because we don't use the LNX-BBC to build LNX-BBC ISOs. That is to say, the LNX-BBC platform is not self-hosting. Most systems, such as the Debian or Red Hat distributions, can tolerate temporary differences because the new libc is installed before anything is compiled against it. The LNX-BBC is built all in one pass, without installing anything.
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.	Our 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. Because the LNX-BBC libc is never installed on the build system, we cannot expect our build system, gargoyle.lnx-bbc.org, to build glibc 2.3 and then successfully link binaries against it without employing significant tricks. We created the STABLE branch at that time which retains the older version of glibc (and also gcc, for similar reasons). The tight coupling that exists between the STABLE branch and the system that's used to build it is a problem related to version skew which we've called /version lock/, and the build system in the STABLE branch has that problem. With the creation of the STABLE branch to continue producing working nightly builds, we are free to try out whatever changes might eventually solve the version lock problem in the HEAD branch. The solution we have settled on is to cross-compile the entire LNX-BBC, allowing us to properly treat the LNX-BBC ISO as an embedded system.
Using this cross-compilation scheme, we have been able to build and	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.	link *most* binaries against glibc 2.3 on systems using glibc 2.2. However, certain major components (XFree86 and Perl, among others) have proven very resistant to cross-compilation. These packages use faulty mechanisms to determine whether or not they are being cross-compiled, or simply don't support cross-compilation. These few stubborn packages are the sole reason the HEAD branch does not currently build on any system running GNU libc 2.2. It will be some time before these issues are fully resolved.
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.	Until then, if you are attempting to build an LNX-BBC ISO, there are two avenues by which you can do it. If you are trying to build on a system which uses glibc 2.2.x, you must use the STABLE branch. STABLE is known to succeed on Debian 3.0 in particular, and if you have problems building STABLE on other glibc 2.2.x systems, we can provide reasonable suggestions that might make it work. If you are building on a system running GNU libc 2.3.x, use HEAD. In recent weeks, HEAD has consistently succeeded in producing working ISOs on Debian sarge, and sometimes on Debian sid. Building HEAD on other distributions probably won't work, but if you're willing to try, we would really like your feedback.