win32 pg_autovacuum make error

I have just started seeing the following on win32:

make[1]: Entering directory
`/home/pgrunner/pgbuildfarm/root/HEAD/pgsql.blurfl/contrib/pg_a
utovacuum'
gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes
-Wmissing-declarations pg_autovacuum.o
-L../../src/interfaces/libpq -lpq
-L../../src/port -lpgport -lwsock32 -lm -lws2_32 -o pg_autovacuum
pg_autovacuum.o(.text+0xae9):pg_autovacuum.c: undefined reference to
`DLNewElem'
pg_autovacuum.o(.text+0xaf8):pg_autovacuum.c: undefined reference to
`DLAddTail'
pg_autovacuum.o(.text+0xc2d):pg_autovacuum.c: undefined reference to
`DLRemove'
pg_autovacuum.o(.text+0x101a):pg_autovacuum.c: undefined reference to
`DLNewList'
pg_autovacuum.o(.text+0x1036):pg_autovacuum.c: undefined reference to
`DLNewElem'
pg_autovacuum.o(.text+0x103f):pg_autovacuum.c: undefined reference to
`DLAddHead'
pg_autovacuum.o(.text+0x11a2):pg_autovacuum.c: undefined reference to
`DLNewList'
pg_autovacuum.o(.text+0x14d3):pg_autovacuum.c: undefined reference to
`DLNewElem'
pg_autovacuum.o(.text+0x14df):pg_autovacuum.c: undefined reference to
`DLAddTail'
pg_autovacuum.o(.text+0x16ad):pg_autovacuum.c: undefined reference to
`DLRemove'
pg_autovacuum.o(.text+0xc57):pg_autovacuum.c: undefined reference to
`DLFreeElem'
pg_autovacuum.o(.text+0xcbe):pg_autovacuum.c: undefined reference to
`DLFreeList'
pg_autovacuum.o(.text+0x16f5):pg_autovacuum.c: undefined reference to
`DLFreeElem'
pg_autovacuum.o(.text+0x17ae):pg_autovacuum.c: undefined reference to
`DLFreeList'
make[1]: *** [pg_autovacuum] Error 1
make[1]: Leaving directory
`/home/pgrunner/pgbuildfarm/root/HEAD/pgsql.blurfl/contrib/pg_a
utovacuum'
make: *** [all] Error 2

Not sure what has changed ....

I don't have a build env around ATM to test, but my guess would be the
new libpq linking. These functions are probably imported from libpq, and
therefor must be added to the .def file (or rather the .txt file that
generates the .def file that Tom just committed if you have the very
latest-and-greates cvs ver) for libpq.dll.

//Magnus

"Magnus Hagander" <mha@sollentuna.net> writes:

I don't have a build env around ATM to test, but my guess would be the
new libpq linking. These functions are probably imported from libpq, and
therefor must be added to the .def file (or rather the .txt file that
generates the .def file that Tom just committed if you have the very
latest-and-greates cvs ver) for libpq.dll.

I have a better idea: make pg_autovacuum not use DLLists. That code
is slated for eventual removal from libpq anyway (if not complete
destruction). Had I been aware that autovacuum was using it I would
have objected ...

regards, tom lane

Tom Lane wrote:

"Magnus Hagander" <mha@sollentuna.net> writes:

I don't have a build env around ATM to test, but my guess would be the
new libpq linking. These functions are probably imported from libpq, and
therefor must be added to the .def file (or rather the .txt file that
generates the .def file that Tom just committed if you have the very
latest-and-greates cvs ver) for libpq.dll.

I have a better idea: make pg_autovacuum not use DLLists. That code
is slated for eventual removal from libpq anyway (if not complete
destruction). Had I been aware that autovacuum was using it I would
have objected ...

Ok, what do you recommend I replace the DLLists with?

"Matthew T. O'Connor" <matthew@zeut.net> writes:

Tom Lane wrote:

I have a better idea: make pg_autovacuum not use DLLists. That code
is slated for eventual removal from libpq anyway (if not complete
destruction). Had I been aware that autovacuum was using it I would
have objected ...

Ok, what do you recommend I replace the DLLists with?

I reconsidered --- seeing that autovacuum will eventually be server-side
code, it's not unreasonable for it to use DLList. It's just that it
shouldn't rely on libpq to provide DLList. I've committed a fix
already.

I think I'm going to go ahead and remove dllist.c from libpq, though.
The library will be smaller, faster, and more robust without it, and
8.0 seems like a good time to break anyone who is foolish enough to
be depending on it being in libpq ...

regards, tom lane