From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Andreas Rottmann Newsgroups: gmane.lisp.guile.devel Subject: Re: What can I do to help? (conclusions) Date: 10 Oct 2002 10:34:16 +0200 Sender: guile-devel-admin@gnu.org Message-ID: <87elayk7zr.fsf@alice.rotty.yi.org> References: <20021004132911.GD20754@www> <87k7ky5ggq.fsf@alice.rotty.yi.org> <20021006170804.GA7206@www> <87ofa71nfh.fsf@alice.rotty.yi.org> <87hefzjgng.fsf@zagadka.ping.de> <87hefyyjxb.fsf@raven.i.defaultvalue.org> <874rbwsxih.fsf@alice.rotty.yi.org> <871y704ryi.fsf@raven.i.defaultvalue.org> <87vg4cwszl.fsf@alice.rotty.yi.org> <87bs62eufb.fsf@raven.i.defaultvalue.org> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1034239271 6025 127.0.0.1 (10 Oct 2002 08:41:11 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 10 Oct 2002 08:41:11 +0000 (UTC) Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17zYsY-0001Z1-00 for ; Thu, 10 Oct 2002 10:41:10 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17zYmi-0008NY-00; Thu, 10 Oct 2002 04:35:08 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17zYm7-0007FQ-00 for guile-devel@gnu.org; Thu, 10 Oct 2002 04:34:31 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17zYlv-0006gw-00 for guile-devel@gnu.org; Thu, 10 Oct 2002 04:34:26 -0400 Original-Received: from sproxy.gmx.net ([213.165.64.20] helo=mail.gmx.net) by monty-python.gnu.org with smtp (Exim 4.10) id 17zYlu-0006be-00 for guile-devel@gnu.org; Thu, 10 Oct 2002 04:34:18 -0400 Original-Received: (qmail 27699 invoked by uid 0); 10 Oct 2002 08:34:16 -0000 Original-Received: from m188p019.adsl.highway.telekom.at (HELO alice.rhinosaur.lan) (62.47.191.115) by mail.gmx.net (mp016-rz3) with SMTP; 10 Oct 2002 08:34:16 -0000 Original-Received: from andy by alice.rhinosaur.lan with local (Exim 3.36 #1 (Debian)) id 17zYls-00082l-00 for ; Thu, 10 Oct 2002 10:34:16 +0200 Original-To: guile-devel@gnu.org In-Reply-To: <87bs62eufb.fsf@raven.i.defaultvalue.org> Original-Lines: 48 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:1509 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1509 Rob Browning writes: > Andreas Rottmann writes: > > > Yes, that's a clear disadvantage. However, in what environments does > > that requirement exist? If you have a configure option, you can decide > > both ways. There could even be a debian package 'guile' (with a C > > linked executable) and a 'guile-c++' one, linked with g++, replacing > > 'guile' (or the other way round with a c++-linked guile as > > default). Then C++ plugins could depend on guile-c++. However, I get > > too much into debian pkg management now, I guess *waves to Rob*. > > I think this might be possible, but if it meant that not only guile, > but every lib and app that was linked against guile would have to be > packaged two ways, then it's probably not feasible. > It's just about the main program (executable). Libs and thus modules won't be affected. Apps can decide wether they want to support guile modules written in C++ (and be linked appropriatly). > > It is not possible to load this plugins with some C++ constructs > > (e.g. exceptions, don't know the full list), since guile > > crashes. > > Are we talking about guile functions calling c++ functions, or c++ > functions calling guile functions here, and are we talking about the > c++ code being accessed via guile loaded (dynamic-link)ed shared > libraries or via direct linking/loadinga? > c++ code being loaded into guile dynamically (i.e. shared libs). > Also is there a description of the problem available anywhere? i.e. in > the case of exceptions where c code is calling c++ code, is it a > problem if the c++ code throws an exception at all, or only if it > tries to throw one up to the c level. If the latter, then can the c++ > code just be required to have a catch-all "catch" at the top-level in > all of the functions guile will be calling? > Sorry, there is no definite explanation (at least i didn't find one). However, I'm going to investigate this more. It seems it may have to do with most C++ shared libs ending up being linked by gcc instead of g++ (due to a libtool bug). Regards, Andy -- Andreas Rottmann | Dru@ICQ | 118634484@ICQ | a.rottmann@gmx.at http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel