This description **was not** the major problem.
But it does describe considerations to be made with "out of tree" system libraries.
Spoiler:
Quote:
Originally Posted by NiLuJe
If that helps, that's what happens when the kernel can't even run the binary (wrong arch, possibly fatally wrong CPU tuning, although that should SIGILL instead).
|
I have had a 4-1/2 hour (night-time) nap, and now the answer is "obvious" - - -
The runpath string is too long for ld.so and/or the kernel (untested at the moment).
But that is the only significant change as the builds progressed from "working" to "totally failing".
The runpath string was getting longer.
We all win (for reasons unknown at the time) -
You are correct: The kernel can't run it.
Our (twobob and I) plan to flatten the FHS tree into a single level.
(Everything then gets the short search path string: "$ORIGIN/../lib")
If that (relative search path) doesn't cover all use cases, then a rename of where we put things might.
Such as: "/mnt/us/esys/lib:mnt/us/esys/usr/lib"
Hmm...
#2 uses absolute pathnames -
And there are undocumented (outside of source code comments) restrictions on the use of "$ORIGIN ....".
Three level, absolute, search path with current naming: 103 characters (broken wherever tried).
Two level, absolute, search path with current naming: 63 characters (broken in some places tried).
Renamed structure, two level, absolute, search path with new naming: 36 characters.
And the winner is (should be): /mnt/us/esys/lib:mnt/us/esys/usr/lib
In: Real world use VS. Documented use
"Real World" wins this one and we just get to conform.
