On 2014-02-16 13:25:58 -0500, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On 2014-02-16 12:57:46 -0500, Tom Lane wrote:
> >> I'm starting to get the feeling that we're going to have to admit
> >> defeat and not try to use --disable-auto-import on cygwin builds.
> >> That platform is evidently not capable of supporting it.
>
> > Agreed. It's probably doable if somebody actually using cygwin
> > themselves would invest a day or two and work on upstreaming the
> > changes, but it looks painful to do indirectly.
>
> Yeah, and I doubt that anybody in the Cygwin project is going to see
> the point of maintaining such patches anyway. As Marco said, their
> idea is to provide a Unix-ish platform as best they can, not adopt all
> the worst features of Windows. I kinda wonder why they have declspec's
> on the getopt variables at all.
When searching for others having issues, I discovered several other
projects also disabling auto-import, so it's not just us. And, afaics,
it's mostly upstream bugs, e.g. libxml's header just misses an "extern"
in one of the cygwin specific defines.
I don't think we've actually found bugs in cygwin yet. We'd overridden
the provided declspec for getopt et al, that's why it failed, and we're
failing to link to several of the libraries we're using. I think the
only reason the latter isn't breaking our neck is that they are
indirectly included and the auto-import code is saving our neck.
That said, even if the upstream projects were fixed, we probably
wouldn't want to enable this unconditionally for a fair while. And I am
surely not volunteering to do the necessary work, and I somehow think
neither are you...
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
