> On 11 May 2020, at 13:11, Richard Sandiford <richard.sandiford@xxxxxxx> wrote: > > The reason this isn't done is that the sysroot is often intended to be > deployed as the real "/" sysroot on a separate target machine. (At least, > that's a common use case for embedded targets.) Using things like > /lib64/ld-linux-x86-64.so.2 is correct for that use case. Right. At a second thought, my use case is somehow similar, I want to have my distribution fully relocatable, i.e. to be able to unpack an archive in any folder, and run from there. I already have cross compilers for arm-none-eabi-gcc and riscv-none-embed-gcc that work like this, and it would be nice to have a native gcc behave similarly. > I don't know of any easy off-the-shelf way of doing what you want to do, > sorry. Maybe one option would be to use "gcc -dumpspecs" to get the > built-in specs, edit the dynamic-linker paths, and install the edited > file as "specs" in the lib/gcc/<target>/<version> directory of the > GCC installation. For fixed location distributions this might be a reasonable workaround, since it can be done at build time, but for relocatable distributions it is less convenient, since it requires a post-install step to update the file after the location is known. But probably the requirement of using the loader provided by the custom glibc is a bit extreme and not really needed; I don't know how compatible are the loaders, maybe the existing loader available in the host system is able to load the new shared libraries provided by the custom glibc. Thank you, Liviu
