From: Thien-Thi Nguyen <ttn@gnuvola.org>
To: bug-guile@gnu.org
Subject: Re: [PATCH] Declare `GC_dump' ourselves if <gc/gc.h> doesn't.
Date: Tue, 12 Jan 2010 05:40:37 +0100 [thread overview]
Message-ID: <87k4vodjga.fsf@ambire.localdomain> (raw)
In-Reply-To: 878wc45m5w.fsf@gnu.org
() ludo@gnu.org (Ludovic Courtès)
() Mon, 11 Jan 2010 23:09:15 +0100
Andy Wingo <wingo@pobox.com> writes:
> On Sat 09 Jan 2010 14:28, Thien-Thi Nguyen <ttn@gnuvola.org> writes:
>
>> +# `GC_dump' is available in GC 6.8 but not declared.
>
> Neil, you also compile with pre-7.x, no? Do we need to support this?
No. Normally checking for bdw-gc.pc rules out 6.8, but apparently
Debian (?) is shipping the .pc file for 6.8 too.
Debian Etch doesn't ship with a .pc file (AFAICT).
I infer the version from the output of
M-x apt-utils-show-package RET libgc-dev RET
reproduced below. Am i missing something?
thi
___________________________________________________________
Package: libgc-dev (Installed)
Priority: optional
Section: libdevel
Installed-Size: 516
Maintainer: Ryan Murray <rmurray@debian.org>
Architecture: i386
Source: libgc
Version: 1:6.8-1
Depends: libgc1c2 (= 1:6.8-1), libc-dev
Filename: pool/main/libg/libgc/libgc-dev_6.8-1_i386.deb
Size: 160808
MD5sum: 8fd9c6b5451059499b79c4334e907c87
SHA1: bc60de45dbd3b5ffff06497ec6a697e959ea6858
SHA256: e7cbb58a14758a914168fa617e5f3b0a46f9f703e481a00d805047862c98663f
Description: conservative garbage collector for C (development)
Boehm's GC is a garbage collecting storage allocator that is
intended to be used as a plug-in replacement for C's malloc.
This package is required to compile and link programs that use
libgc1.
.
Since the collector does not require pointers to be tagged, it does
not attempt to ensure that all inaccessible storage is reclaimed.
However it has typically been more successful at reclaiming unused
memory than most C programs using explicit deallocation. Unlike
manually introduced leaks, the amount of unreclaimed memory typically
stays bounded.
.
This version of the collector is thread safe, has C++ support, and uses the
defaults for everything else. Particularly, it does not work as a malloc()
replacement.
next prev parent reply other threads:[~2010-01-12 4:40 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-09 13:28 [PATCH] Declare `GC_dump' ourselves if <gc/gc.h> doesn't Thien-Thi Nguyen
2010-01-09 22:30 ` Andy Wingo
2010-01-10 2:37 ` Ken Raeburn
2010-01-11 22:09 ` Ludovic Courtès
2010-01-11 22:32 ` Ludovic Courtès
2010-01-12 4:51 ` Thien-Thi Nguyen
2010-01-12 4:40 ` Thien-Thi Nguyen [this message]
2010-01-12 14:17 ` Ludovic Courtès
2010-01-12 15:36 ` Thien-Thi Nguyen
2010-01-12 17:19 ` Ludovic Courtès
2010-01-12 18:51 ` Thien-Thi Nguyen
2010-01-12 19:33 ` Andy Wingo
2010-01-12 19:29 ` Andy Wingo
2010-01-12 22:42 ` Ludovic Courtès
2010-01-17 22:01 ` Neil Jerram
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k4vodjga.fsf@ambire.localdomain \
--to=ttn@gnuvola.org \
--cc=bug-guile@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).