There may be the germ of an insane but possibly usable idea here ...
What we need is a facility by which a program can glue together a bunch
of object files
when it's run ...
Now ?l can already do the gluing,
so why not replace any program that requires dynamic libraries with an
rc script
that links together all the required object files together on the fly
into a temporary file,
then executes the resultant file then removes it.
Yes, it's psychotic, but so are shared libs.
Of course, if you want to link at run-time rather than execute-time,
you're out of luck, but, pedantically, it will do most of what linux
does with .so files
with no changes lower down.
DaveL
(who's on holiday in Sydney and thinks that the next plan9 conference
definitely ought to be here).
erik quanstrom wrote:
perhaps my assembly-language addled brain is just rebelling, but my snarky
reaction
to this python thread is this:
eh, while you're at it, why not just run the whole dynamicly-bound
bit in a 386-emulator. that way, when movietunes3000 really wants some
bit of linux, you can just run it in the emulator.
or, Just Run Linux™.
my slightly more thoughtful reaction is, why does the operating system need to
control
the late-linking process? (python doesn't really need .so shared libraries per
se, does it?)
to me this seems more like a linker problem than anything else. why not write
your own?
you could write an rc script to gather the bits and waah laa. ... ooh, ron. i
just invented
linker scripts. ;-)
- erik
