This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Add a configurable directory prefix for dynamic linkers.


Hi Matthew, Richard,

Matthew Fortune <Matthew.Fortune@imgtec.com> writes:

> Richard Biener <richard.guenther@gmail.com>  writes:
>> On Thu, Dec 4, 2014 at 8:59 AM, Benda Xu <heroxbd@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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]