bug-guile
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Declare `GC_dump' ourselves if <gc/gc.h> doesn't.


From: Thien-Thi Nguyen
Subject: Re: [PATCH] Declare `GC_dump' ourselves if <gc/gc.h> doesn't.
Date: Tue, 12 Jan 2010 05:40:37 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.91 (gnu/linux)

() address@hidden (Ludovic Courtès)
() Mon, 11 Jan 2010 23:09:15 +0100

   Andy Wingo <address@hidden> writes:

   > On Sat 09 Jan 2010 14:28, Thien-Thi Nguyen <address@hidden> 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 <address@hidden>
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.







reply via email to

[Prev in Thread] Current Thread [Next in Thread]