On Thu, Jun 18, 2009 at 12:10:53PM -0400, NightStrike wrote:
> Given the recent issues with libffi being so drastically out of synch
> with upstream, I was curious about boehm-gc and how that is handled.
> In getting gcj to work on Win64, the next step is boehm-gc now that
> libffi works just fine.
On Thu, Jun 18, 2009 at 5:25 PM, Hans Boehm wrote:
> What has been a problem is that while the 6.8 -> 7.0 changes cleaned
> up the code substantially, and a lot of contributed patches since then
> have done a lot more of that, that step also introduced a fair amount of
> instability. I think we're
On Thu, 18 Jun 2009, NightStrike wrote:
So it seems that boehm-gc is in the exact state as libffi.
This is yet another example of why we shouldn't duplicate sources...
Hans, would you be willing to bring boehm-gc up to speed so that we
can start getting it to work for Win64? Without this,
NightStrike wrote:
> On Thu, Jun 18, 2009 at 2:02 PM, Andrew Haley wrote:
>> NightStrike wrote:
>>> Given the recent issues with libffi being so drastically out of synch
>>> with upstream, I was curious about boehm-gc and how that is handled.
>>> In getting gcj to work on Win64, the next step is bo
On Thu, Jun 18, 2009 at 2:02 PM, Andrew Haley wrote:
> NightStrike wrote:
>> Given the recent issues with libffi being so drastically out of synch
>> with upstream, I was curious about boehm-gc and how that is handled.
>> In getting gcj to work on Win64, the next step is boehm-gc now that
>> libffi
NightStrike wrote:
> Given the recent issues with libffi being so drastically out of synch
> with upstream, I was curious about boehm-gc and how that is handled.
> In getting gcj to work on Win64, the next step is boehm-gc now that
> libffi works just fine. However, the garbage collector is in ter
NightStrike wrote:
On Thu, Jun 18, 2009 at 12:58 PM, Andrew Haley wrote:
NightStrike wrote:
On Thu, Jun 18, 2009 at 12:27 PM, David Daney wrote:
NightStrike wrote:
Given the recent issues with libffi being so drastically out of synch
with upstream, I was curious about boehm-gc and how that is
On Thu, Jun 18, 2009 at 12:58 PM, Andrew Haley wrote:
> NightStrike wrote:
>> On Thu, Jun 18, 2009 at 12:27 PM, David Daney
>> wrote:
>>> NightStrike wrote:
Given the recent issues with libffi being so drastically out of synch
with upstream, I was curious about boehm-gc and how that is h
Andrew Haley wrote:
NightStrike wrote:
On Thu, Jun 18, 2009 at 12:27 PM, David Daney wrote:
NightStrike wrote:
Given the recent issues with libffi being so drastically out of synch
with upstream, I was curious about boehm-gc and how that is handled.
In getting gcj to work on Win64, the next st
NightStrike wrote:
> On Thu, Jun 18, 2009 at 12:27 PM, David Daney
> wrote:
>> NightStrike wrote:
>>> Given the recent issues with libffi being so drastically out of synch
>>> with upstream, I was curious about boehm-gc and how that is handled.
>>> In getting gcj to work on Win64, the next step is
On Thu, Jun 18, 2009 at 12:27 PM, David Daney wrote:
> NightStrike wrote:
>>
>> Given the recent issues with libffi being so drastically out of synch
>> with upstream, I was curious about boehm-gc and how that is handled.
>> In getting gcj to work on Win64, the next step is boehm-gc now that
>> lib
NightStrike wrote:
Given the recent issues with libffi being so drastically out of synch
with upstream, I was curious about boehm-gc and how that is handled.
In getting gcj to work on Win64, the next step is boehm-gc now that
libffi works just fine. However, the garbage collector is in terrible
Given the recent issues with libffi being so drastically out of synch
with upstream, I was curious about boehm-gc and how that is handled.
In getting gcj to work on Win64, the next step is boehm-gc now that
libffi works just fine. However, the garbage collector is in terrible
shape and will need a
13 matches
Mail list logo
