On 13/02/2014 00:17, Craig Ringer wrote:
On 02/13/2014 12:39 AM, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-02-12 11:26:56 -0500, Tom Lane wrote:
Hm. So if we're giving up on the idea of ever getting rid of PGDLLIMPORT,
we ought to actually remove that, so that
(2014/02/13 8:21), Tom Lane wrote:
Craig Ringer cr...@2ndquadrant.com writes:
On 02/12/2014 02:31 PM, Inoue, Hiroshi wrote:
Maybe this is one of the few use cases of dlltool.
Because python doesn't ship with its MINGW import library, the
Makefile uses dlltool to generate an import library
On 02/13/2014 02:42 PM, Marco Atzeri wrote:
My personal experience is that a UNIX-vanilla source build 99% right
on recent cygwin.
Yeah, I freely admit my experience with _recent_ cygwin is not abundant.
Things may well have improved.
--
Craig Ringer
On Tue, Feb 11, 2014 at 11:01 AM, Craig Ringer cr...@2ndquadrant.com wrote:
On 02/11/2014 01:28 PM, Tom Lane wrote:
If there are no objections, I'll push this patch into HEAD tomorrow,
along with the upthread patches from Craig Ringer and Marco Atzeri.
We might as well see if this stuff is
Marco Atzeri marco.atz...@gmail.com writes:
On 09/02/2014 14:10, Andrew Dunstan wrote:
On 02/09/2014 01:12 AM, Marco Atzeri wrote:
we should have get rid of dlltool on cygwin.
At least it is not used on my build
The send in a patch. The patch you sent in previously did not totally
remove it
Hiroshi Inoue in...@tpf.co.jp writes:
(2014/02/09 8:06), Andrew Dunstan wrote:
Yeah. Incidentally, we didn't quite get rid of dlltool for Cygwin. We
did get rid of dllwrap. But I agree this is worth trying for Mingw.
I tried MINGW port with the attached change and successfully built
src and
Craig Ringer cr...@2ndquadrant.com writes:
For MSVC, here's a patch that makes gendef.pl emit DATA annotations for
global var exports.
Committed.
Also attached is a patch to make vcregress.pl produce a better error
message when there's no build output, instead of just reporting that
.. is
On 11/02/2014 18:15, Tom Lane wrote:
Marco Atzeri marco.atz...@gmail.com writes:
On 09/02/2014 14:10, Andrew Dunstan wrote:
On 02/09/2014 01:12 AM, Marco Atzeri wrote:
we should have get rid of dlltool on cygwin.
At least it is not used on my build
The send in a patch. The patch you sent
Craig Ringer cr...@2ndquadrant.com writes:
On 02/11/2014 01:28 PM, Tom Lane wrote:
If there are no objections, I'll push this patch into HEAD tomorrow,
along with the upthread patches from Craig Ringer and Marco Atzeri.
We might as well see if this stuff is going to work ...
I'd love to test
I wrote:
Hiroshi Inoue in...@tpf.co.jp writes:
I tried MINGW port with the attached change and successfully built
src and contrib and all pararell regression tests were OK.
I cleaned this up a bit (the if-nesting in Makefile.shlib was making
my head hurt, not to mention that it left a bunch
On 02/12/2014 07:22 AM, Tom Lane wrote:
So the early returns from currawong are interesting:
d:\bf\root\HEAD\pgsql.920\pgsql.sln (default target) (1) -
(contrib\pg_buffercache target) -
pg_buffercache_pages.obj : error LNK2001: unresolved external symbol
_MainLWLockArray
On 02/11/2014 11:04 PM, Amit Kapila wrote:
On Tue, Feb 11, 2014 at 11:01 AM, Craig Ringer cr...@2ndquadrant.com wrote:
On 02/11/2014 01:28 PM, Tom Lane wrote:
If there are no objections, I'll push this patch into HEAD tomorrow,
along with the upthread patches from Craig Ringer and Marco
On 02/12/2014 07:30 AM, Tom Lane wrote:
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute
-Wformat-security -fno-strict-aliasing -fwrapv -g -Wno-comment -shared -o
plperl.dll plperl.o SPI.o Util.o
Craig Ringer cr...@2ndquadrant.com writes:
On 02/12/2014 07:30 AM, Tom Lane wrote:
BTW, now that I look at this ... why are we bothering to build static
libraries (.a files) for DLLs? They have no possible use AFAICS.
I don't see any use for that with plperl, but it might be a valid thing
Craig Ringer cr...@2ndquadrant.com writes:
On 02/12/2014 07:22 AM, Tom Lane wrote:
So the early returns from currawong are interesting:
Great, that's what I was hoping to see - proper errors where we've
omitted things, not silent miscompilation.
Well, before you get too optimistic about that
On 02/12/2014 08:30 AM, Tom Lane wrote:
Craig Ringer cr...@2ndquadrant.com writes:
On 02/12/2014 07:22 AM, Tom Lane wrote:
So the early returns from currawong are interesting:
Great, that's what I was hoping to see - proper errors where we've
omitted things, not silent miscompilation.
On 02/11/2014 08:04 PM, Craig Ringer wrote:
On 02/12/2014 08:30 AM, Tom Lane wrote:
Craig Ringer cr...@2ndquadrant.com writes:
On 02/12/2014 07:22 AM, Tom Lane wrote:
So the early returns from currawong are interesting:
Great, that's what I was hoping to see - proper errors where we've
Andrew Dunstan and...@dunslane.net writes:
On 02/11/2014 08:04 PM, Craig Ringer wrote:
Looks like currawong doesn't build postgres_fdw.
It sure used to:
http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=currawongdt=2014-02-03%2005%3A30%3A00stg=make
Hm, does the MSVC build system do
On 02/12/2014 09:45 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 02/11/2014 08:04 PM, Craig Ringer wrote:
Looks like currawong doesn't build postgres_fdw.
It sure used to:
(2014/02/12 8:30), Tom Lane wrote:
I wrote:
Hiroshi Inoue in...@tpf.co.jp writes:
I tried MINGW port with the attached change and successfully built
src and contrib and all pararell regression tests were OK.
I cleaned this up a bit (the if-nesting in Makefile.shlib was making
my head hurt,
On Wed, Feb 12, 2014 at 5:30 AM, Craig Ringer cr...@2ndquadrant.com wrote:
On 02/11/2014 11:04 PM, Amit Kapila wrote:
On Tue, Feb 11, 2014 at 11:01 AM, Craig Ringer cr...@2ndquadrant.com wrote:
On 02/11/2014 01:28 PM, Tom Lane wrote:
If there are no objections, I'll push this patch into HEAD
On Feb 12, 2014 4:09 AM, Craig Ringer cr...@2ndquadrant.com wrote:
On 02/12/2014 09:45 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 02/11/2014 08:04 PM, Craig Ringer wrote:
Looks like currawong doesn't build postgres_fdw.
It sure used to:
(2014/02/12 3:03), Tom Lane wrote:
Hiroshi Inoue in...@tpf.co.jp writes:
(2014/02/09 8:06), Andrew Dunstan wrote:
Yeah. Incidentally, we didn't quite get rid of dlltool for Cygwin. We
did get rid of dllwrap. But I agree this is worth trying for Mingw.
I tried MINGW port with the attached
(2014/02/09 8:06), Andrew Dunstan wrote:
On 02/08/2014 05:34 PM, Tom Lane wrote:
Hiroshi Inoue in...@tpf.co.jp writes:
Though I'm not a MINGW expert at all, I know dllwrap is a deprecated
tool and dlltool is almost a deprecated tool. Cygwin port is removing
the use of dllwrap and dlltool now.
(2014/02/10 22:42), Hiroshi Inoue wrote:
(2014/02/09 8:06), Andrew Dunstan wrote:
On 02/08/2014 05:34 PM, Tom Lane wrote:
Hiroshi Inoue in...@tpf.co.jp writes:
Though I'm not a MINGW expert at all, I know dllwrap is a deprecated
tool and dlltool is almost a deprecated tool. Cygwin port is
Inoue, Hiroshi in...@tpf.co.jp writes:
(2014/02/10 22:42), Hiroshi Inoue wrote:
I tried MINGW port with the attached change and successfully built
src and contrib and all pararell regression tests were OK.
I forgot to mention the environment. I tried the change in 2 machines
and both worked.
On 02/11/2014 01:28 PM, Tom Lane wrote:
If there are no objections, I'll push this patch into HEAD tomorrow,
along with the upthread patches from Craig Ringer and Marco Atzeri.
We might as well see if this stuff is going to work ...
I'd love to test my patch properly before pushing it, but my
On 02/09/2014 01:12 AM, Marco Atzeri wrote:
On 09/02/2014 00:06, Andrew Dunstan wrote:
On 02/08/2014 05:34 PM, Tom Lane wrote:
Hiroshi Inoue in...@tpf.co.jp writes:
Though I'm not a MINGW expert at all, I know dllwrap is a deprecated
tool and dlltool is almost a deprecated tool. Cygwin
On 09/02/2014 14:10, Andrew Dunstan wrote:
On 02/09/2014 01:12 AM, Marco Atzeri wrote:
On 09/02/2014 00:06, Andrew Dunstan wrote:
On 02/08/2014 05:34 PM, Tom Lane wrote:
Hiroshi Inoue in...@tpf.co.jp writes:
Though I'm not a MINGW expert at all, I know dllwrap is a deprecated
tool and
Amit Kapila amit.kapil...@gmail.com writes:
On Sun, Feb 9, 2014 at 4:04 AM, Tom Lane t...@sss.pgh.pa.us wrote:
In the meantime, here's a short patch trying the #define extern approach.
Anyone want to try this on a Windows machine or two?
There are quite a few warnings and errors in build:
On 02/05/2014 01:52 PM, Tom Lane wrote:
Craig Ringer cr...@2ndquadrant.com writes:
On 02/05/2014 06:29 AM, Tom Lane wrote:
I had been okay with the manual PGDLLIMPORT-sprinkling approach
(not happy with it, of course, but prepared to tolerate it) as long
as I believed the buildfarm would
On Mon, Feb 10, 2014 at 8:51 AM, Craig Ringer cr...@2ndquadrant.com wrote:
On 02/05/2014 01:52 PM, Tom Lane wrote:
Craig Ringer cr...@2ndquadrant.com writes:
On 02/05/2014 06:29 AM, Tom Lane wrote:
I had been okay with the manual PGDLLIMPORT-sprinkling approach
(not happy with it, of course,
On 02/10/2014 01:59 PM, Amit Kapila wrote:
On Mon, Feb 10, 2014 at 8:51 AM, Craig Ringer cr...@2ndquadrant.com wrote:
On 02/05/2014 01:52 PM, Tom Lane wrote:
Craig Ringer cr...@2ndquadrant.com writes:
On 02/05/2014 06:29 AM, Tom Lane wrote:
I had been okay with the manual
Hiroshi Inoue in...@tpf.co.jp writes:
Though I'm not a MINGW expert at all, I know dllwrap is a deprecated
tool and dlltool is almost a deprecated tool. Cygwin port is removing
the use of dllwrap and dlltool now. Isn't it better for MINGW port to
follow it?
Only way to make that happen is to
On 2014-02-08 17:34:32 -0500, Tom Lane wrote:
Hiroshi Inoue in...@tpf.co.jp writes:
Though I'm not a MINGW expert at all, I know dllwrap is a deprecated
tool and dlltool is almost a deprecated tool. Cygwin port is removing
the use of dllwrap and dlltool now. Isn't it better for MINGW port
On 02/08/2014 05:34 PM, Tom Lane wrote:
Hiroshi Inoue in...@tpf.co.jp writes:
Though I'm not a MINGW expert at all, I know dllwrap is a deprecated
tool and dlltool is almost a deprecated tool. Cygwin port is removing
the use of dllwrap and dlltool now. Isn't it better for MINGW port to
follow
Andres Freund and...@2ndquadrant.com writes:
I think that there's a small problem with your patch, namely that you
made the explicit PGDLLEXPORT definition empty, but that's currently
used in fmgr.h for the function and module magic, I think we actually
need those to be __declspec(dllexport)ed
On 09/02/2014 00:06, Andrew Dunstan wrote:
On 02/08/2014 05:34 PM, Tom Lane wrote:
Hiroshi Inoue in...@tpf.co.jp writes:
Though I'm not a MINGW expert at all, I know dllwrap is a deprecated
tool and dlltool is almost a deprecated tool. Cygwin port is removing
the use of dllwrap and dlltool
(2014/02/05 14:52), Tom Lane wrote:
Craig Ringer cr...@2ndquadrant.com writes:
On 02/05/2014 06:29 AM, Tom Lane wrote:
I had been okay with the manual PGDLLIMPORT-sprinkling approach
(not happy with it, of course, but prepared to tolerate it) as long
as I believed the buildfarm would reliably
OK I can see the error message at PostgreSQL Build Farm Log.
I see a similar problem in a simple test case.
gcc -DCALLPG=\import1\ -c export.c -o export1.o
dlltool --export-all --output-def export1.def export1.o
dlltool --dllname export1.exe --def export1.def --output-lib export1.a
dlltool
On 02/03/2014 07:04 AM, Robert Haas wrote:
On Mon, Feb 3, 2014 at 9:57 AM, Andrew Dunstan and...@dunslane.net wrote:
It's not so long ago that they were saying they would no longer publish
free-as-in-beer command line compilers at all. The outrage made them change
their minds, but we really
On 02/05/2014 01:41 PM, Joshua D. Drake wrote:
On 02/03/2014 07:04 AM, Robert Haas wrote:
On Mon, Feb 3, 2014 at 9:57 AM, Andrew Dunstan and...@dunslane.net
wrote:
It's not so long ago that they were saying they would no longer publish
free-as-in-beer command line compilers at all. The
On 02/05/2014 10:56 AM, Andrew Dunstan wrote:
It appears that LLVM supports Windows:
http://llvm.org/docs/GettingStartedVS.html
If someone wants to work on getting a Windows build working with llvm
then go for it. But until then the Mingw tools are the only thing we
have that we know
On 02/05/2014 01:52 PM, Tom Lane wrote:
Craig Ringer cr...@2ndquadrant.com writes:
On 02/05/2014 06:29 AM, Tom Lane wrote:
I had been okay with the manual PGDLLIMPORT-sprinkling approach
(not happy with it, of course, but prepared to tolerate it) as long
as I believed the buildfarm would
On 02/06/2014 10:14 AM, Craig Ringer wrote:
On 02/05/2014 01:52 PM, Tom Lane wrote:
Craig Ringer cr...@2ndquadrant.com writes:
On 02/05/2014 06:29 AM, Tom Lane wrote:
I had been okay with the manual PGDLLIMPORT-sprinkling approach
(not happy with it, of course, but prepared to tolerate it) as
On Tue, Feb 4, 2014 at 12:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Amit Kapila amit.kapil...@gmail.com writes:
In the function where it is used, it seems to me that it is setting DateStyle
as ISO if it is not ISO and function configure_remote_session() will set it
to ISO initially. So
On 2014-02-04 02:10:47 -0500, Tom Lane wrote:
Amit Kapila amit.kapil...@gmail.com writes:
In the function where it is used, it seems to me that it is setting
DateStyle
as ISO if it is not ISO and function configure_remote_session() will set it
to ISO initially. So basically even if the
Andres Freund and...@2ndquadrant.com writes:
On 2014-02-04 02:10:47 -0500, Tom Lane wrote:
Meh. It might be that the DateStyle usage in postgres_fdw would
accidentally fail to malfunction if it saw a bogus value of the variable.
But it's hard to believe that this would be true of
On 02/04/2014 10:43 AM, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-02-04 02:10:47 -0500, Tom Lane wrote:
Meh. It might be that the DateStyle usage in postgres_fdw would
accidentally fail to malfunction if it saw a bogus value of the variable.
But it's hard to
On February 4, 2014 5:06:52 PM CET, Andrew Dunstan and...@dunslane.net wrote:
On 02/04/2014 10:43 AM, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-02-04 02:10:47 -0500, Tom Lane wrote:
Meh. It might be that the DateStyle usage in postgres_fdw would
accidentally fail
On 02/04/2014 11:30 AM, Andres Freund wrote:
We have details on how to build with Mingw/Msys on Windows on an Amazon
VM http://wiki.postgresql.org/wiki/Building_With_MinGW which is
either
free or very cheap. Do I need to give instructions on how to do this
for
MSVC builds too? It's really
Andrew Dunstan and...@dunslane.net writes:
If someone volunteered to pay for the storage, I'd be prepared to make
some time to create an AMI to reduce the startup time dramatically.
Basically it would be boot the AMI and start testing your patches. I'd
even make it as friendly as possible
On 02/04/2014 09:34 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
If someone volunteered to pay for the storage, I'd be prepared to make
some time to create an AMI to reduce the startup time dramatically.
Basically it would be boot the AMI and start testing your patches. I'd
On Tue, Feb 4, 2014 at 8:06 AM, Andrew Dunstan and...@dunslane.net wrote:
On 02/04/2014 10:43 AM, Tom Lane wrote:
Ugh. This problem was bad enough when I thought that it would only lead
to link-time errors detectable in the buildfarm. If it can lead to errors
only observable at runtime
Joshua D. Drake j...@commandprompt.com writes:
On 02/04/2014 09:34 AM, Tom Lane wrote:
My own opinion is that I've already wasted untold man-hours thanks to
the random porting problems induced by Windows, a platform that I never
have and never will care about personally. I will *not* spend my
On 02/04/2014 10:53 AM, Tom Lane wrote:
Joshua D. Drake j...@commandprompt.com writes:
On 02/04/2014 09:34 AM, Tom Lane wrote:
My own opinion is that I've already wasted untold man-hours thanks to
the random porting problems induced by Windows, a platform that I never
have and never will care
On 02/04/2014 01:53 PM, Tom Lane wrote:
Joshua D. Drake j...@commandprompt.com writes:
On 02/04/2014 09:34 AM, Tom Lane wrote:
My own opinion is that I've already wasted untold man-hours thanks to
the random porting problems induced by Windows, a platform that I never
have and never will care
On 02/04/2014 11:17 AM, Andrew Dunstan wrote:
prepared to declare the entire damn thing no longer supported.
Although that is obviously your prerogative it is important to remember
that Windows is easily the second most used version of PostgreSQL out
there (behind Linux).
[ shrug... ] If
On Tue, Feb 4, 2014 at 9:26 AM, Andrew Dunstan and...@dunslane.net wrote:
On 02/04/2014 11:30 AM, Andres Freund wrote:
We have details on how to build with Mingw/Msys on Windows on an Amazon
VM http://wiki.postgresql.org/wiki/Building_With_MinGW which is
either
free or very cheap. Do I
On Tue, Feb 4, 2014 at 12:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
If someone volunteered to pay for the storage, I'd be prepared to make
some time to create an AMI to reduce the startup time dramatically.
Basically it would be boot the AMI and start
On 02/04/2014 03:08 PM, Jeff Janes wrote:
Do you know about what it would cost? Could official community funds
be used for it (it seems like something that is cheap, but which you
wouldn't want to be forgotten about some month.)
Having an AMI would help, but even with an AMI in place,
Robert Haas robertmh...@gmail.com writes:
You know, I would really prefer to just stick a PGDLLIMPORT on this
place and any others that need it, and any others that come up, than
turn this into a political football. Having to sprinkle PGDLLIMPORT
on the handful of variables that are accessed
Andrew Dunstan and...@dunslane.net writes:
On 02/04/2014 03:08 PM, Jeff Janes wrote:
Having an AMI would help, but even with an AMI in place, MinGW is
still insanely slow. Running make on already made PostgreSQL (so
there was nothing to actually do) takes 1.5 minutes. And a make after
a
On 02/04/2014 05:47 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 02/04/2014 03:08 PM, Jeff Janes wrote:
Having an AMI would help, but even with an AMI in place, MinGW is
still insanely slow. Running make on already made PostgreSQL (so
there was nothing to actually do)
On 02/05/2014 04:08 AM, Jeff Janes wrote:
So doing a git bisect is just painful. Is the MSVC
build faster?
Yes, but not on EC2.
I've found Windows EC2 instances so impossibly slow I just gave up
working with it. It took 1.5 hours to do a build and regression check
with msvc on a Medium EC2
On 02/05/2014 02:53 AM, Tom Lane wrote:
Joshua D. Drake j...@commandprompt.com writes:
On 02/04/2014 09:34 AM, Tom Lane wrote:
My own opinion is that I've already wasted untold man-hours thanks to
the random porting problems induced by Windows, a platform that I never
have and never will care
On 02/04/2014 10:48 PM, Craig Ringer wrote:
On 02/05/2014 04:08 AM, Jeff Janes wrote:
So doing a git bisect is just painful. Is the MSVC
build faster?
Yes, but not on EC2.
I've found Windows EC2 instances so impossibly slow I just gave up
working with it. It took 1.5 hours to do a build
On 02/05/2014 06:29 AM, Tom Lane wrote:
I had been okay with the manual PGDLLIMPORT-sprinkling approach
(not happy with it, of course, but prepared to tolerate it) as long
as I believed the buildfarm would reliably tell us of the need for
it. That assumption has now been conclusively
On 02/05/2014 12:06 AM, Andrew Dunstan wrote:
On 02/04/2014 10:43 AM, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-02-04 02:10:47 -0500, Tom Lane wrote:
Meh. It might be that the DateStyle usage in postgres_fdw would
accidentally fail to malfunction if it saw a
Craig Ringer cr...@2ndquadrant.com writes:
On 02/05/2014 06:29 AM, Tom Lane wrote:
I had been okay with the manual PGDLLIMPORT-sprinkling approach
(not happy with it, of course, but prepared to tolerate it) as long
as I believed the buildfarm would reliably tell us of the need for
it. That
On 2014-02-03 12:00:40 +0800, Craig Ringer wrote:
I think it's a good thing personally - we shouldn't be exporting every
little internal var in the symbol table.
If we built with -fvisibility=hidden on 'nix there'd be no need to
complain about commits being on on 'nix then breaking on
On Sun, Feb 2, 2014 at 3:59 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Page dp...@pgadmin.org writes:
On Sun, Feb 2, 2014 at 1:03 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I think we should give serious consideration to desupporting this
combination so that we can get rid of the plague of
On Mon, Feb 3, 2014 at 5:45 AM, Dave Page dp...@pgadmin.org wrote:
Done:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=narwhaldt=2014-02-03%2009%3A26%3A43
It's not happy though :-(
Specifically, it says:
dlltool --export-all --output-def libpg_buffercachedll.def
pg_buffercache_pages.o
Robert Haas robertmh...@gmail.com writes:
I assume I should go stick a DLLIMPORT on MainLWLockArray, unless
somebody has another proposal.
Hold up awhile. The reason we're resurrecting it is to get a crosscheck
on what symbols it thinks need DLLIMPORT that no other platform does.
Andres Freund and...@2ndquadrant.com writes:
On 2014-02-03 12:00:40 +0800, Craig Ringer wrote:
I think it's a good thing personally - we shouldn't be exporting every
little internal var in the symbol table.
If we built with -fvisibility=hidden on 'nix there'd be no need to
complain about
On 2014-02-03 09:13:02 -0500, Tom Lane wrote:
What we need is to make the Windows platform stop thinking that it is
the center of the world, and make it act as much as possible like the
Unix-oid platforms.
What about the completely crazy thing of simply redefining export to
include the
On 02/03/2014 06:37 PM, Andres Freund wrote:
On 2014-02-03 12:00:40 +0800, Craig Ringer wrote:
I think it's a good thing personally - we shouldn't be exporting every
little internal var in the symbol table.
If we built with -fvisibility=hidden on 'nix there'd be no need to
complain about
On 2014-02-03 22:23:16 +0800, Craig Ringer wrote:
On 02/03/2014 06:37 PM, Andres Freund wrote:
I think that'd be an exercise in futility. We're not talking about a
general purpose library here, where I agree -fvisibility=hidden is a
useful thing, but about the backend. We'd break countless
Andres Freund and...@2ndquadrant.com writes:
What about the completely crazy thing of simply redefining export to
include the declspec on windows for backend build? That will possibly
blow up the size of the .def files et al a bit, but I have little mercy
with that.
You mean #define extern
On 2014-02-03 09:25:57 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
What about the completely crazy thing of simply redefining export to
include the declspec on windows for backend build? That will possibly
blow up the size of the .def files et al a bit, but I have
On 02/03/2014 01:13 AM, Peter Geoghegan wrote:
On Sun, Feb 2, 2014 at 5:22 PM, Craig Ringer cr...@2ndquadrant.com wrote:
I'm not a fan of MinGW (gcc) on Windows, it's a right pain. It's also
the only open source compiler currently supported for PostgreSQL on
Windows - practically the only one
On Mon, Feb 3, 2014 at 9:57 AM, Andrew Dunstan and...@dunslane.net wrote:
It's not so long ago that they were saying they would no longer publish
free-as-in-beer command line compilers at all. The outrage made them change
their minds, but we really can't rely on only Microsoft compilers for
Andrew Dunstan and...@dunslane.net writes:
On 02/03/2014 01:13 AM, Peter Geoghegan wrote:
On Sun, Feb 2, 2014 at 5:22 PM, Craig Ringer cr...@2ndquadrant.com wrote:
I'm not a fan of MinGW (gcc) on Windows, it's a right pain. It's also
the only open source compiler currently supported for
On Mon, Feb 3, 2014 at 11:36 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Amit Kapila amit.kapil...@gmail.com writes:
Also as per below link, it seems that PGDLLIMPORT is required for
exported global variables.
http://msdn.microsoft.com/en-us/library/8fskxacy(v=vs.80).aspx
That was what we'd
Amit Kapila amit.kapil...@gmail.com writes:
In the function where it is used, it seems to me that it is setting DateStyle
as ISO if it is not ISO and function configure_remote_session() will set it
to ISO initially. So basically even if the value of DateStyle is junk, it will
just do what we
Dave Page dp...@pgadmin.org writes:
On Sun, Feb 2, 2014 at 1:03 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I think we should give serious consideration to desupporting this
combination so that we can get rid of the plague of PGDLLIMPORT
marks.
No objection here - though I should point out that
On 02/02/2014 09:03 AM, Tom Lane wrote:
According to the buildfarm database, narwhal is running a gcc build on
Windows 2003. That hardly seems like a mainstream use case. I could
believe that it might be of interest to developers, but clearly no
developers are actually running such a build.
On Mon, Feb 3, 2014 at 6:52 AM, Craig Ringer cr...@2ndquadrant.com wrote:
On 02/02/2014 09:03 AM, Tom Lane wrote:
According to the buildfarm database, narwhal is running a gcc build on
Windows 2003. That hardly seems like a mainstream use case. I could
believe that it might be of
On 02/03/2014 11:10 AM, Ashesh Vashi wrote:
On Mon, Feb 3, 2014 at 6:52 AM, Craig Ringer cr...@2ndquadrant.com
mailto:cr...@2ndquadrant.com wrote:
On 02/02/2014 09:03 AM, Tom Lane wrote:
According to the buildfarm database, narwhal is running a gcc build on
Windows 2003. That
On Mon, Feb 3, 2014 at 6:52 AM, Craig Ringer cr...@2ndquadrant.com wrote:
On 02/02/2014 09:03 AM, Tom Lane wrote:
According to the buildfarm database, narwhal is running a gcc build on
Windows 2003. That hardly seems like a mainstream use case. I could
believe that it might be of interest to
On Sun, Feb 2, 2014 at 6:33 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I happened to notice today that the owner of buildfarm member narwhal
is trying to revive it after a long time offline, but it's failing in
the 9.3 branch (and not attempting to build HEAD, yet). The cause
appears to be that
Amit Kapila amit.kapil...@gmail.com writes:
Also as per below link, it seems that PGDLLIMPORT is required for
exported global variables.
http://msdn.microsoft.com/en-us/library/8fskxacy(v=vs.80).aspx
That was what we'd always assumed, but the fact that postgres_fdw has been
working for the
On Sun, Feb 2, 2014 at 5:22 PM, Craig Ringer cr...@2ndquadrant.com wrote:
I'm not a fan of MinGW (gcc) on Windows, it's a right pain. It's also
the only open source compiler currently supported for PostgreSQL on
Windows - practically the only one available. I don't know about you,
but I'm not
I happened to notice today that the owner of buildfarm member narwhal
is trying to revive it after a long time offline, but it's failing in
the 9.3 branch (and not attempting to build HEAD, yet). The cause
appears to be that contrib/postgres_fdw is referencing the DateStyle
and IntervalStyle
On 2014-02-01 20:03:58 -0500, Tom Lane wrote:
I think we should give serious consideration to desupporting this
combination so that we can get rid of the plague of PGDLLIMPORT
marks. Obviously this would depend on confirming that there are
no more-interesting Windows build methods that
On 02/01/2014 08:03 PM, Tom Lane wrote:
I happened to notice today that the owner of buildfarm member narwhal
is trying to revive it after a long time offline, but it's failing in
the 9.3 branch (and not attempting to build HEAD, yet). The cause
appears to be that contrib/postgres_fdw is
On 2014-02-02 02:15:39 +0100, Andres Freund wrote:
On 2014-02-01 20:03:58 -0500, Tom Lane wrote:
I think we should give serious consideration to desupporting this
combination so that we can get rid of the plague of PGDLLIMPORT
marks. Obviously this would depend on confirming that there are
Andres Freund and...@2ndquadrant.com writes:
On 2014-02-01 20:03:58 -0500, Tom Lane wrote:
I think we should give serious consideration to desupporting this
combination so that we can get rid of the plague of PGDLLIMPORT
marks. Obviously this would depend on confirming that there are
no
Andres Freund and...@2ndquadrant.com writes:
I don't know why it didn't fail for postgres_fdw. Hm, maybe it's because
Mkvcbuild.pm links postgres_fdw with libpq, but not test_shm_mq?
Hard to see how libpq as such could have anything to do with it.
I wonder though if adding libpq causes some
On 2014-02-01 21:04:44 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
I don't know why it didn't fail for postgres_fdw. Hm, maybe it's because
Mkvcbuild.pm links postgres_fdw with libpq, but not test_shm_mq?
Hard to see how libpq as such could have anything to do with
101 - 200 of 201 matches
Mail list logo
