Aside from the connected use of "cd ..." and "$PWD" -
You almost have it down to a one-liner:
Code:
#!/lib/ld-linux.so.3 --library-path $PWD/lib:/usr/lib:/lib --inhibit-rpath libfftw3.so.3 ./fftw-wisdom
For the purposes of conversation here, let us say that the above code implements the requirements of your chosen distribution policy (it does/will).
Whatever the final version of that "policy implementor" becomes, the above demonstrates the overall behavior.
(Sorry if this reads like I am preaching/teaching or something else, no insult intended to anyone, not even if the above meets the GM whitespace standard.)
Next (rhetorical) question:
How to avoid writing (or having the build system write) one of those above for each and every new application?
In answer, start by reading what is written above in the prototype launcher glue.
What does the first two characters, the Splat-Bang, in a *nix script do?
It causes the loading mechanism used to start an executable to search for a program (other than the elf loader) to interpret the rest of the file.
Now, ask yourself, what mechanism does binfmt_misc provide?
It is a loading mechanism that selects a program to interpret the rest of the file based on either extension or magic number.
The "program" may be any executable, including a script "wrapper".
Ah, so, as the light begins to dawn ....
Now we can see why that crazy old fool was asking for mod binfmt_misc.
Suppose that the above single line glue code began with a six character magic number:
Code:
#!ld.3 --library-path $PWD/lib:/usr/lib:/lib --inhibit-rpath libfftw3.so.3 ./fftw-wisdom
Now all you need is one "wrapper" that binfmt_misc can call when it detects a new executable that needs: "launcher glue".
That wrapper can be used to determine the variables of the "glue code" launcher.
For a more advanced usage, to get a Kindle to "swallow" anything we add-in, see the following reference.
When reading the reference:
http://www.kernel.org/doc/Documentation/binfmt_misc.txt
You will find examples of how binfmt_misc can read the elf header of the file to be run.
One of the first things in the elf header is the interpreter to be used and some other flag bits.
I.E: Not only can we "glue in" applications using a mis-matched glibc, we can "glue in" applications that aren't even built against glibc of any version.
(the uClibc loader has a different name, only I need to re-build the uClibc used in the emulator because the current one was built without a required option).