Re: build error in initdb on win32

>> The underlying problem is still there, though. initdb is pulling all
>> these symbols in from libpq.dll, which is clearly the wrong
>place to get
>> them... Or are they supposed to be available? If so, they should be
>> added to the official API, no?
>
>"Used by our own code" does not equate to "should be part of the
>official API".
>
>> (The problem occured when I tried to fix the problem "fix
>MinGW libpq to
>> export only required symbols". I have a patch that fixes
>this problem,
>> but causes these others instead)
>
>You'd better back off a little on what you're removing. Or forget the
>whole thing; I don't really agree that the above is a bug. libpq has
>always had rather more visible symbols than are in the official API,
>and there are probably people using some of them.

The problem today is that our officially supported build methods
generate two different libpq.dll's that are incompatible with each other
(to the point of causing a SEGV or other such nastyness in a program
using them). I certainly consider that a bug.

How about this. If the required functions (which aren't *too* many) are
added to libpqdll.def, everything returns to working order. It does add
a slight maintainability issue - whenever a new binary is using a
function in libpq never before exported, it has to be added to
libpqdll.def. But since it's never re-ordered, it does not break
backwards compatibility.
Would that be acceptable?

The other option would be to add every single possible output to the
MSVC DLL file. There is no way to do that fromt he MSVC build system
that I can find, so it would require manual updating of that file
whenever any function that ultimatly gets exported from libpq (direct or
indirect) is added, which I beleive would be much more work to maintain.

(Well, the third option is of course to accept that we have to
incompatible libraries witht he same name, but I don't consider that a
"real" option)

//Magnus