linking against another libc

[Jason Lunz <j at falooley dot org>]

Please let me know if this is the wrong list to be asking on. It's hard
to know whether the glibc or binutils lists might be more relevant.

I'm trying to build a disk image to be stored on a flash card for a
single-purpose machine. Both the host machines and the target machine
with flash disk are i386. Because I want the contents of the flash disk
to be strictly controlled, I'm compiling glibc myself for it and
installing it to an image/ directory which will eventually become the
flash image.

Where I'm running into trouble is making sure that programs compiled on
the host machine link against this new copy of glibc and not the one on
the host. I compiled gcc and binutils as a cross-compiler/toolchain with
"--target i386-custom-linux", using the image/ copy of glibc for the
target machine's headers. This worked ok, but the resulting
i386-custom-linux-* tools don't use paths to the glibc libraries in the
image when linking. For example, a _native_ gcc compiling "hello world"
invokes the linker like this:

/usr/lib/gcc-lib/i386-linux/2.95.4/collect2 -m elf_i386 -dynamic-linker
 /lib/ld-linux.so.2 -o hello /usr/lib/crt1.o /usr/lib/crti.o
 /usr/lib/gcc-lib/i386-linux/2.95.4/crtbegin.o
 -L/usr/lib/gcc-lib/i386-linux/2.95.4 /tmp/ccRsrJKt.o -lgcc -lc -lgcc
 /usr/lib/gcc-lib/i386-linux/2.95.4/crtend.o /usr/lib/crtn.o

But the "cross-compiler" I compiled doesn't have paths to my
custom-compiled glibc components. For example, the crt*.o arguments to
collect2 don't have any path, which of course fails.

Am I even going about this the right way? How do I install glibc into a
machine image subdirectory and then compile other programs to link
against this custom image rather than things on the host system?

thanks, Jason