From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.devel Subject: (no subject) Date: Sun, 08 Nov 2009 22:21:54 +0000 Message-ID: <87my2wy7wd.fsf@ossau.uklinux.net> References: <8763ay88d6.fsf@gnu.org> <87vdi6sc5m.fsf@gnu.org> <87hbtciouk.fsf@gnu.org> <87ljin8gy7.fsf@ossau.uklinux.net> <87zl707gfq.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1261399937 28335 80.91.229.12 (21 Dec 2009 12:52:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Dec 2009 12:52:17 +0000 (UTC) Cc: guile-devel@gnu.org To: ludo@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Dec 21 13:52:10 2009 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NMhk3-00025p-N6 for guile-devel@m.gmane.org; Mon, 21 Dec 2009 13:52:04 +0100 Original-Received: from localhost ([127.0.0.1]:40888 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NMhk3-00070D-Mq for guile-devel@m.gmane.org; Mon, 21 Dec 2009 07:52:03 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N7G9A-0002qj-Pb for guile-devel@gnu.org; Sun, 08 Nov 2009 17:22:08 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N7G95-0002od-N4 for guile-devel@gnu.org; Sun, 08 Nov 2009 17:22:07 -0500 Original-Received: from [199.232.76.173] (port=42884 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N7G95-0002oV-E2 for guile-devel@gnu.org; Sun, 08 Nov 2009 17:22:03 -0500 Original-Received: from mail3.uklinux.net ([80.84.72.33]:53263) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N7G93-00081O-1U; Sun, 08 Nov 2009 17:22:01 -0500 Original-Received: from arudy (host86-145-153-90.range86-145.btcentralplus.com [86.145.153.90]) by mail3.uklinux.net (Postfix) with ESMTP id 3C8441F6778; Sun, 8 Nov 2009 22:22:00 +0000 (GMT) Original-Received: from arudy (arudy [127.0.0.1]) by arudy (Postfix) with ESMTP id C2AE838023; Sun, 8 Nov 2009 22:21:54 +0000 (GMT) In-Reply-To: <87zl707gfq.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?= =?iso-8859-1?Q?=22's?= message of "Thu, 05 Nov 2009 23:30:33 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.4-2.6 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:9782 Archived-At: ludo@gnu.org (Ludovic Court=A8=A8s) writes: > Hi Neil, > > Neil Jerram writes: > >> But what about using SCM_API instead of extern? Wouldn't that always >> generate the right code? (At least for building guile itself.) > > You=A1=AFre right. It=A1=AFll work for building Guile itself, but most p= robably > fail when building external libraries, because it will have > SCM_API=3D=3Ddllimport whereas the symbols of the lib being built want > dllexport. > > I have no idea how to fix this since third party libraries typically > have their own =A1=AESCM_API=A1=AF-like macro for that purpose. > > Well, we could just disable =A1=AESCM_SUPPORT_STATIC_ALLOCATION=A1=AF alt= ogether > for =A1=B0Woe32=A1=B1 builds. > > What do you think? We're talking here about macros that are always used in .c files, aren't we? (As opposed to headers that an application using the library would include.) So on Woe32, we actually always want dllexport. i.e. if the header has SCM_API SCM scm_frobate (SCM arg); and the SCM_DEFINE in .c expands to something that includes __declspec(dllexport) SCM scm_frobate (SCM arg); that should be good, because SCM_API will be __declspec(dllexport) when building the library. In the Scheme-only case, that does mean exporting something that doesn't need exporting - but either we can just live with that, or later add your suggestion of SCM_DEFINE_LOCAL. Regards, Neil