unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: Neil Jerram <neil@ossau.uklinux.net>
Cc: guile-devel@gnu.org
Subject: Re: Merging ‘bdw-gc-static-alloc’
Date: Thu, 05 Nov 2009 23:30:33 +0100	[thread overview]
Message-ID: <87zl707gfq.fsf@gnu.org> (raw)
In-Reply-To: <87ljin8gy7.fsf@ossau.uklinux.net> (Neil Jerram's message of "Tue, 03 Nov 2009 20:57:20 +0000")

Hi Neil,

Neil Jerram <neil@ossau.uklinux.net> writes:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>>      should be OK.  However, I’m slightly concerned about MSVC’s
>>      __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’re right.  It’ll work for building Guile itself, but most probably
fail when building external libraries, because it will have
SCM_API==dllimport 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 ‘SCM_API’-like macro for that purpose.

Well, we could just disable ‘SCM_SUPPORT_STATIC_ALLOCATION’ altogether
for “Woe32” builds.

What do you think?

In the meantime, I’ve pushed this:
http://git.savannah.gnu.org/cgit/guile.git/commit/?id=f4767979987530bb9d88dde6ebe61cdac6f756b9 .

> 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 ‘SCM_DEFINE_LOCAL’ 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’.




  reply	other threads:[~2009-11-05 22:30 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-02  9:15 Merging ‘bdw-gc-static-alloc’ Ludovic Courtès
2009-10-02 16:26 ` Andy Wingo
2009-10-23  9:16   ` Ludovic Courtès
2009-10-23 12:57     ` Andy Wingo
2009-11-02 21:44       ` Ludovic Courtès
2009-11-03 20:57         ` (no subject) Neil Jerram
2009-11-05 22:30           ` Ludovic Courtès [this message]
2009-11-08 22:21             ` Neil Jerram

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zl707gfq.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=guile-devel@gnu.org \
    --cc=neil@ossau.uklinux.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).