Hi Neil, Neil Jerram <n...@ossau.uklinux.net> writes:
> l...@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’.
