Re: Mark all GUC variable as PGDLLIMPORT
От | Julien Rouhaud |
---|---|
Тема | Re: Mark all GUC variable as PGDLLIMPORT |
Дата | |
Msg-id | CAOBaU_b3CNnU3skSmoS91DJ3xk_VgUFJtssKLurRTo5WY1iOJg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Mark all GUC variable as PGDLLIMPORT (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: Mark all GUC variable as PGDLLIMPORT
|
Список | pgsql-hackers |
On Fri, Aug 27, 2021 at 3:42 AM Magnus Hagander <magnus@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
В списке pgsql-hackers по дате отправления: