[perl #38429] [BUG] --parrot_is_shared=0 and dynpmc
Leopold Toetsch
# Please include the string: [perl #38429]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org/rt3/Ticket/Display.html?id=38429 >
Platform x86/linux
Compiling a static Parrot simplifies debugging, e.g. for setting
breakpoints. But it doesn't play nicely with dynamic extensions.
$ ./parrot -w t/dynpmc/foo_1.pir
Couldn't load 'foo.so': libparrot.so.0.4.1: cannot open shared object file
It works only with
$ LD_LIBRARY_PATH=blib/lib ./parrot ...
leo
Nick Glencross
I'm pretty certain that after a fresh build things works perfectly, but
my hunch is that the dynpmcs aren't forced to relink after a Configure.
I've just checked, and although they seem to be recopied into
runtime/parrot/ dynext, the timestamps don't change in src/dynpmc.
I suspect that the proper solution is to enhance 'needs_build' in
tools/build/dynpmc.pl to take into account whether Configure has been
rerun. I can propose a solution to this tomorrow, unless there are any
other takers...
Nick
Leopold Toetsch
On Feb 5, 2006, at 0:37, Nick Glencross wrote:
> Leopold Toetsch (via RT) wrote:
>> Compiling a static Parrot simplifies debugging, e.g. for setting
>> breakpoints. But it doesn't play nicely with dynamic extensions.
> I'm pretty certain that after a fresh build things works perfectly,
> but my hunch is that the dynpmcs aren't forced to relink after a
> Configure.
Oh well. You are right, sorry. I did use the new 'make archclean' make
target, which is supposed to clean such files, but obviously doesn't.
Keeping the from .pmc generated .c files still saves a lot of build
time, so I think, this clean target just need fixes.
> Nick
leo
Joshua Isom
so people could try it out. I'd only tested it on freebsd and darwin
and my main concern was with win32. It does a lot of restructuring to
help make it easier, and I wasn't sure how it'd be with windows.