After a little prodding around, I think the problem is that the dynops
aren't build with the rpath. I don't know how "proper" the following
patch is(i.e. linux doesn't seem to have a problem so either this is
right or the other way is right), but it does the trick.
Index: config/gen/makefiles
I was patching along the patch and hadn't tried it out myself. When I did so
tonight in the
'reconfigure' branch, I did not get good results:
CC="/usr/bin/gcc-3.3"
CX="/usr/bin/g++-3.3"
/usr/local/bin/perl Configure.pl --cc="$CC" --cxx="$CX" --link="$CX" \
--ld="$CX" --without-icu --without
On Fri Jun 01 09:29:18 2007, chromatic at wgz.org wrote:
> This patch is very close. Instead of handling compilation manually, I
> recommend instead using cc_gen() and cc_build() from
> Parrot::Configure::Step.
> See config/auto/sizes.pm for an example.
>
> -- c
>
Can you explain why using the
> > What happens when NULL is not a consective series of '\0' chars?
>
> I think that it breaks.
>
> > Are there such platforms and are they releavant for parrot?
>
> I believe that this assumption is endemic in Perl 5, and it's never
> hindered
> Perl 5's portability. The C FAQ gives examples
On Sun, 3 Jun 2007 09:57:25 -0700
chromatic <[EMAIL PROTECTED]> wrote:
> On Sunday 03 June 2007 05:39:01 James E Keenan wrote:
>
> > chromatic wrote:
>
> > > If you're using a modern GNU ld, remove the shared library and
> > > add a few more flags to LINK_DYNAMIC in Makefile. Here's mine:
> > >
On Mon, 04 Jun 2007 13:39:44 -0700
"Parrot via RT" <[EMAIL PROTECTED]> wrote:
> Greetings,
>
> This message has been automatically generated in response to the
> creation of a parrotbug regarding:
> "Re: GC bug on freebsd/x86, triggered by a perl6 test"
This ticket is a duplicate of RT #43
On Mon, 04 Jun 2007 21:39:08 +0100
Jonathan Worthington <[EMAIL PROTECTED]> wrote:
> > Assertion failed: (s->encoding && s->charset
> > && !PObj_on_free_list_TEST(s)), function string_hash, file
> > src/string.c, line 2024. Abort trap (core dumped)
> >
> I'm betting that it's the !PObj_on_free_l
On Mon, 4 Jun 2007 13:07:18 -0700
chromatic <[EMAIL PROTECTED]> wrote:
> On Monday 04 June 2007 12:49:45 Mark Glines wrote:
>
> > (the LD_LIBRARY_PATH bit is required on freebsd so parrot can find
> > libparrot.so.)
>
> The GNU linker supports a flag to mark a relocatable shared library.
> From
Mark Glines wrote:
I tried the perl6 testsuite on freebsd at Coke's request, and
discovered a test that fails on freebsd but succeeds on linux. The
test seems to be a GC-related assertion failure; parrot -G does not
crash, parrot without -G does crash.
...
Assertion failed: (s->encoding && s->
# New Ticket Created by chromatic
# Please include the string: [perl #43129]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=43129 >
On Monday 04 June 2007 12:49:45 Mark Glines wrote:
> (the LD_LIBRARY_PATH bit is required
On Monday 04 June 2007 12:49:45 Mark Glines wrote:
> (the LD_LIBRARY_PATH bit is required on freebsd so parrot can find
> libparrot.so.)
The GNU linker supports a flag to mark a relocatable shared library. From my
Makefile:
-Wl,-rpath=/home/chromatic/dev/parrot/blib/lib
I don't know
I tried the perl6 testsuite on freebsd at Coke's request, and
discovered a test that fails on freebsd but succeeds on linux. The
test seems to be a GC-related assertion failure; parrot -G does not
crash, parrot without -G does crash.
I am running on freebsd 6.2, in a checkout of svn r18803. I di
Nicholas Clark schrieb:
On Sun, Jun 03, 2007 at 08:00:18AM -0700, Bernhard Schmalhofer via RT wrote:
I have looked at the 'more_memory.patch' and I'm wondering about the
portability.
In that patch loops where pointers are explicitly set to NULL
are replaced with a
memset( start, 0, len);
Parrot Bug Summary
http://rt.perl.org/rt3/NoAuth/parrot/Overview.html
Generated at Mon Jun 4 13:00:01 2007 GMT
---
* Numbers
* New Issues
* Overview of Open Issues
* Ticket Status By Version
* Requestors with mo
14 matches
Mail list logo
