Fujii Masao wrote: > On Wed, Jan 13, 2010 at 3:37 AM, Magnus Hagander <mag...@hagander.net> wrote: >>> This change which moves walreceiver process into a dynamically loaded >>> module caused the following compile error on my MinGW environment. >> That sounds strange - it should pick those up from the -lpostgres. Any >> chance you have an old postgres binary around from a non-syncrep build >> or something? > > No, there is no old postgres binary. > >> Do you have an environment to try to build it under msvc? > > No, unfortunately. > >> in my >> experience, that gives you easier-to-understand error messages in a >> lot of cases like this - it removets the mingw black magic. > > OK. I'll try to build it under msvc. > > But since there seems to be a long way to go before doing that, > I would appreciate if someone could give me some advice.
It looks like dawn_bat is experiencing the same problem. I don't think we want to sprinkle all those variables with PGDLLIMPORT, and it didn't fix the problem for you earlier anyway. Is there some other way to fix this? Do people still use MinGW for any real work? Could we just drop walreceiver support from MinGW builds? Or maybe we should consider splitting walreceiver into two parts after all. Only the bare minimum that needs to access libpq would go into the shared object, and the rest would be linked with the backend as usual. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
