From 8518583cdb10340bab3464121629a1a9ec387afa Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Wed, 12 Oct 2016 12:45:50 -0400 Subject: [PATCH] Provide DLLEXPORT markers for C functions via PG_FUNCTION_INFO_V1 macro. This isn't really necessary for our own code, because we use a .DEF file in MSVC builds (see gendef.pl), or --export-all-symbols in MinGW and Cygwin builds, to ensure that all global symbols in loadable modules will be exported on Windows. However, third-party authors might use different build processes that need this marker, and it's harmless enough for our own builds. To some extent, this is an oversight in commit e7128e8db, so back-patch to 9.4 where that was added. Laurenz Albe Discussion: --- src/include/fmgr.h | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/src/include/fmgr.h b/src/include/fmgr.h index 0491e2e1d1..18c224ecfa 100644 --- a/src/include/fmgr.h +++ b/src/include/fmgr.h @@ -344,11 +344,17 @@ typedef const Pg_finfo_record *(*PGFInfoFunction) (void); /* * Macro to build an info function associated with the given function name. - * Win32 loadable functions usually link with 'dlltool --export-all', but it - * doesn't hurt to add PGDLLIMPORT in case they don't. + * + * As a convenience, also provide an "extern" declaration for the given + * function name, so that writers of C functions need not write that too. + * + * On Windows, the function and info function must be exported. Our normal + * build processes take care of that via .DEF files or --export-all-symbols. + * We add PGDLLEXPORT nonetheless so that C functions built with a + * different build process are guaranteed to be exported. */ #define PG_FUNCTION_INFO_V1(funcname) \ -Datum funcname(PG_FUNCTION_ARGS); \ +extern PGDLLEXPORT Datum funcname(PG_FUNCTION_ARGS); \ extern PGDLLEXPORT const Pg_finfo_record * CppConcat(pg_finfo_,funcname)(void); \ const Pg_finfo_record * \ CppConcat(pg_finfo_,funcname) (void) \