David L . Nicol <[EMAIL PROTECTED]> writes:
>
>
>The difference, whether a .o becomes a stand-alone executable or
>part of a .so, is at link time.
On modern OSes (Linux, Solaris, Win32) there is very little difference
between an executable and a shared object.
>
>I imagined when I wrote 61 that implementing it might require including
>a lot of the function of ld.
>
>I don't know about doing it all within the process we have already,
>but I can implement the interface (for C) by automating the creation
>of a short C program that can accept input in some form that I
>will provide to it, compiling it, linking it against the provided
>objects, and keeping around the result, as a standalone file in a
>temporary file space available to this program, all the preceding
>at compile time, and at run time marshalling the input data properly
>and running the temporary standalone file in backticks.
Rather than doing all that time-consuming stuff at (each) run time it is
better to build a shared object and load and call that.
Shared objects also avoid the problem of having N functions called main()
as each .so has its own name-space.
>
>If internals can dynamically open a shared object, the compile-time
>invocation of ld can be directed to create a shared object.
That is how XS extensions work in perl5.
Now the process of doing that can be cleaned up some...
>
>
>References:
>
>man (1) ld -- the GNU linker
Look at:
man dlopen()
man dlsym()
--
Nick Ing-Simmons
