From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <cacc637eadad6e94a3eda0cf1a09f4d9@9netics.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] python
Date: Thu,  4 Jan 2007 23:26:34 -0800
From: Skip Tavakkolian <9nut@9netics.com>
In-Reply-To: <459DF84B.3010405@anvil.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: fd266c18-ead1-11e9-9d60-3106f5b1d025

how would this help with ldopen/LoadLibrary stuff?

while we're throwing out ideas, how about using filesystems to
implement the indirection that shared libs provide.  for a 'subsys'
instead loading a shared lib so we can write subsys.func1(params),
etc, provide an fs with hierarchy like:

	/subsys
		/func1
		/func2
		/func3

that implements the calls; then calls to subsys.func1(params,...)
would translate roughly to open/write(params)/read(result)/close of
the corresponding file.

> 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 ...
>> 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. ;-)
>>