From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Hans Aberg Newsgroups: gmane.lisp.guile.user Subject: Re: How to add Guile support to a package Date: Mon, 5 Jan 2015 18:06:36 +0100 Message-ID: References: <4850D445-1C26-4463-9D95-3883943E438A@telia.com> <20150105131811.766a8813@bother.homenet> <20150105162737.1a556f5a@bother.homenet> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2064\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1420477716 11096 80.91.229.3 (5 Jan 2015 17:08:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 5 Jan 2015 17:08:36 +0000 (UTC) Cc: guile-user@gnu.org To: Chris Vine Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Mon Jan 05 18:08:28 2015 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Y8B8l-0001U3-V6 for guile-user@m.gmane.org; Mon, 05 Jan 2015 18:08:28 +0100 Original-Received: from localhost ([::1]:33179 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y8B7O-0001Ie-AP for guile-user@m.gmane.org; Mon, 05 Jan 2015 12:07:02 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36451) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y8B79-0001Dl-6D for guile-user@gnu.org; Mon, 05 Jan 2015 12:06:51 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y8B73-0007ga-4r for guile-user@gnu.org; Mon, 05 Jan 2015 12:06:47 -0500 Original-Received: from smtp-out11.han.skanova.net ([195.67.226.200]:47016) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y8B72-0007gN-Kw for guile-user@gnu.org; Mon, 05 Jan 2015 12:06:41 -0500 Original-Received: from [10.0.1.3] (217.208.169.99) by smtp-out11.han.skanova.net (8.5.142.07) (authenticated as u26619196) id 544A6E2E02089C3E; Mon, 5 Jan 2015 18:06:38 +0100 In-Reply-To: <20150105162737.1a556f5a@bother.homenet> X-Mailer: Apple Mail (2.2064) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x X-Received-From: 195.67.226.200 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:11706 Archived-At: > On 5 Jan 2015, at 17:27, Chris Vine = wrote: >=20 > On Mon, 5 Jan 2015 15:44:16 +0100 > Hans Aberg wrote: >> Guile is written entirely in C, so there is no problem. >=20 > You referred to using C++ global objects with gc on Darwin, which is = the > subject I am interested in. You did so presumably because GNU chess > is written in C++. =20 Right. > I am interested in what the specific issue with C++ > is, because I have a project to which that may be relevant. =20 C++ global objects have initializers which are run before main(), so if = they do GC allocations, GC_INIT() can=E2=80=99t be put there. > According > to the OP, GNU chess is at present conventionally allocated, so none = of > its static data (if any) is at present GC=E2=80=99ed. Right: no problem now without GC, and no problem if testing on = GNU/Linux, but if it is a multiplatform distribution, it may show up.=20 >>> In any event, I have not had problems getting guile to work as an >>> optional extension language for a C++ program with linux, from the >>> memory allocation point of view. =20 >>=20 >> On GNU/Linux, GC_INIT() is not required, so there is no issue there. >=20 > Indeed. >=20 >> If you want to pass C++ exceptions through C-code, there is a gcc >> option for that. >=20 > It enables you to pass a C++ exception through (but not catch it in) C > code (in other words, it enables stack unwinding). However, I do not > think it enables you to throw C++ exceptions out of guile dynwind > blocks and end up with a sensible result (other than program > termination), since C++ exceptions use a different mechanism from > guile's exception jumps. Leaving aside the point that relying on the > gcc -fexceptions extension for C makes code non-portable, are you > saying it actually works with dynwind blocks? I recall the option puts C++ exception stacks in into the C code, so if = all C translation units have it, throw-catch should work as normal in = the C++ code. If you want to pass it through Guile code, say if main() is C++ with a = try-catch construct, Guile must be recompiled with this option.