Re: Mark all GUC variable as PGDLLIMPORT
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Chapman Flack <chap@anastigmatix.net>, Julien Rouhaud <rjuju123@gmail.com>, Michael Paquier <michael@paquier.xyz>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-02-15T16:06:58Z
Lists: pgsql-hackers
Hi, On 2022-02-15 08:58:05 -0500, Robert Haas wrote: > On Mon, Feb 14, 2022 at 8:53 PM Andres Freund <andres@anarazel.de> wrote: > > > An alternative rule which would dodge that particular issue would be > > > to just slap PGDLLIMPORT on every global variable in every header > > > file. That would arguably be a simpler rule, though it means even more > > > PGDLLIMPORT declarations floating around. > > > > That would have the advantage of being comparatively easy to check in an > > automated way. Might even be cheap enough to just make it part of the build. > > I wasn't able to quickly write something that was smart enough to use > as part of the build, but I wrote something dumb that I think works > well enough to use with a little bit of human intelligence alongside. > See attached. Cool. > > But it seems like it'd be a fair amount of work and cause a lot of patch > > rebasing pain? If we end up going that way, we should schedule this to happen > > just after the feature freeze, I think. > > We could do that. I'd sort of rather get it done. We still have two > weeks before the last CommitFest officially starts, and it's not as if > there won't be tons of uncommitted patches floating around after that. Breaking close to every patch 6-7 weeks before freeze doesn't seem great. Particularly because this is a mostly automatically generated patch, so I don't really see a forcing function to do this now, rather than at a more opportune moment. The more I think about it the more I'm convinced that if we want to do this, we should do it for variables and functions. > > If we consider doing this for all extern variables, we should think about > > doing this for headers *and* functions. That'd allow us to get rid of the > > fairly complicated logic to generate the .def file for the postgres binary on > > windows (src/tools/gendef.pl). And maybe also the related thing on AIX > > (src/backend/port/aix/mkldexport.sh) > > I don't know what you mean by this. We only need gendef.pl because we don't mark functions with visibility information. If we attach PGDLLIMPORT to functions and variables we can a fair bit of complexity. And I think not just for windows, but also AIX (there's a whole section in src/backend/Makefile about AIX oddity), but I'm not sure about it. > diff --git a/src/include/common/relpath.h b/src/include/common/relpath.h > index a4b5dc853b..13849a3790 100644 > --- a/src/include/common/relpath.h > +++ b/src/include/common/relpath.h > @@ -56,7 +56,7 @@ typedef enum ForkNumber > > #define FORKNAMECHARS 4 /* max chars for a fork name */ > > -extern const char *const forkNames[]; > +extern PGDLLIMPORT const char *const forkNames[]; > > extern ForkNumber forkname_to_number(const char *forkName); > extern int forkname_chars(const char *str, ForkNumber *fork); I think we might need a new form of PGDLLIMPORT to mark these correctly - I don't think they should be marked PGDLLIMPORT in frontend environment. > diff --git a/src/include/fe_utils/print.h b/src/include/fe_utils/print.h > index 836b4e29a8..5caf9e2d08 100644 > --- a/src/include/fe_utils/print.h > +++ b/src/include/fe_utils/print.h > @@ -177,10 +177,10 @@ typedef struct printQueryOpt > } printQueryOpt; > > > -extern volatile sig_atomic_t cancel_pressed; > +extern PGDLLIMPORT volatile sig_atomic_t cancel_pressed; > > -extern const printTextFormat pg_asciiformat; > -extern const printTextFormat pg_asciiformat_old; > +extern PGDLLIMPORT const printTextFormat pg_asciiformat; > +extern PGDLLIMPORT const printTextFormat pg_asciiformat_old; > extern printTextFormat pg_utf8format; /* ideally would be const, but... */ Are these right? I don't think we should make frontend stuff exported without a very clear reason. > extern void jit_reset_after_error(void); > diff --git a/src/include/jit/llvmjit.h b/src/include/jit/llvmjit.h > index 66143afccc..4541f9a2c4 100644 > --- a/src/include/jit/llvmjit.h > +++ b/src/include/jit/llvmjit.h > @@ -56,30 +56,30 @@ typedef struct LLVMJitContext > } LLVMJitContext; > > /* llvm module containing information about types */ > -extern LLVMModuleRef llvm_types_module; > +extern PGDLLIMPORT LLVMModuleRef llvm_types_module; These are wrong I think, this is a shared library. Greetings, Andres Freund
Commits
-
Remove PGDLLIMPORT marker from __pg_log_level
- 8d3341266508 15.0 landed
-
Mark a few 'bbsink' related functions / variables static.
- b5f44225b833 15.0 landed
-
Add some missing PGDLLIMPORT markings
- 5edeb574285e 15.0 landed
-
Apply PGDLLIMPORT markings broadly.
- 8ec569479fc2 15.0 landed
-
Helper script to apply PGDLLIMPORT markings.
- 80900d469091 15.0 landed
-
Simplify declaring variables exported from libpgcommon and libpgport.
- e04a8059a74c 15.0 cited