[racket-dev] support for arm64 / aarch64

2014-12-29 Thread David Bremner
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:

Re: [racket-dev] crash running raco setup with racket 6.1

2014-10-23 Thread David Bremner
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

Re: [racket-dev] crash running raco setup with racket 6.1

2014-10-23 Thread David Bremner
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

Re: [racket-dev] crash running raco setup with racket 6.1

2014-10-23 Thread David Bremner
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

[racket-dev] crash running raco setup with racket 6.1

2014-10-22 Thread David Bremner
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

Re: [racket-dev] advice on the 6.x build system.

2014-10-17 Thread David Bremner
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

[racket-dev] advice on the 6.x build system.

2014-10-16 Thread David Bremner
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

Re: [racket-dev] advice on the 6.x build system.

2014-10-16 Thread David Bremner
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.

[racket-dev] potentially renaming /usr/bin/planet to /usr/bin/planet-racket in Debian

2012-07-29 Thread David Bremner
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

Re: [racket-dev] build hang on s390x

2012-02-27 Thread David Bremner
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?

[racket-dev] build hang on s390x

2012-02-24 Thread David Bremner
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

Re: [racket-dev] memory consumption (bug?) on Debian/kFreeBSD-i386

2011-05-11 Thread David Bremner
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

Re: [racket-dev] memory consumption (bug?) on Debian/kFreeBSD-i386

2011-05-10 Thread David Bremner
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

Re: [racket-dev] memory consumption (bug?) on Debian/kFreeBSD-i386

2011-05-09 Thread David Bremner
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

Re: [racket-dev] memory consumption (bug?) on Debian/kFreeBSD-i386

2011-05-09 Thread David Bremner
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

Re: [racket-dev] memory consumption (bug?) on Debian/kFreeBSD-i386

2011-04-29 Thread David Bremner
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. The latest commit (b5f86a26...) seems to fix all the remaining problems I know about. The current git master builds, build collects,

Re: [racket-dev] memory consumption (bug?) on Debian/kFreeBSD-i386

2011-04-28 Thread David Bremner
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.

Re: [racket-dev] memory consumption (bug?) on Debian/kFreeBSD-i386

2011-04-28 Thread David Bremner
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

Re: [racket-dev] memory consumption (bug?) on Debian/kFreeBSD-i386

2011-04-28 Thread David Bremner
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

Re: [racket-dev] memory consumption (bug?) on Debian/kFreeBSD-i386

2011-04-28 Thread David Bremner
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

Re: [racket-dev] racket 5.1 build failure on debian/kfreebsd

2011-04-24 Thread David Bremner
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

[racket-dev] racket 5.1 build failure on debian/kfreebsd

2011-04-21 Thread David Bremner
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