Aah, you all are amazing -- thank you!! Applied and merged.
Cheers,
Andy
On Mon 17 Feb 2020 20:27, Charles Stanhope writes:
> On 2/16/20, Charles Stanhope wrote:
>> On 2/16/20, Mike Gran wrote:
>>>
>>> I can confirm that Charles's patch, plus another one line patch
>>> to define
On 2/16/20, Charles Stanhope wrote:
> On 2/16/20, Mike Gran wrote:
>>
>> I can confirm that Charles's patch, plus another one line patch
>> to define CPU_SETSIZE, is enough to get Guile 3.0.x to build and run
>> on my box. All tests pass except strptime in French, and the absence
>> of crypt.
On 2/16/20, Mike Gran wrote:
> On Fri, Feb 14, 2020 at 09:46:04AM -0800, Charles Stanhope wrote:
>> Andy, I don't know if you'd want to continue this here or on
>> lightening's gitlab page, but I looked into this a little bit a few
>> minutes here and there this past weeek. The x86 "fast-call"
Excellent, and thank you all! I've been WIndowsless for a few weeks, but
that should change again soon.
On Sun, Feb 16, 2020 at 6:23 PM Mike Gran wrote:
> On Fri, Feb 14, 2020 at 09:46:04AM -0800, Charles Stanhope wrote:
> > Andy, I don't know if you'd want to continue this here or on
> >
Am 14.02.2020 um 18:46 schrieb Charles Stanhope:
On 2/6/20, Charles Stanhope wrote:
On 2/6/20, Andy Wingo wrote:
Given that John said that compilation went fine with
GUILE_JIT_THRESHOLD=-1, I think perhaps this problem may have been fixed
in the past. My suspicions are that this issue is
On 2/6/20, Charles Stanhope wrote:
> On 2/6/20, Andy Wingo wrote:
>
>> Given that John said that compilation went fine with
>> GUILE_JIT_THRESHOLD=-1, I think perhaps this problem may have been fixed
>> in the past. My suspicions are that this issue is an ABI issue with
>> lightening that could
On 2/6/20, Andy Wingo wrote:
> Given that John said that compilation went fine with
> GUILE_JIT_THRESHOLD=-1, I think perhaps this problem may have been fixed
> in the past. My suspicions are that this issue is an ABI issue with
> lightening that could perhaps be reproduced by:
>
> git co
On Mon 20 Jan 2020 18:22, Mike Gran writes:
> On Mon, Jan 20, 2020 at 11:38:35AM -0500, John Cowan wrote:
>> Yes, gladly, but I don't know how to get one in this context. Do I need to
>> add some flags to the Makefile, and if so, where? (It's a twisty maze of
>> passages, all different.) .
On Wed, Feb 05, 2020 at 04:11:04PM -0500, John Cowan wrote:
> On Mon, Feb 3, 2020 at 5:11 PM szgyg wrote:
>
> On Fri, Jan 31, 2020 at 09:23:19AM -0500, John Cowan wrote:
> > > Aaaand... Cygwin doesn't do core dumps. Under the skin it's WIndows,
> > after
> > > all. This is what I get when I
On Fri, Jan 31, 2020 at 09:23:19AM -0500, John Cowan wrote:
> Aaaand... Cygwin doesn't do core dumps. Under the skin it's WIndows, after
> all. This is what I get when I specify ulimit -c unlimited and rebuild:
> [...]
Please see my previous mail on how to get a real core dump on cygwin
Aaaand... Cygwin doesn't do core dumps. Under the skin it's WIndows, after
all. This is what I get when I specify ulimit -c unlimited and rebuild:
Exception: STATUS_ACCESS_VIOLATION at rip=0055A8B1B25
rax= rbx=FF90 rcx=FF90
rdx=0034964A
John Cowan skribis:
> Both Cygwin and MacOS crash in pretty much the same way. By disabling the
> JIT, I was able to get the Cygwin build to run to completion.
That I understand. However, I was asking for the backtrace of the crash
on Cygwin when JIT is enabled. Could you grab it?
Thanks in
t: Friday January 24 2020 9:36:59AM
Subject: bug#39118: Segfault while building on 64-bit Cygwin
Both Cygwin and MacOS crash in pretty much the same way. By disabling
the JIT, I was able to get the Cygwin build to run to completion. On
MacOS with --disable-jit, however, I am now getting an entir
Both Cygwin and MacOS crash in pretty much the same way. By disabling the
JIT, I was able to get the Cygwin build to run to completion. On MacOS
with --disable-jit, however, I am now getting an entirely new failure:
CC readline.lo
readline.c:432:7: warning: implicitly declaring library
Hi,
John Cowan skribis:
> Thanks. Unfortunately, the standard recipe for making core dumps on Mac
This bug report is about Cygwin, not macOS, right? :-)
Ludo’.
I'm no longer talking about Cygwin (which builds fine without JIT). I'm
now talking about MacOS Catalina, which needs a core dump to debug, but on
which nobody seems to know how to enable core dumps.
On Tue, Jan 21, 2020 at 1:41 PM szgyg wrote:
> On Tue, Jan 21, 2020 at 10:01:58AM +0100,
Thanks. Unfortunately, the standard recipe for making core dumps on Mac
(put "limit core unlimited" into /etc/launchd.conf and reboot, make sure
/cores is writable, set ulimit -c unlimited) seem to actually enable them
on MacOS Catalina (10.15.2). I have tested with SIGQUIT and SIGSEGV on
On Tue, Jan 21, 2020 at 10:01:58AM +0100, Ludovic Courtès wrote:
> but before that you’d run
> “ulimit -c unlimited” in that shell to make sure there’s a core dumped
> when it crashes.
This won't work on cygwin. If you want a core dump, you should use the
dumper tool, as described here
Yes, gladly, but I don't know how to get one in this context. Do I need to
add some flags to the Makefile, and if so, where? (It's a twisty maze of
passages, all different.) . Note that this *is* a build with JIT enabled;
when I disable it using the env variable, there are no errors and 3.0.0
Hi John,
John Cowan skribis:
> Guile 2.9.9, like .8 and .7, does not build on Cygwin (64 bit). Configure
> runs without error, but make crashes with this (truncated to just the tail):
>
> Making all in bootstrap
> make[2]: Entering directory
>
20 matches
Mail list logo
