Re: [ARM/FDPIC v5 03/21] [ARM] FDPIC: Force FDPIC related options unless -mno-fdpic is provided

[Rich Felker <dalias@libc.org>]

On Wed, May 15, 2019 at 03:59:39PM +0000, Szabolcs Nagy wrote:
> On 15/05/2019 16:37, Rich Felker wrote:
> > On Wed, May 15, 2019 at 05:12:11PM +0200, Christophe Lyon wrote:
> >> On Wed, 15 May 2019 at 16:37, Rich Felker <dalias@libc.org> wrote:
> >>> On Wed, May 15, 2019 at 01:55:30PM +0000, Szabolcs Nagy wrote:
> >>>> can support both normal elf and fdpic elf so you can test/use
> >>>> an fdpic toolchain on a system with mmu, but this requires
> >>>> different dynamic linker name ..otherwise one has to run
> >>>> executables in a chroot or separate mount namespace to change
> >>>> the dynamic linker)
> >>>
> >>> Indeed, it's a bad idea to make them clash.
> >>>
> >>
> >> Not sure to understand your point: indeed FDPIC binaries work
> >> on a system with mmu, provided you have the right dynamic
> >> linker in the right place, as well as the needed runtime libs (libc, etc....)
> >>
> >> Do you want me to change anything here?
> > 
> > I think the concern is that if the PT_INTERP name is the same for
> > binaries with different ABIs, you wouldn't be able to have both
> > present in the same root fs, and this would make it more of a pain to
> > debug fdpic binaries on a full (with-mmu) host.
> > 
> > musl always uses a different PT_INTERP name for each ABI combination,
> > so I guess the question is whether uclibc or whatever other libc
> > you're intending people to use would also want to do this.
> 
> glibc uses different names now for new abis, so i was expecting
> some *_DYNAMIC_LINKER update, but it seems uclibc always uses
> the same fixed name
> 
> /lib/ld-uClibc.so.0
> 
> i guess it makes sense for them since iirc uclibc can change
> its runtime abi based on lot of build time config so having
> different name for each abi variant may be impractical.

Yes, this "feature" of uclibc was was of the key motivations behind
the creation of musl... :-)

Rich