On 30.06.21 17:38, Florian Weimer wrote:
Not necessarily, these can still be applied (and fairly simple).
You actually have to twist more extra knobs if to wanted those weird
things to happen.
Sorry, this is just not true. You cannot load system libraries such as
NSS modules or cryptographic libraries with a custom glibc because the
system glibc could be newer, and glibc does not provide that kind of
compatibility (only the other way round).
Yes, such glibc "plugins" specifically need to be built for the same
glibc version.
I've already mentioned that in 25yrs I've had such scenario, where some
operator actually wants to load *3rdparty* nss modules (that are *not*
included in upstream glibc), just *once* - and this time myself doing
that funny stuff (and also written that module).
And I'm repeating my previous questions: can you name some actual real
world (not hypothetical or academical) scenarios where:
somebody really needs some binary-only application &&
needs those extra modules *into that* application &&
cannot recompile these modules into the applications's prefix &&
needs AMX in that application &&
cannot just use chroot &&
cannot put it into container ?
I happen to be one exacly those folks whose better part of the daily
business is dealing with really crazy scenarios, most people don't
even dare thinking about (also dealing with horrible stuff like having
link in binary-only objects into embedded applications which had been
compiled for different ABIs, etc) - and I can only conclude that the
above kind of scenario is really, really rare, usually caused by
completely non-technical factors (e.g. beaurocrazy) and there're always
other options.
--mtx
--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@xxxxxxxxx -- +49-151-27565287
