I am currently working on building up a glibc-2.1 based distribution. To
date I have never built a distribution across libc versions - they have all
been libc5 based. Now, I have the problem of conflicting libraries.
I figured the easiest way to keep the different library versions seperate
was to build a cross-compiling environment for GNU Libc 2.1 based Linux.
So, I went about building a cross-development environment - I compiled
binutils-22.214.171.124.21, egcs-1.1.2, and glibc-2.1 exactly as if I was building
an environment to host Hurd (my last venture; it failed, btw). Binutils
and egcs were configured with --build/--host=i586-pc-linux-gnulibc and
--target=i586-pc-linux-gnu. Glibc 2.1 was compiled with
--build-i586-pc-linux-gnulibc1 and --host/--target=i586-pc-linux-gnu.
These builds went well, and I came out of the other side with what seemed
like a perfect cross-development environment.
So I picked out a little package to test this out. I built make-3.77,
once with a * configure line, and once with i586-pc-linux-gnu as the
host. This worked great. The first configure got me a make linked to
libc.so.5 and ld-linux.so.1, while the second one scored me a make linked
to libc.so.6 and ld-linux.so.2. For the next test I grabbed the bash
source. Every combination of configure commands and setting CC would
produce a binary linked to libc.so.5/ld-linux.so.1. The big problem here,
was every time my system was identified as i586-pc-linux-gnu! Are these
two target names too similar for configure to differentiate? Why did this
setup work really well during the build of my environment and why did it
not work after it was done? Is this intended autoconf behavior?
WARNING: Windows is unable to provide a .sig, rebooting...