Shared library question
Sam Ruby
This code is present in libparrot.so, which currently is not referenced
as a library by the link step for dynclasses.
Options include:
1) eliminating this dependency, as it is the only one
2) directly including extend.o into each shared library
3) linking to libparrot.so
As an added complication, the link step for dynclasses is by default run
from a different directory than the main build.
Preferences?
- Sam Ruby
Dan Sugalski
>Background: Pmc2c.pm emits code which references Parrot_PMC_typenum.
>This code is present in libparrot.so, which currently is not
>referenced as a library by the link step for dynclasses.
>
>Options include:
>
> 1) eliminating this dependency, as it is the only one
> 2) directly including extend.o into each shared library
> 3) linking to libparrot.so
#3's the right thing here. PMC classes have access to enough of the
internals that linking to libparrot's fine. If we're feeling paranoid
we can define a PMC API and link against a shared library that
exposes it, but that's a bit much for now.
>As an added complication, the link step for dynclasses is by default
>run from a different directory than the main build.
Pfui. Probably ought to be fixed.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Sam Ruby
> At 3:49 PM -0500 11/4/04, Sam Ruby wrote:
>
>> Background: Pmc2c.pm emits code which references Parrot_PMC_typenum.
>> This code is present in libparrot.so, which currently is not
>> referenced as a library by the link step for dynclasses.
>>
>> Options include:
>>
>> 1) eliminating this dependency, as it is the only one
>> 2) directly including extend.o into each shared library
>> 3) linking to libparrot.so
>
> #3's the right thing here. PMC classes have access to enough of the
> internals that linking to libparrot's fine. If we're feeling paranoid we
> can define a PMC API and link against a shared library that exposes it,
> but that's a bit much for now.
I ran into both technical and performance issues, both of which are
worth discussing. First the technical difficulties:
By adding "-L../blib/lib -lparrot" to the link step, I was able to
produce a shared library. However, getting it to successfully load was
a challenge. The problem is that library.c is hardcoded to look for
dynamic libraries in runtime/parrot/dynext/, effectively requring parrot
to be invoked from the parrot directory if any shared libraries are
going to be loaded. That needs to be fixed, IMHO, but that is beside
the point.
With option (3) above, the loading of python_group requires libparrot.so
to be loaded. Unfortunately, nothing tells the OS that this library can
be found in blib/lib, so it fails. There are a number of ways to
address this, one of the simplest is to modify library.c to add a "" to
dynext_paths, effectively enabling LD_LIBRARY_PATH to be used. This may
not be the right long term solution, but it did enable me to get past
this problem, and does provide a workaround to the issue of returing
parrot to be run from a particular directory.
- - -
I have a simple unit test[1], one that was not intended to be a
benchmark. Each run passed, and here are the results (in seconds,
methodology = best of three runs):
3.437 Dynclass w/ dependency on libparrot.so
2.912 Dynclass w/o dependency on libparrot.so
1.221 enum class
Note: in the last run, the loadlib ops were removed, but the find_type
ops remained in place. An additional run was made with the find_type
ops removed, but the difference was not measurable.
On the plus side, the overhead is presumably all startup costs.
However, the fact that the overhead is noticeable at all, let alone this
significant, in a series of tests involving the compiling from source of
a program is distressing.
One other thing to note, "make shared" does not reduce the size of the
parrot executable. If the long term plan is to change the perl classes
to be dynclasses, then the presumtion should be that everybody is
running shared, and the parrot executable should contain only what is
not in libparrot.so.
- Sam Ruby
Sam Ruby
>
> I have a simple unit test[1], one that was not intended to be a
> benchmark.
I probably should have included the following in my email *blush*:
[1] http://intertwingly.net/stories/2004/11/05/parrot/t/dynclass/pyint.t
- Sam Ruby