guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

(no subject)


From: Neil Jerram
Subject: (no subject)
Date: Sun, 08 Nov 2009 22:22:09 -0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

address@hidden (Ludovic Courtès) writes:

> Hi Neil,
>
> Neil Jerram <address@hidden> 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’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?

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]