Hi Matthew, Richard, Matthew Fortune <matthew.fort...@imgtec.com> writes:
> Richard Biener <richard.guent...@gmail.com> writes: >> On Thu, Dec 4, 2014 at 8:59 AM, Benda Xu <hero...@gentoo.org> wrote: >> > Hello, >> > >> > libc could be installed in a directory prefix. This patch provides a >> > way to specify such a prefix for gcc at configuration time. >> > >> > I have only tested the patch with glibc on amd64, x86 and arm. >> > It is logically straightforward. Please share your thoughts on it. >> >> I think you are supposed to use sysroots for that. @Richard, I could not. The sysroot does not affect location of the dynamic loader. There are use cases (see below) where the dynamic loader is at e.g. for x86 DL_PREFIX/lib/ld-linux.so.2. > This patch would appear to allow the ABI defined locations of a dynamic > linker to be changed which does not seem like a good idea. I.e. My > understanding is that the combination of arch+ABI+Clibrary indicates an > ABI defined absolute path to the dynamic linker as well as name of the > dynamic linker. I'd welcome any correction to that from someone who > lives and breathes this stuff. > I am under the impression that installing glibc with a prefix effectively > breaks the ABI paths and is primarily for testing and/or creating > sysroots for cross compilers and such forth. Such sysroots must be > installed to a target before being used or with qemu user-mode there is > an option to say where your sysroot is so that the dynamic linker can > be located from within that path. Thank you for pointing out the ABI specification. https://refspecs.linuxbase.org/LSB_1.2.0/IA32/spec/dynamiclinking.html The LSB specifies the Program Interpreter to be /lib/ld-lsb.so.1 You are right. But after all, the *INTERP* ELF field in Program Headers codes the dynamic linker (output of readelf -l /bin/ls on i386): Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align INTERP 0x000154 0x08048154 0x08048154 0x00013 0x00013 R 0x1 [Requesting program interpreter: /lib/ld-linux.so.2] This is not for cross compiling, and not for a chroot. The compiled programs are supposed to be loaded by the dynamic linker at DL_PREFIX/lib/ld-linux.so.2. The use cases are 1. Compiling new software on shared computing clusters as normal users. More often the host glibc-2.5 from RHEL 5 for example, becomes too old to compile out new programs, like >=openssl-0.9.8. The feasible solution is to *run* a glibc and its dynamic linker inside the user's own home directory. 2. A LTS environment insensitive to underlying infrastructure for dedicated software deployment. So that the environment could be copied to the subdir of a large variety of distributions, and run off-the-shelf with their own glibc and libstdc++. 3. Running GNU userland on Android-based mobile devices. The rootfs of Android is volatile initramfs. We had better to put the system in a directory other than /. https://www.gentoo.org/proj/en/gentoo-alt/prefix/usecases.xml https://wiki.gentoo.org/wiki/Project:Android > While I believe the dynamic linker paths are hard coded, the library > Locations are more complex especially when multilibs (MULTILIB_OSDIRNAMES) > and/or multiarch gets layered on top. You are right, multilib and multiarch are about library locations. And they have nothing to do with the location of dynamic linker. On multilib, the dynamic linkers are as-is, e.g. amd64/x86 system has both /lib64/ld-linux-x86-64.so.2 and /lib/ld-linux.so.2. On multiarch, dynamic linkers are symlinked to the traditional locations: $ ls -l /lib/ld-linux.so.2 lrwxrwxrwx 1 root root 25 Oct 23 19:37 /lib/ld-linux.so.2 -> i386-linux-gnu/ld-2.19.so > I'd love to see a description of how all these pieces are intended to > sit together as I too am looking at this area for MIPS sysroots. Perhaps > that is a topic for libc-alpha though. If the target is the rootfs of a MIPS embedded system, when it is a classical sysroot use case;) Cheers, Benda