On 09/21/2016 12:48 PM, Felix Fietkau wrote:
> On 2016-09-21 20:13, Florian Fainelli wrote:
>> This patch series adds support for generating valid ld.so.cache which match 
>> the
>> target architecture, without requiring a cross-compiled version of ldconfig
>> that would run on the host, nor run on the target.
>> Having a proper ld.so.cache might be needed if e.g: 64-bit executable loader
>> only has /lib64 in its default search path.
> Can't we simply fix the default search path instead?

Not necessarily, but it's software, so anything can be fixed, I just
don't want to force a toolchain update just yet on my users.

> Or is this a workaround for dealing with external toolchain braindamage?

It works as a workaround for such toolchains, it's also just useful for
people who want to make use of it and speed up their search paths with
glibc-based systems.

>> At some point, we should probably think about how we want to structure the
>> rootfs in OpenWrt/LEDE wrt. 32-bit/64-bit libraries but that set of changes 
>> is
>> orthogonal and can be useful on its own.
> What do we need that for?

What part are you asking about, re-thinking the 32-bit/64-bit library
paths or ldconfig in general?

It's fine not to accept these patches, I just don't see a reason why not
if it is useful to people like me (sorry for not fitting in the internal
toolchain model just yet), and possibly others as well. If you want this
hidden behind a CONFIG_USE_LDCONFIG, maybe that becomes more acceptable
in your eyes?

Lede-dev mailing list

Reply via email to