Dan Sugalski wrote:
> >ways to link C functions other than C<main> (or any other external
> >binary with a specifiable linkage) directly into Perl, so that
> >not only do I not have to fire up a sub process, I don't even have to
> >select the blade of my fancy pocket knife with a command line option:
> >I can tell my Perl6 program where that blade is, if I know.
>
> Linking against shareable images/libraries/DLLs/whatever is a separate
> matter entirely. That's definitely doable, since this is what they're
> designed to do. The big issue there is dynamically calling routines whose
> function signatures are all different.
The difference, whether a .o becomes a stand-alone executable or
part of a .so, is at link time.
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.
If internals can dynamically open a shared object, the compile-time
invocation of ld can be directed to create a shared object.
References:
man (1) ld -- the GNU linker
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
On hold for support since 1995
