I'm hoping this is just a simple linker option, but
I've been reading "ld" manuals for the past few
hours and I just don't get it. :)
I'm trying to make a dynamically loaded PMC that
subclasses another dynamically loaded PMC.
I made two files in parrot/dynclasses/ :
// file 1: pisequence.pmc
#include "parrot/parrot.h"
#define enum_class_PiSequence -1
pmclass PiSequence need_ext dynpmc {
INTVAL get_integer () {
return 0;
}
}
// file 2: piobject.pmc
#include "parrot/parrot.h"
#define enum_class_PiString -1
pmclass PiString extends PiSequence need_ext dynpmc {
}
I added these to the Makefile, ran make -C dynclasses
and now, I have two *.so files:
% find runtime -name "pi*.so"
runtime/parrot/dynext/pisequence.so
runtime/parrot/dynext/pistring.so
Then I try to run this:
.sub __main__
loadlib P0, "pisequence"
find_type I0, "PiSequence"
print I0
print "\n"
loadlib P1, "pistring"
find_type I1, "PiString"
print I1
print "\n"
end
.end
Output is:
Couldn't load 'runtime/parrot/dynext/pistring': \
runtime/parrot/dynext/pistring: cannot open shared object file: \
No such file or directory
51
Couldn't load 'runtime/parrot/dynext/pistring': \
runtime/parrot/dynext/pistring: cannot open shared object file: \
No such file or directory
0
If I copy the get_integer function to PiString
instead of trying to inhert, everything works:
51
52
It seems the problem is that pistring.so can't
load because it can't find a definition for
Parrot_PiSequence_get_integer... Even though
it's defined in the other *.so file that's
already loaded.
I don't think this is a bug... I think I just
don't know what I'm doing. Can someone help? :)
Sincerely,
Michal J Wallace
Sabren Enterprises, Inc.
-------------------------------------
contact: mic...@sabren.com
hosting: http://www.cornerhost.com/
my site: http://www.withoutane.com/
--------------------------------------
> Hi all,
> I'm hoping this is just a simple linker option, but
> I've been reading "ld" manuals for the past few
> hours and I just don't get it. :)
> I'm trying to make a dynamically loaded PMC that
> subclasses another dynamically loaded PMC.
Its a linker problem, but not too simple. Your analysis is correct:
pistring needs the symbol Parrot_PiSequence_get_integer, so you have to
provide it:
I did something like this:
$ make -C dynclasses
$ cp dynclasses/pisequence.so blib/lib/libpisequence.so
$ cd dynclasses; cc -shared -L/usr/local/lib -o pistring.so \
-I../include -I../classes -L../blib/lib -lparrot pistring.c \
-lpisequence ; cd ..
$ cp dynclasses/pistring.so runtime/parrot/dynext/
$ parrot wl.imc # run your test program
51
52
I also had -Wl,-E in the Makefile, when compiling pisquence. I don't
know if its necessary.
Another (untested) possibility: you could try to append the 2 pi*.c
files into another one and then compile the combined source to a shared
lib.
> Michal J Wallace
leo
> Michal Wallace <mic...@sabren.com> wrote:
>
> > I'm trying to make a dynamically loaded PMC that
> > subclasses another dynamically loaded PMC.
>
> Its a linker problem, but not too simple. Your analysis is correct:
> pistring needs the symbol Parrot_PiSequence_get_integer, so you have to
> provide it:
Thanks Leo! You rock!!!
> I did something like this:
>
> $ make -C dynclasses
> $ cp dynclasses/pisequence.so blib/lib/libpisequence.so
Aha! I was trying to figure out how to do -lpisequence.
It didn't occur to me to just RENAME it. :)
> $ cd dynclasses; cc -shared -L/usr/local/lib -o pistring.so \
> -I../include -I../classes -L../blib/lib -lparrot pistring.c \
> -lpisequence ; cd ..
> $ cp dynclasses/pistring.so runtime/parrot/dynext/
>
> $ parrot wl.imc # run your test program
> 51
> 52
Awesome! Thanks again! :)
> I also had -Wl,-E in the Makefile, when compiling pisquence. I don't
> know if its necessary.
>
> Another (untested) possibility: you could try to append the 2 pi*.c
> files into another one and then compile the combined source to a shared
> lib.
That makes sense. I'll try it. If it works, I'll patch
pmc2c2.pl to do do this automatically. I'm sure this won't
be the last time someone wants to provide a whole set of
classes at once.
> leo
Perhaps all such .so's should be generated with "lib" at the start of the name.
Tim.