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: Y
Jens Axel Søgaard 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 I'm building fo
David Bremner 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.
Installi
David Bremner 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
> s
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
unst
Matthew Flatt 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 attachment, sinc
Matthew Flatt 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. Currently this
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 th
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 c
On Mon, 27 Feb 2012 09:46:43 -0700, Matthew Flatt 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?
It doesn
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
/home/bremner/racket-
On Tue, 10 May 2011 23:58:07 -0300, David Bremner 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 dev
On Tue, 10 May 2011 00:14:42 -0300, David Bremner wrote:
> On Mon, 9 May 2011 06:56:48 -0600, Matthew Flatt 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 S
On Mon, 9 May 2011 06:56:48 -0600, Matthew Flatt 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 (squeeze), one should
On Fri, 29 Apr 2011 08:46:32 -0600, Matthew Flatt 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
current git mast
On Fri, 29 Apr 2011 08:46:32 -0600, Matthew Flatt wrote:
> I've pushed fixes for kFreeBSD, so let me know if you encounter further
> problems.
>
The latest commit (b5f86a26...) seems to fix all the remaining problems
I know about. The current git master builds, build collects, and passes
minimal
On Thu, 28 Apr 2011 19:37:42 -0600, Matthew Flatt 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
traceback from
On Thu, 28 Apr 2011 07:00:46 -0600, Matthew Flatt 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 bus error
ep 17 00:00:00 2001
From: David Bremner
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/racket/src/n
On Wed, 27 Apr 2011 18:48:51 -0600, Matthew Flatt 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. Resident set s
matic? Can someone with a stock FreeBSD-i386
confirm that 5.1 (or git) builds there?
>From 5da8f3df6174e509c60fc62b3ad0dd6b8ce572cf Mon Sep 17 00:00:00 2001
From: David Bremner
Date: Tue, 26 Apr 2011 22:25:55 -0300
Subject: [PATCH] add sys/cdefs.h and sys/param.h before floatingpoint.h
This
On Fri, 22 Apr 2011 12:06:10 -0400, Asumu Takikawa wrote:
> Since collects/openssl/mzssl.rkt depends on SSLv2 (presumably for legacy
> support?), this seems to cause a build failure on Debian testing and
> newer using the system libraries.
Yeah, this is a problem for the official Debian builds a
On Sun, 24 Apr 2011 08:58:19 -0600, Matthew Flatt wrote:
> It's in the "racket" subdirectory. I've changed the `configure' case
> from "FreeBSD" to "*FreeBSD", which I think is the right fix.
Latest master and 5.1+your patch builds on Debian/kFreeBSD, _if_ I use
configure --enable-cgcdefault. Ot
On Thu, 21 Apr 2011 23:06:23 -0300, David Bremner wrote:
> On Thu, 21 Apr 2011 19:32:18 -0600, Matthew Flatt 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
On Thu, 21 Apr 2011 19:32:18 -0600, Matthew Flatt wrote:
> At Thu, 21 Apr 2011 22:22:00 -0300, David Bremner 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
&
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 def
26 matches
Mail list logo
