[got a failure, sorry if this is a duplicate] On 15 Aug 2004 10:11:11 -0000 Leopold Toetsch via RT <[EMAIL PROTECTED]> wrote:
> Mattia Barbon <[EMAIL PROTECTED]> wrote: > > > Hello, > > I am not sure about this patch. It splits part of Parrot_load_lib > > into a Parrot_init_lib(Interp, load_func_ptr, init_func_ptr) > > where load/init_func_ptr are pointers to the function loadlib calls. The > > objective is allowing dynamic PMCs linked inside a larger library > > or maybe an executable. For example Ponie might have Perl5IV, > > Perl5PVCV, etc. PMCs linked inside libponie, > > For PMC libraries I'd rather have that done in the PMCs init code. > This could be automated for a bunch of PMC files of one language. E.g. a > utility concats the .c files generated from .pmc and chains the init > functions, so that one init call registers all PMCs. Maybe something like this (exact syntax up in the air): pmc2c2.pl ... --dump pmc1.pmc pmc2c2.pl ... --dump pmc2.pmc pmc2c2.pl ... --dump pmc3.pmc pmc2c2.pl ... --c --library-name baz pmc1.pmc pmc2.pmc pmc3.pmc # outputs the PMC code in pmc1.c, pmc2.c, pmc3.c # puts a merged class_init and Parrot_lib_baz_load in baz.c This will also allow solving the problem in the patch to Pmc2c.pm (can't have two dynpmc A and B, A declaring an MMD function with B and B declaring one for A). Will work on it. > But your solution seems to be just a generalization of this. It is not. Yet. But this patch (or something like this) is needed to implement PMCs linked into an executable (statically linked ponie), or into a shared library that also contains other runtime functions (a shared libponie.so(. Regards Mattia
