Hi All;
I'm trying to build 5.1 on debian/kfreebsd, and I'm having problems with
src/racket/src/port.c
The main problems stem from MZ_FLUSH_* not being defined. This in turn
seems to be because MZ_FDS is not defined at line 259. At that point I
got stuck, I couldn't see what controlled this
On Thu, 21 Apr 2011 23:06:23 -0300, David Bremner brem...@debian.org wrote:
On Thu, 21 Apr 2011 19:32:18 -0600, Matthew Flatt mfl...@cs.utah.edu wrote:
Besides some code-organization problems, my guess is that sconfig.h
doesn't figure out that you're on a FreeBSD variant. Do you know what
On Wed, 27 Apr 2011 18:48:51 -0600, Matthew Flatt mfl...@cs.utah.edu wrote:
Do you have any process limits set? (My impression is memory is often
limited by default on FreeBSD systems.)
There was a limit of 512M on data segment size, which I raised to 2G, but it
doesn't seem to change much.
00:00:00 2001
From: David Bremner brem...@debian.org
Date: Thu, 28 Apr 2011 20:00:37 -0300
Subject: [PATCH] Add cdefs.h and param.h before ieeefp.h. Change ieeefp.h to
machine/ieeefp.h
---
src/racket/src/number.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/src
On Thu, 28 Apr 2011 07:00:46 -0600, Matthew Flatt mfl...@cs.utah.edu wrote:
To make 3m work right, src/racket/gc2/sighand.c needs a
__FreeBSD_kernel__ on line 128:
#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__) ||
defined(__NetBSD__) || defined(__OpenBSD__)
Does that avoid the
On Thu, 28 Apr 2011 19:37:42 -0600, Matthew Flatt mfl...@cs.utah.edu wrote:
But then I had a bus error, as before.
A stack trace might be helpful. Otherwise, I guess I'll have to set up
a kFreeBSD virtual machine.
I couldn't find any documentation on fpsetmask so far, but here is a
On Fri, 29 Apr 2011 08:46:32 -0600, Matthew Flatt mfl...@cs.utah.edu wrote:
I've pushed fixes for kFreeBSD, so let me know if you encounter further
problems.
It seems the updates (gcc?) on kFreeBSD (i386 and amd64) cause a
regression: I am getting a segmentation fault from make gracket3m with
On Mon, 9 May 2011 06:56:48 -0600, Matthew Flatt mfl...@cs.utah.edu wrote:
Maybe someone decided that SIGSEGV is the right signal after all for an
mprotect() violation (which Rackets catches as a write barrier) instead
of SIGBUS.
This seems to be about right. In Debian/kFreeBSD stable
On Tue, 10 May 2011 00:14:42 -0300, David Bremner brem...@debian.org wrote:
On Mon, 9 May 2011 06:56:48 -0600, Matthew Flatt mfl...@cs.utah.edu wrote:
Maybe someone decided that SIGSEGV is the right signal after all for an
mprotect() violation (which Rackets catches as a write barrier
On Tue, 10 May 2011 23:58:07 -0300, David Bremner brem...@debian.org wrote:
I don't claim to understand all the implications yet, but the following
patch seems to work, i.e. catching both SIGSEGV and SIGBUS with the same
handler.
As a followup, I talked a bit more to the Debian/kFreeBSD
Hi, it's the debian guys again and their wacky architectures.
The build on the s390x (64 bit version) seems to hang at the following
place
/usr/bin/make ../gracket3m
make[6]: Entering directory `/home/bremner/racket-5.2.1+dfsg1/build/gracket/gc2'
../../racket/racket3m -cqu
On Mon, 27 Feb 2012 09:46:43 -0700, Matthew Flatt mfl...@cs.utah.edu wrote:
My guess is that something is going wrong with the GC's write barrier.
In src/racket/gc2/newgc.c around line 2677, if you change 1 to 0 in
newgc-generations_available = 1;
does the build make further progress?
Hi All;
We're currently trying to figure out the right way to handle a name
conflict in Debian between racket and an rss aggregator named
planet-venus.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680685
I don't use the command /usr/bin/planet myself, so I was wondering if
anybody
I've been been trying to rework the debian racket packaging, and to
understand the new racket build system. I need to have the two seperate
targets, which most of the package installation is done in the the
build-indep-stamp target.
The following makefile snippet is _almost_ working, except
Matthew Flatt mfl...@cs.utah.edu writes:
That said, is there a particular reason that basing the build on the
git repo would be better?
One reason is that I need I need to track from release to release the
files that are removed from the racket source by debian for
licensing-related reasons.
Matthew Flatt mfl...@cs.utah.edu writes:
Meanwhile, I haven't answered your original question. Can you remind me
of the specific steps that I'd need to follow to try the script that
you sent before?
With your indulgence, I'll just answer this part now. I have re-included
the Makefile as an
Building racket 6.1, from racket-6.1-src.tgz, the debian build
calls make install twice,
the first time with PLT_EXTRA=--no-docs --no-zo, and the second time
with PLT_EXTRA=--no-launcher --no-install --no-post-install. This
second (main) call is crashing after some recent change in Debian
David Bremner da...@tethera.net writes:
Building racket 6.1, from racket-6.1-src.tgz, the debian build
calls make install twice,
the first time with PLT_EXTRA=--no-docs --no-zo, and the second time
with PLT_EXTRA=--no-launcher --no-install --no-post-install. This
second (main) call
David Bremner da...@tethera.net writes:
As a point of information, I can duplicate the crash with yesterdays
snapshot (20141022-d9f2a84). I didn't bother getting a backtrace there,
but I can if it would help.
I verified that the version of libcairo2 is what makes a difference.
Installing
Jens Axel Søgaard jensa...@soegaard.net writes:
It might me worth doubling checking that the versions of the shared
libaries that Racket loads matches your expectations.
Then again, maybe there were an API change in Cairo that
caused the problem - and if so the above is irrelevant.
Since
A user submitted the attached patch for partial support for arm64 on
Debian/Ubuntu. It only enables cgc, 3m still hangs during compilation.
If the patch makes sense to you, perhaps you'd like to apply it
upstream.
d
From 7b5acfba9a1df00f0427d1d2e1a92570da3ab2d1 Mon Sep 17 00:00:00 2001
From:
21 matches
Mail list logo
