Re: t/dynclass failures due to using installed libs

2005-03-31 Thread Leopold Toetsch 
Bob Rogers [EMAIL PROTECTED] wrote:

 The following trivial patch fixes this.  It's written so that an
 explicit

   PARROT_TEST=0 make test

Thanks, applied.
leo

Re: t/dynclass failures due to using installed libs

2005-03-28 Thread Leopold Toetsch 
Bob Rogers [EMAIL PROTECTED] wrote:

 ...  If the prefix is disabled via
 PARROT_TEST, this fixes the immediate problem:

 [EMAIL PROTECTED] PARROT_TEST=1 perl -Ilib t/dynclass/foo.t
 1..1
 ok 1 - abs
 [EMAIL PROTECTED]

 But shouldn't make test do this by default?  Otherwise, you're not
 actually testing the version you just built . . .

Seems so, yes.

   -- Bob Rogers

leo

t/dynclass failures due to using installed libs

2005-03-27 Thread Bob Rogers 
I just did a CVS update (the first in a while, with all necessary
options present, btw), and got some dynamic loading failures, e.g.:

[EMAIL PROTECTED] perl -Ilib t/dynclass/foo.t
1..1
not ok 1 - abs
# Failed test (t/dynclass/foo.t at line 21)
#  got: 'Couldn't load 'foo': foo: cannot open shared object file: 
No such file or directory
# Illegal PMC enum (0) in new
# '
# expected: '42
# '
# '(cd .  ./parrot  /shared/src/parrot/t/dynclass/foo_1.imc)' failed 
with exit code 1
# Looks like you failed 1 tests of 1.
[EMAIL PROTECTED] 

Poking into it, I found that Parrot_locate_runtime_file searches under
the prefix, /usr/local/parrot-0.1.2-devel in this case, which certainly
makes sense for installed code.  If the prefix is disabled via
PARROT_TEST, this fixes the immediate problem:

[EMAIL PROTECTED] PARROT_TEST=1 perl -Ilib t/dynclass/foo.t
1..1
ok 1 - abs
[EMAIL PROTECTED] 

But shouldn't make test do this by default?  Otherwise, you're not
actually testing the version you just built . . .

-- Bob Rogers
   http://rgrjr.dyndns.org/