On 09/21/2016 02:50 PM, Felix Fietkau wrote:
> 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.

I considered having a sort of automatic postinst script which would
reload the ld.so.cache after a package with shared libraries is
installed, not sure if this makes sense, fixing the loader search paths
is definitively on my TODO, but won't happen just yet, but by the time
this comes, maybe I will just use the native toolchain anyway...

>>>> 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 sane in the context of using the internal toolchain and defaulting
to everything in /lib, which I agree is a keep it simple approach, I
don't anticipate having to support a mixed userland though.

>> 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.

Which I probably can't fix since I don't have access to such a system,
are there automated Mac OSX builds somewhere that I can leverage, if
not, can you show me the failure?

Lede-dev mailing list

Reply via email to