From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludo@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Newsgroups: gmane.lisp.guile.devel Subject: Re: Merging =?utf-8?b?4oCYYmR3LWdjLXN0YXRpYy1hbGxvY+KAmQ==?= Date: Thu, 05 Nov 2009 23:30:33 +0100 Message-ID: <87zl707gfq.fsf@gnu.org> References: <8763ay88d6.fsf@gnu.org> <87vdi6sc5m.fsf@gnu.org> <87hbtciouk.fsf@gnu.org> <87ljin8gy7.fsf@ossau.uklinux.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1257461047 11660 80.91.229.12 (5 Nov 2009 22:44:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 5 Nov 2009 22:44:07 +0000 (UTC) Cc: guile-devel@gnu.org To: Neil Jerram Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Nov 05 23:44:00 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 1N6B3e-0006z6-Gu for guile-devel@m.gmane.org; Thu, 05 Nov 2009 23:43:58 +0100 Original-Received: from localhost ([127.0.0.1]:47042 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N6B3e-0006T7-2A for guile-devel@m.gmane.org; Thu, 05 Nov 2009 17:43:58 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N6Aqn-0007Ea-LY for guile-devel@gnu.org; Thu, 05 Nov 2009 17:30:41 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N6Aqj-0007Al-Tr for guile-devel@gnu.org; Thu, 05 Nov 2009 17:30:41 -0500 Original-Received: from [199.232.76.173] (port=48664 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N6Aqj-0007Aa-Pm for guile-devel@gnu.org; Thu, 05 Nov 2009 17:30:37 -0500 Original-Received: from mail1-relais-roc.national.inria.fr ([192.134.164.82]:29644) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.60) (envelope-from ) id 1N6Aqj-000121-7Y for guile-devel@gnu.org; Thu, 05 Nov 2009 17:30:37 -0500 X-IronPort-AV: E=Sophos;i="4.44,688,1249250400"; d="scan'208";a="39611518" Original-Received: from reverse-83.fdn.fr (HELO nixey) ([80.67.176.83]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 05 Nov 2009 23:30:35 +0100 X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 15 Brumaire an 218 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEA52ECF4 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 821D 815D 902A 7EAB 5CEE D120 7FBA 3D4F EB1F 5364 X-OS: x86_64-unknown-linux-gnu In-Reply-To: <87ljin8gy7.fsf@ossau.uklinux.net> (Neil Jerram's message of "Tue, 03 Nov 2009 20:57:20 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:9635 Archived-At: Hi Neil, Neil Jerram writes: > ludo@gnu.org (Ludovic Court=C3=A8s) writes: > >> should be OK. However, I=E2=80=99m slightly concerned about MSVC= =E2=80=99s >> __declspec: does it work if it sees: >> >> __declspec(dllexport) extern SCM foo (SCM); >> extern SCM foo (SCM); > > I don't know for sure, but I know I've seen "function redeclared with > different linkage" warnings in the past, and this could well be one of > the situations that generates such warnings. Right. > But what about using SCM_API instead of extern? Wouldn't that always > generate the right code? (At least for building guile itself.) You=E2=80=99re right. It=E2=80=99ll work for building Guile itself, but mo= st probably 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 =E2=80=98SCM_API=E2=80=99-like macro for that purpose. Well, we could just disable =E2=80=98SCM_SUPPORT_STATIC_ALLOCATION=E2=80=99= altogether for =E2=80=9CWoe32=E2=80=9D builds. What do you think? In the meantime, I=E2=80=99ve pushed this: http://git.savannah.gnu.org/cgit/guile.git/commit/?id=3Df4767979987530bb9d8= 8dde6ebe61cdac6f756b9 . > I guess it depends if the primitives in question are designed to be used > only from Scheme, or also from other C files. If they're only for > Scheme, it's a nice feature that SCM_DEFINE does everything needed and > the developer doesn't need a matching prototype. If they're for other C > files, the missing prototype warning could be helpful. Yes, although ideally functions only for Scheme would be either static or with internal linkage, which calls for an =E2=80=98SCM_DEFINE_LOCAL=E2= =80=99 macro or similar. > Then again, the developer will get some kind of warning anyway when > trying to use the function from another file. So I think the balance is > in favour of SCM_DEFINE including the prototype. Yes. Thanks, Ludo=E2=80=99.