On Fri, Aug 27, 2021 at 3:42 AM Magnus Hagander <mag...@hagander.net> wrote: > > 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?
It's apparently not enough. I tried with autovacuum_max_workers GUC, and it still errors out. If I add a PGDLLIMPORT, there's a link error when trying to access the variable: error LNK2019: unresolved external symbol __imp_autovacuum_max_workers referenced in function... I think that it means that msvc tries to link that to a DLL while it's expected to be in postgres.lib as the __imp_ prefix is added in that case. If I use PGDLLEXPORT I simply get: error LNK2001: unresolved external symbol aytovacuum_max_workers
