chromatic via RT wrote:
> On Tuesday 23 December 2008 14:53:15 Jarkko Hietaniemi wrote:
>
>> I am seeing some new warnings, if I find the time I'll file a new bug on
>> those. An easy quick one to fix would be this:
>>
>> cc: Info: ./include/parrot/sub.h, line 47: Trailing comma found in
>> enume
On Tuesday 23 December 2008 14:53:15 Jarkko Hietaniemi wrote:
> I am seeing some new warnings, if I find the time I'll file a new bug on
> those. An easy quick one to fix would be this:
>
> cc: Info: ./include/parrot/sub.h, line 47: Trailing comma found in
> enumerator list. (trailcomma)
> } sub_
.pl and/or during compilation.
>
> Thanks for the report.
Thanks for looking into it. I synced to r34297 and it seems to compile
in Tru64, thanks!
I am seeing some new warnings, if I find the time I'll file a new bug on
those. An easy quick one to fix would be this:
cc: Info: ./inclu
On Wednesday 03 December 2008 18:00:32 Jarkko Hietaniemi wrote:
> First we get a couple of warnings fro some files, but then one file
> refuses to compile (see below). I didn't notice any other warnings or
> failures during Configure.pl and/or during compilation.
Thanks for the report.
> src/op
; uname -a
OSF1 kosh.hut.fi V5.1 2650 alpha
kosh:/tmp/jhi/parrot/parrot-0.8.0 ; cc -V
Compaq C V6.5-011 on Compaq Tru64 UNIX V5.1B (Rev. 2650)
Compiler Driver V6.5-003 (sys) cc Driver
kosh:/tmp/jhi/parrot/parrot-0.8.0 ;
..
src/ops/core_ops.c
cc: Warning: src/ops/object.ops, line 436: Non-void
s ticket.
If we could get a test run on Tru64 again, that'd be great. ^_^
Thanks, applied as r24799
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #49590]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=49590 >
Attached.
--
Jarkko Hietaniemi <[EMAIL PROTECTED]> http://www.iki.fi/jhi/ "There
On Wed, 9 Jan 2008, Jarkko Hietaniemi wrote:
> --- config/init/hints/dec_osf.pm.dist 2008-01-09 04:57:50.0 +0200
> +++ config/init/hints/dec_osf.pm 2008-01-09 05:23:23.0 +0200
> @@ -43,8 +45,9 @@
> $conf->data->set( linkflags => $linkflags );
> }
>
> -# Re
Jarkko Hietaniemi wrote:
--- config/init/hints/dec_osf.pm.dist 2008-01-09 04:57:50.0 +0200
+++ config/init/hints/dec_osf.pm2008-01-09 05:23:23.0 +0200
@@ -14,8 +14,10 @@
Jarkko: Our RT system doesn't pick up new submissions that go (only) to
[EMAIL PROTECTED]
Coul
--- config/init/hints/dec_osf.pm.dist 2008-01-09 04:57:50.0 +0200
+++ config/init/hints/dec_osf.pm2008-01-09 05:23:23.0 +0200
@@ -14,8 +14,10 @@
if ( $ccflags !~ /-pthread/ ) {
$ccflags .= ' -pthread';
}
+if ( $ccflags !~ /-D_REENTRANT/ ) {
+
What does atan2(0, 0) generate on tru64?
On Jan 5, 2008, at 7:51 PM, Jarkko Hietaniemi wrote:
--- src/pmc/complex.pmc.dist2008-01-06 00:48:21.0 +0200
+++ src/pmc/complex.pmc 2008-01-06 02:53:34.0 +0200
@@ -1180,7 +1180,10 @@
im = 0.0;
RE(d) = log(sqrt
On Saturday 05 January 2008 17:51:41 Jarkko Hietaniemi wrote:
> --- src/pmc/complex.pmc.dist 2008-01-06 00:48:21.0 +0200
> +++ src/pmc/complex.pmc 2008-01-06 02:53:34.0 +0200
Thanks, applied as r24578.
I'm really glad to hear the implication that Tru64 can
--- src/pmc/complex.pmc.dist2008-01-06 00:48:21.0 +0200
+++ src/pmc/complex.pmc 2008-01-06 02:53:34.0 +0200
@@ -1180,7 +1180,10 @@
im = 0.0;
RE(d) = log(sqrt(re*re + im*im));
-IM(d) = atan2(im, re);
+ if (re == 0.0 && im == 0.0) /* atan2(0,
I think these errors were because p5rx.t was in the midst of being
converted from Perl 5 to PIR (and was left with a number of
failing tests). I was getting similar (identical?) failures
for p5rx.t on my x86_64 platform.
I think that r16593 fixes p5rx.t -- if you could
test it on tru64 to
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #41250]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41250 >
---
osname= dec_osf
osvers= 5.1a
arch= alpha-dec_osf-thread-multi
cc= cc V6.4
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #41256]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41256 >
---
osname= dec_osf
osvers= 5.1a
arch= alpha-dec_osf-thread-multi
cc= cc V6.4
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #41251]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41251 >
---
osname= dec_osf
osvers= 5.1a
arch= alpha-dec_osf-thread-multi
cc= cc V6.4
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #41253]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41253 >
---
osname= dec_osf
osvers= 5.1a
arch= alpha-dec_osf-thread-multi
cc= cc V6.4
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #41255]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41255 >
---
osname= dec_osf
osvers= 5.1a
arch= alpha-dec_osf-thread-multi
cc= cc V6.4
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #41249]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41249 >
---
osname= dec_osf
osvers= 5.1a
arch= alpha-dec_osf-thread-multi
cc= cc V6.4
Fixed in r16570, thanks!
Pm
Now fixed in r16570, thanks!
Pm
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #41254]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41254 >
---
osname= dec_osf
osvers= 5.1a
arch= alpha-dec_osf-thread-multi
cc= cc V6.4
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #41257]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41257 >
---
osname= dec_osf
osvers= 5.1a
arch= alpha-dec_osf-thread-multi
cc= cc V6.4
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #41248]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41248 >
---
osname= dec_osf
osvers= 5.1a
arch= alpha-dec_osf-thread-multi
cc= cc V6.4
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #41247]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41247 >
---
osname= dec_osf
osvers= 5.1a
arch= alpha-dec_osf-thread-multi
cc= cc V6.4
On Mon Dec 18 18:25:24 2006, jhi wrote:
> Two patches, the first is needed for parrot trunk to compile at all
> in Tru64, the second one is needed to dodge dozens of core dumps.
> There still are some, will take a closer look when I have more time,
> but least this way there is less wa
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #41110]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41110 >
Original Message
Subject: [PATCH] tru64: compile (src/nc
> The second one: in tru64 malloc/calloc/realloc of zero bytes returns
> a NULL ptr (quite logical, in a way: you couldn't put anything in a
> memory block of zero bytes...). I guess one could be fancier and
> add a probe for this feature in Configure.pl, but I was feeli
Two patches, the first is needed for parrot trunk to compile at all
in Tru64, the second one is needed to dodge dozens of core dumps.
There still are some, will take a closer look when I have more time,
but least this way there is less wading in core dumps.
In more detail:
The first one is
un-subscribe
On 8/4/06, Chip Salzenberg via RT <[EMAIL PROTECTED]> wrote:
Fixed in svn by deleting that never-will-work-again japh,
which hacked internals in an amazingly evil way.
Chip Salzenberg via RT wrote:
> parrot obeys you
> when you ask it politely
> to halt and catch fire
The test harness
should kindly be told about
this confusing anomaly
I never could get my
haikus to work
--
Jarkko Hietaniemi <[EMAIL PROTECTED]> http://www.iki.fi/jhi/ "There is this
special
bio
Fixed in svn by deleting that never-will-work-again japh,
which hacked internals in an amazingly evil way.
parrot obeys you
when you ask it politely
to halt and catch fire
Fixed in svn.
Actual bug was causing malloc(0).
Proximate bug is that, on tru64, malloc(0) fails. :-)
Until we know what these I/O ops should do, seg faults aren't
unexpected. Nor are they something we can meaningfully fix.
This ticket now depends on the review of the I/O pdd.
This ticket now depends on ResizeableBooleanArray rewrite.
Am Donnerstag, 3. August 2006 23:29 schrieb Chip Salzenberg:
> Wow. So I've just learned that our test harness ignores seg faults.
Nope. It's Test::* TODO magic. From t/examples/japh.t:
# known reasons for failure
my %todo = ( 1 => 'opcode "pack" is gone',
2 => 'opcode "pack" is
Wow. So I've just learned that our test harness ignores seg faults. Which
explains why t/examples/japh.t keeps reporting "all tests successful" when
actually they're mostly segfaulting and otherwise failing.
This particular japh uses threading, which is known not to work until the
STM work by Ch
Jerry Gay via RT wrote:
> i've related this ticket to #38887: (Nobody) Result of INFINITY or NAN
> stringification is platform dependent [new]
>
> there are many platforms failing NaN/Inf related tests due to this issue.
That is very true, and very worthy of a separate ticket, but isn't
the failu
hcf is actually supposed to explode if possible. Not sure if we should:
1) skip the test usually;
2) close the ticket as "not a bug"
3) eliminate this particular (silly) dynamic opcode.
Regards.
On Jul 7, 2006, at 2:04 AM, Jarkko Hietaniemi (via RT) wrote:
# New Ticket Created by Jarkko Hiet
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #39752]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39752 >
(dbx) run --gc-debug t/pmc/lexicals_27.pir
# Failed test (t/op/lexicals.t at l
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #39751]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39751 >
(dbx) run --gc-debug t/dynoplibs/myops_4.pir
neither here
thread 0x3 signal Segment
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #39755]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39755 >
t/pmc/complexok 32/53
# Failed test (t/pmc/complex.t at
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #39756]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39756 >
(dbx) run --gc-debug t/examples/japh_10.pasm
run --gc-debug t/examples/japh_10.pasm
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #39750]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39750 >
(dbx) run --gc-debug t/examples/japh_12.pasm
Parrot VM: PANIC: Out of bound registe
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #39753]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39753 >
(dbx) run --gc-debug t/pmc/io_1.pir
Undef ok 1
Undef ok 2
Assertion failed: (unsign
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #39754]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39754 >
(dbx) run --gc-debug t/pmc/resizablebooleanarray_20.pasm
thread 0x3 signal Segmenta
Will Coleda wrote:
> While you're waiting, we should improve the test for readline: we
> used to have similar failures where we found readline (or other
> probed thingees) but the version was not recent enough for us to link
> with.
(1) Some sort of grouping for the libraries so that only th
While you're waiting, we should improve the test for readline: we
used to have similar failures where we found readline (or other
probed thingees) but the version was not recent enough for us to link
with.
Regards.
On Jul 2, 2006, at 4:47 PM, Jarkko Hietaniemi wrote:
Leopold Toetsch wro
Leopold Toetsch wrote:
> On Jul 2, 2006, at 15:04, Jarkko Hietaniemi wrote:
>
>> But the -lreadline is needed for something later?
>
> If readline is available, it can be used at interactive prompts, but
> it's not absolutely needed.
I think I will first try to get the admins to get compile a n
On Jul 2, 2006, at 15:04, Jarkko Hietaniemi wrote:
But the -lreadline is needed for something later?
If readline is available, it can be used at interactive prompts, but
it's not absolutely needed.
$ cd languages/perl6/
...
[EMAIL PROTECTED] $ ../../parrot perl6.pbc
p6> say 'ok'
ok
p6>
le
Leopold Toetsch wrote:
> On Jul 1, 2006, at 21:42, Jarkko Hietaniemi wrote:
>
>> (1) I don't know all those -libraries are being listed, the test
>> program certainly doesn't need them... yes, the linker should
>> know to ignore them as unused... but:
>>
>> (2) This is not Linux so that -l
On Jul 1, 2006, at 21:42, Jarkko Hietaniemi wrote:
(1) I don't know all those -libraries are being listed, the test
program certainly doesn't need them... yes, the linker should
know to ignore them as unused... but:
(2) This is not Linux so that -lgmp and -lreadline are not "standard"
rintf died during execution: Can't run the snprintf
testing program: at config/auto/snprintf.pm line 33.
"cxx" is the Tru64 C++ compiler.
(1) I don't know all those -libraries are being listed, the test
program certainly doesn't need them... yes, the linker should
On Jun 29, 2006, at 18:48, Jarkko Hietaniemi wrote:
Any way to add verbosity to e.g. see which commands are being run?
perl Configure.pl --verbose-step=snprintf
leo
Parrot 0.4.5 in Tru64 5.1B:
$ perl Configure.pl
...
Determining if your platform supports readline.yes.
Determining if your platform supports gdbm..no.
Testing snprintf...resolve_symbols: loader error: dlopen:
libreadline.so.4: symbol "tg
Jarkko -
Is this still an issue with svn-latest ?
> [jhi - Wed Oct 05 22:27:25 2005]:
>
> Didn't notice this earlier because the whole japh.t is
> reported as succeeding even though a core dump happens
> for the subtest #10.
>
>1 pthread_kill(0x0, 0x11fffb038, 0x0, 0x11fffc010, 0x3ff000
Joshua Hoblitt via RT wrote:
>>[doughera - Thu Oct 06 07:21:15 2005]:
>>
>>I think this bug can be closed. I just got those tests to pass on
>>Sparc/Solaris 8 with gcc -m64 -mcpu=v9. (Mind you lots of other tests
>>fail, but that's a separate problem.)
>>
>>
>>
>
>
> Jarrko,
>
> Are you OK w
On Thu, Oct 06, 2005 at 10:32:40PM +0300, Jarkko Hietaniemi wrote:
> >
> > Since I don't think anyone else can test this on tru64, would you mind
> > consolidating all of the fixes discussed in this thread into a single
> > patch?
>
> Attached
On Thu, 6 Oct 2005, Joshua Hoblitt wrote:
> On Thu, Oct 06, 2005 at 01:17:57AM -0700, Jarkko Hietaniemi via RT wrote:
> > > Jarkko,
> > >
> > > I never got a response from anyone. How would you feel about closing
> > > this bug?
> >
> > I don't think it can be closed until at least another big-
On Thu, Oct 06, 2005 at 01:17:57AM -0700, Jarkko Hietaniemi via RT wrote:
> -J
>
>
>
>
> >>>
> >>
> >
> > Jarkko,
> >
> > I never got a response from anyone. How would you feel about closing
> > this bug?
>
> I don't think it can be closed until at least another big-endi
igure::Data->set(
> > ccflags => $ccflags,
> > );
>
> So the above patch should be applied so that Tru64 is happy, and works,
> but as was pointed out to me in private email, the (socklen_t*) cast
> should most probably be removed, too (and the newsize made s
( $ccflags !~ /-D_XOPEN_SOURCE=/ ) {
> +# Request all POSIX visible (not automatic for cxx, as with cc)
> +$ccflags .= ' -D_XOPEN_SOURCE=500';
> +}
> Configure::Data->set(
> ccflags => $ccflags,
> );
So the above patch should be applied so that Tru64 is hap
&newsize)) == -1)
>>>{
>>>fprintf(stderr, "accept: errno=%d", errno);
>>>/* Didn't get far enough, free the io */
>>>
>>
>>
>>Please ignore that patch, it doesn't work since socklen_t is a long,
&
The latest changes by Leo seem to have fixed this one, and similarly
#37338 and #37337.
-J
>>>
>>
>
> Jarkko,
>
> I never got a response from anyone. How would you feel about closing
> this bug?
I don't think it can be closed until at least another big-endian 64-bit
platform (like IRIX 64 is/was) has been used to verify that things work.
> -J
>
>
>
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #37361]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37361 >
Didn't notice this earlier because the whole japh.t is
reported as succeeding even
Jarkko Hietaniemi (via RT) wrote:
t/pmc/stringok 12/35
# Failed test (t/pmc/string.t at line 556)
# got: '0
# 1
# -1
# 128
It looks like #37338 and #37339 reveal the same, now fixed, bug as #37337.
leo
Jarkko Hietaniemi (via RT) wrote:
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #37337]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37337 >
t/op/compok 6/80
# Failed test (t/op/
Jarkko Hietaniemi (via RT) wrote:
cc: Info: imcc/pcc.c, line 379: In this statement, an array is being
accessed o\
utside the bounds specified for the array type. (subscrbounds)^
regs[2] = arg;^
-
nice compiler
And sure enough, regs has been declared as two-elemen
Jarkko Hietaniemi (via RT) wrote:
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #37334]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37334 >
io/io_unix.c does not compile because socklen_
o=%d", errno);
>> /* Didn't get far enough, free the io */
>>
>
>
> Please ignore that patch, it doesn't work since socklen_t is a long,
> not an int, and in Tru64 one shall not mix those.
Please ignore the ignore :-) It seems that "it depends&q
>>
>>
>
>
> Jarkko,
>
> Does this issue still occur on tru64?
Works in Parrot 0.3.0.
> -J
>
>
io */
>
Please ignore that patch, it doesn't work since socklen_t is a long,
not an int, and in Tru64 one shall not mix those.
>
>> 1989 /*
>>(dbx)
>>
>>The line->label is an impossible pointer, so deferencing causes promptly
>>a bus error.
>>
>>
>>
>
>
> Jarkko,
>
> Can you restest and confirm that this is still an issue with pdb?
These seems to have been fixed.
> Thanks,
>
> -J
>
>
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #37339]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37339 >
t/pmc/perlstringok 43/68
# Failed test (t/pmc/perlstring.t at line 1244)
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #37338]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37338 >
t/pmc/stringok 12/35
# Failed test (t/pmc/string.t at line 556)
#
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #37337]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37337 >
t/op/compok 6/80
# Failed test (t/op/comp.t at line 156)
# got:
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #37335]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37335 >
imcc/pcc.c^M
cc: Info: imcc/pcc.c, line 379: In this statement, an array is being
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #37334]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37334 >
io/io_unix.c does not compile because socklen_t is not defined.
According to the
Does anyone has access to an IRIX machine?
-J
--
On Thu, Sep 22, 2005 at 07:37:44PM +0300, Jarkko Hietaniemi wrote:
>
> >
> > Jarkko,
> >
> > Are there still outstanding issues on IRIX? AFAIK nobody else has been
> > building parrot on that platform.
>
> Unfortunately I no more have access t
>
> Jarkko,
>
> Are there still outstanding issues on IRIX? AFAIK nobody else has been
> building parrot on that platform.
Unfortunately I no more have access to that platform.
> -J
>
>
>
>
Forgot to add: in many environments (at least SGI/MIPS, AIX Power/PPC,
HP-UX/HPPA) things are even more interesting -- one can in compile time
decide between different 32-bit modes and different 64-bit modes.
(E.g. in IRIX there are two of each.) I believe the new x86-ish
processors and Linux/gcc
Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote:
> P.S. (I wish I still had Cray 90 access, the unusual-but-legal
> longsize=ptrsize=intsize=shortsize=8 nicely shook bugs to the bright
> light of day in Perl 5.)
Would break nicely ;)
leo
is 64 bit.
Weelll... I did not say *quite* that. What I said that so far the
Parrot's core seems to have worked well in systems with _some_ 64-bit
integer types available. So the Parrot core has been 64-bit _safe_,
which doesn't mean it has been _using_ 64-bit integers explicit
Nick Glencross wrote:
> Jarkko Hietaniemi wrote:
>
>
>>>Not true. We've done successful compiles before on Tru64. Maybe as of 0.0.6
>>>
> Ok, so intsize=4, which is why my md5 test tried to run. I'd be really
> grateful if some could run my inst
Jay,
Jay Scherrer wrote:
> Attached is my make test output from my laptop running Fedora Core 3
> x86_64bit: makeTest.txt
> Is there any other way I can help?
>
Thanks for that Jay. What's happened is that in the last week a new test
has gone into CVS, but I haven't had access to systems besides a
Jarkko Hietaniemi wrote:
Not true. We've done successful compiles before on Tru64. Maybe as of 0.0.6
True, not true :-) I do manual test compiles in Tru64 once in a while.
Once the packfile portability problems were solved back when, the Parrot
core at least has been pretty good rega
>
> Not true. We've done successful compiles before on Tru64. Maybe as of 0.0.6
True, not true :-) I do manual test compiles in Tru64 once in a while.
Once the packfile portability problems were solved back when, the Parrot
core at least has been pretty good regarding 64-bitness.
Attached is my make test output from my laptop running Fedora Core 3
x86_64bit: makeTest.txt
Is there any other way I can help?
Jay Scherrer
On Fri, 2005-04-01 at 11:24 -0500, MrJoltCola wrote:
> At 06:33 AM 4/1/2005, Nick Glencross wrote:
>
> >Having never had access to a Tru64
MrJoltCola wrote:
At 06:33 AM 4/1/2005, Nick Glencross wrote:
Having never had access to a Tru64 system, does that mean that parrot
is compiled 64 bit?
Two initial comments:
* This is a platform that we've not had a chance to test on, so I'm
grateful to see it tested on a new platfo
At 06:33 AM 4/1/2005, Nick Glencross wrote:
Having never had access to a Tru64 system, does that mean that parrot is
compiled 64 bit?
Two initial comments:
* This is a platform that we've not had a chance to test on, so I'm
grateful to see it tested on a new platform. It was hop
Nick Glencross wrote:
Having never had access to a Tru64 system, does that mean that parrot
is compiled 64 bit?
Two initial comments:
* This is a platform that we've not had a chance to test on, so I'm
grateful to see it tested on a new platform. It was hoped that it
would work, b
Leopold Toetsch wrote:
Original Message
Subject: a warning and a failure for parrot in Tru64
Date: Thu, 31 Mar 2005 20:41:30 +0300
From: Jarkko Hietaniemi <[EMAIL PROTECTED]>
To: Leopold Toetsch <[EMAIL PROTECTED]>
cc: Warning: pylist.pmc, line 601: In this st
Original Message
Subject: a warning and a failure for parrot in Tru64
Date: Thu, 31 Mar 2005 20:41:30 +0300
From: Jarkko Hietaniemi <[EMAIL PROTECTED]>
To: Leopold Toetsch <[EMAIL PROTECTED]>
cc: Warning: pylist.pmc, line 601: In this statement, the referenced
Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote:
> The ld -s flag caused all symbol information to be stripped from
> the libraries, which caused all the Python dynclass tests to fail.
> (The -s can be used in Perl 5 since the XS builds up a separate
> "symbol table".) Patch attached.
Thanks, applie
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #34352]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=34352 >
The ld -s flag caused all symbol information to be stripped from
the libraries, wh
Sam Ruby via RT wrote:
> Andrew Dougherty wrote:
>
>>The offending line in config/gen/makefiles/dynclasses_pl.in
>>is probably this one:
>>
>>$LD $CFLAGS $LDFLAGS $LD_LOAD_FLAGS $LIBPARROT
>>
>>That CFLAGS doesn't belong there. CFLAGS are intended to be sent to $CC,
>>not to $LD. The command
1 - 100 of 143 matches
Mail list logo
