Re: Mark all GUC variable as PGDLLIMPORT - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Mark all GUC variable as PGDLLIMPORT
Date
Msg-id CABUevEzBLnYs5s4nm-nMznS9+KFF+oQvhJ2Cw9=aUVOm26a01A@mail.gmail.com
Whole thread Raw
In response to Re: Mark all GUC variable as PGDLLIMPORT  (Julien Rouhaud <rjuju123@gmail.com>)
Responses Re: Mark all GUC variable as PGDLLIMPORT
Re: Mark all GUC variable as PGDLLIMPORT
List pgsql-hackers
On Thu, Aug 26, 2021 at 3:38 AM Julien Rouhaud <rjuju123@gmail.com> wrote:
>
> On Thu, Aug 26, 2021 at 1:51 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> >
> > On 2021-Aug-25, Magnus Hagander wrote:
> >
> > > The thing we need the PGDLLIMPORT definition for is to *import* them
> > > on the other end?
> >
> > Oh ... so modules that are willing to cheat can include their own
> > declarations of the variables they need, and mark them __declspec
> > (dllimport)?
>
> I just tried and msvc doesn't like it.  It errors out with a C2370
> error "redefinition; different storage class".  According to
> https://docs.microsoft.com/en-us/cpp/error-messages/compiler-errors-1/compiler-error-c2370
> changing __declspec() on the other side is not possible.

Yeah, but that does move the problem to the other side doesn't it? So
if you (as a pure test of course) were to remove the variable
completely from the included header and just declare it manually with
PGDLLSPEC in your file, it should work?

Ugly as it is, I wonder if there's a chance we could just process all
the headers at install times and inject the PGDLLIMPORT. We know which
symvols it is on account of what we're getting in the DEF file.

Not saying that's not a very ugly solution, but it might work?

-- 
 Magnus Hagander
 Me: https://www.hagander.net/
 Work: https://www.redpill-linpro.com/



pgsql-hackers by date:

Previous
From: Mark Dilger
Date:
Subject: Re: verify_heapam for sequences?
Next
From: Robert Haas
Date:
Subject: Re: Mark all GUC variable as PGDLLIMPORT