Ticket #627 (closed bug: fixed)

Opened 5 years ago

Last modified 5 years ago

dynlexpad doesn't work with installed parrot.

Reported by: coke Owned by: coke
Priority: normal Milestone:
Component: none Version: 1.1.0
Severity: medium Keywords: tcl blocker
Cc: jkeenan Language:
Patch status: Platform: darwin

Description

Given this PIR from t/dynpmc/dynlexpad.t

.loadlib "dynlexpad"

.HLL "Some"
.sub load :anon :init
  .local pmc interp, lexpad, dynlexpad
  interp = getinterp
  lexpad = get_class 'LexPad'
  dynlexpad = get_class 'DynLexPad'
  interp.'hll_map'(lexpad, dynlexpad)
.end

# see loadlib
.sub 'test' :main
    foo()
.end
.sub foo :lex
    $P1 = new 'Integer'
    $P1 = 13013
    store_lex 'a', $P1
    print "ok 1\n"
    $P2 = find_lex 'a'
    print "ok 2\n"
    print $P2
    print "\n"
    end
.end

running with svn-recent out of the build dir, I get:

$ ./parrot /tmp/die.pir
ok 1
ok 2
13013

Running from an installed parrot, I get:

$ parrot /tmp/die.pir
src/string/api.c:762: failed assertion 'encoding'
Abort trap
slurpee:~/research/parrot coke$ parrot -V
This is Parrot version 1.1.0 built for nojit.
Copyright (C) 2001-2009, Parrot Foundation.

This code is distributed under the terms of the Artistic License 2.0.
For more details, see the full text of the license in the LICENSE file
included in the Parrot source tree.

Change History

in reply to: ↑ description   Changed 5 years ago by jkeenan

Replying to coke:

I tried to reproduce your results but could not. On Linux/i386, at r38412, I got this using an installed Parrot:

../pseudoinstall/bin/parrot ~/learn/parrot/die.pir
ok 1
ok 2
13013

On the same machine, same SVN revision, I got this using a parrot built in my sandbox (but not installed):

[li11-226:parrot] 563 $ ./parrot ~/learn/parrot/die.pir
ok 1
ok 2
13013

Other than configuring with --prefix=/path/to/pseudoinstall in the first case, there was no difference between the two cases.

follow-up: ↓ 3   Changed 5 years ago by coke

This is very likely a darwin only issue related to the override of Parrot_dlopen.

in reply to: ↑ 2 ; follow-up: ↓ 8   Changed 5 years ago by jkeenan

Replying to coke:

This is very likely a darwin only issue related to the override of Parrot_dlopen.

I'll try it on Darwin PPC at my earliest opportunity.

follow-up: ↓ 7   Changed 5 years ago by coke

Thanks to NotFound++, I found that the dynlexpad.bundle file is pointing to the libparrot in the build directory (which is long gone.)

I'm not sure why the loadlib doesn't die here, but rewriting the installed dynext's with install_name_tool fixes the problem.

This means that anyone doing a install on OSX from source (and not via the port as it exists today) will not have the problem, since /everything/ is pointing (incorrectly) to the build dir.

  Changed 5 years ago by coke

  • owner set to coke

  Changed 5 years ago by jkeenan

  • cc jkeenan added

in reply to: ↑ 4   Changed 5 years ago by doughera

Replying to coke:

Thanks to NotFound++, I found that the dynlexpad.bundle file is pointing to the libparrot in the build directory (which is long gone.)

Yes. I have previously reported this same problem as TT #540.

in reply to: ↑ 3 ; follow-up: ↓ 9   Changed 5 years ago by jkeenan

Replying to jkeenan:

Replying to coke:

This is very likely a darwin only issue related to the override of Parrot_dlopen.

I'll try it on Darwin PPC at my earliest opportunity.

This is what I got on Darwin/PPC (OS X 10.4) at r38469. I configured with --prefix=/topdir/pseudoinstall, then ran make. Then I tested from the sandbox:

$ ./parrot ~/learn/parrot/die.pir
ok 1
ok 2
13013

Then I called make install and tested with the installed executable:

$ ../pseudoinstall/bin/parrot ~/learn/parrot/die.pir
ok 1
ok 2
13013

in reply to: ↑ 8   Changed 5 years ago by coke

Replying to jkeenan:

Replying to jkeenan:

Replying to coke:

This is very likely a darwin only issue related to the override of Parrot_dlopen.

I'll try it on Darwin PPC at my earliest opportunity.

This is what I got on Darwin/PPC (OS X 10.4) at r38469. I configured with --prefix=/topdir/pseudoinstall, then ran make. Then I tested from the sandbox: {{{ $ ./parrot ~/learn/parrot/die.pir ok 1 ok 2 13013 }}} Then I called make install and tested with the installed executable: {{{ $ ../pseudoinstall/bin/parrot ~/learn/parrot/die.pir ok 1 ok 2 13013 }}}

Which makes sense, given my previous diagnosis. Your installed version is linked against your build directory.

  Changed 5 years ago by coke

  • status changed from new to closed
  • resolution set to fixed

I believe the patch applied in TT #698 (doughera++) has resolved the self-referential -lparrot issue.

The installed parrot binary still refers to the build dir, but the macport install is compensating for that.

Note: See TracTickets for help on using tickets.