Re: Mark all GUC variable as PGDLLIMPORT

On Tue, Feb 15, 2022 at 11:07 PM Andres Freund <andres(at)anarazel(dot)de> wrote:

> > 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.

That has been taken care of already, IIUC:

commit e04a8059a74c125a8af94acdcb7b15b92188470a
Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Date: Mon Nov 29 11:00:00 2021 -0500

Simplify declaring variables exported from libpgcommon and libpgport.

This reverts commits c2d1eea9e and 11b500072, as well as similar hacks
elsewhere, in favor of setting up the PGDLLIMPORT macro so that it can
just be used unconditionally. That can work because in frontend code,
we need no marking in either the defining or consuming files for a
variable exported from these libraries; and frontend code has no need
to access variables exported from the core backend, either.

--
John Naylor
EDB: http://www.enterprisedb.com