[LEDE-DEV] [PATCH 0/3] Support for ldconfig on the target

[Felix Fietkau]

On 2016-09-21 22:03, Florian Fainelli wrote:
> 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.
If it ends up being required only for external toolchains, I'd like to
limit it to those.

>> 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.
I think such a speedup will probably end up being completely
insignificant. The reason for my reluctance in accepting this is the
fact that it ends up adding more potentially fragile stuff to the mix
which could lead to bugs or inconsistent behavior.
I wonder how it will affect installing more library packages via opkg.
Will running ldconfig on the device be required whenever new things get
added that aren't in the default search path?
If so, then this is a crappy solution, and the toolchain should be fixed
instead.

>>> 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?
32-bit/64-bit paths. I don't expect LEDE to ever handle a mix of 32 + 64
bit properly, so having symlinks seems like the most sane option to me
right now.

> 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?
Your ldconfig-native tool does not build on Mac OS X, so enabling it by
default is not an option to me, at least until it is fixed.

- Felix