Although larger issues about testing of Parrot configuration step
classes remain outstanding (and will for some time), they're being
tracked in other tickets. The immediate issue in this ticket seems
resolved, as this test has been passing in all smoke reports for some
time. So I'm closing the ti
On Nov 4, 2007, at 3:13 AM, Cosimo Streppone via RT wrote:
However, just out of curiosity...
Would the attached test work as well?
I replaced all the code that does the "hand-testing" of auto::gcc
with the automated `test_step_thru_runstep()' function.
IIUC, that function does exactly what th
Cosimo, chromatic, et al.:
Please try out the new version of t/configure/111-auto_gcc-01.t attached.
It works for me on both Darwin and Linux as an argument to either
/usr/bin/prove or /usr/local/bin/prove.
Thank you very much.
kid51
111-auto_gcc-01.t
Description: Binary data
James Keenan via RT wrote:
> Cosimo,
>
> The more I look at this, the more I wonder whether the test failure in
> 111-auto_gcc-01.t (reported below) has anything to do with the presence
> or absence of gdbm on one's OS or whether one's Perl was build with gdbm
> or not.
>
I'm sorry. I now realiz
I can now reproduce the problem reported by Cosimo and chromatic. If
instead of running the tests in t/configure/ with 'prove' -- which is
connected to my hand-built (without gdbm) Perl 5.8.7 -- I run those same
tests with '/usr/bin/prove' -- which is connected to the vendor-supplied
Perl 5.8.8 bu
chromatic wrote:
I bet that Cosimo's test.ldo file says "couldn't link with -lgdbm" or
something similar. I see the same failure; here's what's in my test.ldo:
/usr/bin/ld: cannot find -lgdbm
collect2: ld returned 1 exit status
For whatever reason, this test file is trying
On Saturday 03 November 2007 07:32:21 James Keenan via RT wrote:
> The more I look at this, the more I wonder whether the test failure in
> 111-auto_gcc-01.t (reported below) has anything to do with the presence
> or absence of gdbm on one's OS or whether one's Perl was build with gdbm
> or not.
Cosimo,
The more I look at this, the more I wonder whether the test failure in
111-auto_gcc-01.t (reported below) has anything to do with the presence
or absence of gdbm on one's OS or whether one's Perl was build with gdbm
or not.
>
> --8<
> [EMAIL PROTEC
I believe that what we have stumbled on here is a case where we have
been bitten on the butt by our dependence on Perl 5's Config.pm and the
global, read-only variable it supplies, %Config. If the Perl you use
for building Parrot was not build with gdbm, then no reference to gdbm
will be located i
James Keenan via RT wrote:
> Cosimo Streppone wrote:
>> # New Ticket Created by Cosimo Streppone
>> # Please include the string: [perl #47127]
>> # in the subject line of all future correspondence about this issue.
>> # http://rt.perl.org/rt3/Ticket/Display.html?id=47127 >
>
>> Just found out
I am immediately accepting and applying your correction to
config/auto/gdbm.pm, which was included in the patch. You managed to
find mistakes made by both myself and the other chief Cage Cleaner!
[li11-226:parrot] 571 $ svn diff config/auto/gdbm.pm
Index: config/auto/gdbm.pm
===
Cosimo Streppone wrote:
# New Ticket Created by Cosimo Streppone
# Please include the string: [perl #47127]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=47127 >
Hi,
I'm trying to get my feet wet with parrot.
Welcome!
# New Ticket Created by Cosimo Streppone
# Please include the string: [perl #47127]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=47127 >
Hi,
I'm trying to get my feet wet with parrot.
Just found out this test failure.
Af
13 matches
Mail list logo
