Re: Using XLogFileNameP in critical section
От | Andrew Dunstan |
---|---|
Тема | Re: Using XLogFileNameP in critical section |
Дата | |
Msg-id | 41357459-90ec-408a-cb65-9d284eeb7ab0@dunslane.net обсуждение исходный текст |
Ответ на | Re: Using XLogFileNameP in critical section (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 12/3/19 11:24 AM, Tom Lane wrote: > I wrote: >> Also, buildfarm member drongo is not happy: >> postgres.def : error LNK2001: unresolved external symbol XLogFileNameP [C:\prog\bf\root\HEAD\pgsql.build\postgres.vcxproj] >> Release/postgres/postgres.lib : fatal error LNK1120: 1 unresolved externals [C:\prog\bf\root\HEAD\pgsql.build\postgres.vcxproj] >> I'm guessing you missed a reference someplace. > Hm ... grep swears up and down that there is no remaining instance > of the string "XLogFileNameP" anywhere in the tree. So this doesn't > seem to be the fault of 9989d37d1 per se. What my eye now falls on > is this, a bit further up in the build log [1]: > > ... > PreLinkEvent: > Generate DEF file > perl src\tools\msvc\gendef.pl Release\postgres x64 > :VCEnd > Not re-generating POSTGRES.DEF, file already exists. > Link: > ... > > So it seems that the problem might really be a faulty rule in our > MSVC build script about when postgres.def needs to be regenerated? > Or else it's some weird caching problem on drongo --- the lack of > complaints from other Windows critters might point the finger > that way. > > regards, tom lane > > [1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=drongo&dt=2019-12-03%2007%3A30%3A01 > this was pilot error on my part. Should be fixed now. cheers andrew
В списке pgsql-hackers по дате отправления: