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 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 specify ulimit -c unlimited and rebuild:
> > [...]
>
> Please see my
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
Hello,
John Cowan skribis:
> Yes, gladly, but I don't know how to get one in this context.
You would unpack, configure, and build like you did before (with JIT
enabled, so as to reproduce the crash), but before that you’d run
“ulimit -c unlimited” in that shell to make sure there’s a core
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
>
22 matches
Mail list logo
