On 03/06/2020 22.44, Andre McCurdy wrote: > On Wed, Jun 3, 2020 at 12:38 AM Rasmus Villemoes > <rasmus.villem...@prevas.dk> wrote: >> On 02/06/2020 23.46, Andre McCurdy wrote: >>> On Tue, Jun 2, 2020 at 2:15 PM Phil Blundell via >>> lists.openembedded.org <pb=pbcl....@lists.openembedded.org> wrote: >>>> >>> >>> It seems like a weird corner case to me. Where do these libraries come >>> from and why can't they be moved or symlinked into a standard path? >> >> Pre-compiled proprietary binaries/libraries that go in >> /opt/<vendor>/..., just as /opt is meant for (and no, we can't just >> install them to /usr/lib, /usr/bin etc - partly because they contain >> hard-coded absolute paths, but also due to some not-entirely-techical >> reasons). So there's an /etc/ld.so.conf.d/<vendor>.conf that needs to be >> picked up. >> >>> If they are somehow special and only used by special applications then >>> setting rpath or using LD_LIBRARY_PATH just for those applications >>> would seem to be a better solution than enabling them globally. >> >> We don't control the compilation, so rpath is out. We did consider >> LD_LIBRARY_PATH, but figured that the ld.conf solution is more robust >> (no problems with setuid binaries or an application that misguidedly >> sanitizes the environment for subprocesses). > > Unless the supplier of your binaries is completely unresponsive (if > so, bad luck) then educating them on the usage of rpath and asking for > a new release is probably the cleanest solution.
For various reasons that is not a viable path. > If you start your special application via a wrapper script which sets > LD_LIBRARY_PATH then it won't be seen by anything else, so the > concerns about other apps messing with it etc should not apply? "Other apps" could be the apps in /opt themselves, that start other binaries from under /opt, perhaps via some maze of shell scripts or whatnot (the usual mess one sees with proprietary stuff) - which is also the reason I'm worried they might have done some "value-add" sanitization somewhere. > Relying on /etc/ld.so.conf.d/*.conf will certainly work too, but has > two disadvantages: it will add the custom library path globally > instead of just for the special apps and it's not portable (it's not > supported by musl etc - although if you only care about your > proprietary binaries pre-compiled for glibc then that won't matter to > you). One could also ask the question: If one is not supposed to use the drop-in dir ld.so.conf.d/ for exactly what I'm using it for, then why does Yocto provide a ld.so.conf that mentions it? Sure, for glibc-based distros (of course, it's from the glibc recipe), but that's fine. Please remember that this is all just about ensuring that the ldconfig run at image build time produces the same result, regardless of whether one has opted to have ldconfig-the-binary in the rootfs or not (and everybody seems to agree there are valid reasons not to have that). > Anyway, the original patch has been merged, so this now just a side > discussion. Indeed. Rasmus
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#139206): https://lists.openembedded.org/g/openembedded-core/message/139206 Mute This Topic: https://lists.openembedded.org/mt/74625854/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
