BUG #10436: Can't compile 9.4 with this mingw64-w32 gcc 4.8.1, 4.8.2, 4.8.3
On 2014-05-24 14:21:32 -0400, Tom Lane wrote:
Andres Freund <andres@2ndquadrant.com> writes:
On 2014-05-24 12:35:08 -0400, Tom Lane wrote:
If it's not getting through configure, the only plausible explanation
seems to be that something in autoconf 2.69 broke it.It could also be the linking changes made while trying to make missing
PGDLLIMPORTs more visible.None of those changes touched the configure script, though.
Right.
Regina, can you post config.log from 9.3 and 9.4?
There's a couple of bugreports referencing _set_invalid_parameter_handle
and mingw. With confusingly different explanations...
Greetings,
Andres Freund
Okay will do in a bit after I rebuild both.
FWIW: I'm not convinced its autoconf 2.69 at fault. I'm running autoconf
2.69
And as an experiment
In the 9.3.4 configure.in source code -- I changed the autoconf requirement
in configure.in to 2.69 and rebuilt the configure script (making sure I
deleted the old one before trying to rebuild)
It still configures fine with 9.3.4 (just tested with mingw32 gcc 4.9.0 and
same issue with that)
rebuilding the configure script for 9.4.0 still fails.
Sorry if this doesn't follow the thread -- for some reason I didn't get any
of these emails you sent.
Thanks again for the help,
Regina
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Regina, can you post config.log from 9.3 and 9.4?
Attached are the config.logs from both trying to configure with mingw64-w32
gcc 4.8.1
Thanks,
Regina
Import Notes
Reply to msg id not found: | Resolved by subject fallback
Regina, can you post config.log from 9.3 and 9.4?
Sorry was too big so got bounced back. Here are the links to the config
logs
http://www.postgresonline.com/tmp/config94_mingw64w32gcc481.txt
http://www.postgresonline.com/tmp/config934_mingw64w32gcc481.txt
Thanks,
Regina
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Andreas,
Thanks for the suggestion of looking at the logs
Figured out the problem I think.
In looking at the logs:
http://www.postgresonline.com/tmp/config94_mingw64w32gcc481.txt
http://www.postgresonline.com/tmp/config934_mingw64w32gcc481.txt
I noticed the difference was the --disable-auto-import in 9.4.
So in src\template\win32 file
I changed:
LDFLAGS="-Wl,--allow-multiple-definition -Wl,--disable-auto-import"
Back to the old:
LDFLAGS="-Wl,--allow-multiple-definition"
And that fixed the configure issue with mingw64-w32 4.8.1+ and it seems to
have compiled fine too and passed all regression tests.
Better yet -- this new one doesn't have that annoying extra import of
InterlockedCompareExchange@
That I complained about here:
/messages/by-id/286FBE756DA043A881A289C539AD2ED3@O
That broke my PostGIS 32-bit builds
And extensions built with it seem to be loadable in my EDB install again.
Have to do more tests, but looks good so far.
Still puzzling why my gcc 4.8.0 compiled at all and still had that annoying
dependency even when I also changed that file suspecting that was an issue
before. Perhaps the 4.8.0 has a bug and is half heartedly paying attention
to some things and not others.
Any thoughts on what to do about that win32 thing. Wasn't quite clear why
it was introduced in the first place
Thanks,
Regina
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Import Notes
Reply to msg id not found: | Resolved by subject fallback
"Paragon Corporation" <lr@pcorp.us> writes:
I changed:
LDFLAGS="-Wl,--allow-multiple-definition -Wl,--disable-auto-import"
Back to the old:
LDFLAGS="-Wl,--allow-multiple-definition"
And that fixed the configure issue with mingw64-w32 4.8.1+ and it seems to
have compiled fine too and passed all regression tests.
Hm. It would be pretty disappointing to have to do that, because it would
be admitting complete defeat in trying to get the various Windows build
toolchains to have consistent link behavior. We put enough sweat into
that goal last winter that I don't really want to just walk away.
OTOH, it seems clear at this point that the Mingw people are not testing
their product with --disable-auto-import, so expecting it to work with
that switch may be foolish.
I poked around and found this bug report:
http://sourceforge.net/p/mingw/bugs/2020/
which seems related but it's not clear that it's exactly the same thing.
That's marked as fixed a few months ago, but I can't tell if the fix
has been shipped yet.
Thoughts? Should we just take the path of least resistance, or should
we look harder for a better solution?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Hi,
On 2014-05-25 13:42:48 -0400, Tom Lane wrote:
"Paragon Corporation" <lr@pcorp.us> writes:
I changed:
LDFLAGS="-Wl,--allow-multiple-definition -Wl,--disable-auto-import"
Back to the old:
LDFLAGS="-Wl,--allow-multiple-definition"
And that fixed the configure issue with mingw64-w32 4.8.1+ and it seems to
have compiled fine too and passed all regression tests.Hm. It would be pretty disappointing to have to do that, because it would
be admitting complete defeat in trying to get the various Windows build
toolchains to have consistent link behavior. We put enough sweat into
that goal last winter that I don't really want to just walk away.
Yea. And it did catch a couple of bugs...
OTOH, it seems clear at this point that the Mingw people are not testing
their product with --disable-auto-import, so expecting it to work with
that switch may be foolish.I poked around and found this bug report:
http://sourceforge.net/p/mingw/bugs/2020/
which seems related but it's not clear that it's exactly the same thing.
That's marked as fixed a few months ago, but I can't tell if the fix
has been shipped yet.Thoughts? Should we just take the path of least resistance, or should
we look harder for a better solution?
How about removing it for 9.4 only once that has branched? That'd make
less users be affected while we hope for mingw to fix that?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Andres Freund <andres@2ndquadrant.com> writes:
On 2014-05-25 13:42:48 -0400, Tom Lane wrote:
Hm. It would be pretty disappointing to have to do that, because it would
be admitting complete defeat in trying to get the various Windows build
toolchains to have consistent link behavior. We put enough sweat into
that goal last winter that I don't really want to just walk away.
Yea. And it did catch a couple of bugs...
How about removing it for 9.4 only once that has branched? That'd make
less users be affected while we hope for mingw to fix that?
I fear that'd just mean we deal with it again next year :-(.
It occurs to me that we could make configure probe for whether
--disable-auto-import breaks simple test programs on Mingw. That would
catch this particular manifestation with _set_invalid_parameter_handle,
although there would still be opportunities to fail later perhaps.
Not sure if it's worth the trouble.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs