On Wed, Oct 22, 2014 at 12:12:36AM -0400, Noah Misch wrote:
On Mon, Oct 20, 2014 at 01:03:31AM -0400, Noah Misch wrote:
I reproduced narwhal's problem using its toolchain on another 32-bit Windows
Server 2003 system. The crash happens at the SHGetFolderPath() call in
pqGetHomeDirectory().
Noah Misch n...@leadboat.com writes:
Calls to ldap_init() exhibit the same problem shfolder.dll:SHGetFolderPath()
exhibited: it loads and unloads some DLLs, and it manages to unload libpq in
passing. There's nothing comparable to the above workaround this time, but I
found a more fundamental
On Mon, Oct 20, 2014 at 01:03:31AM -0400, Noah Misch wrote:
I reproduced narwhal's problem using its toolchain on another 32-bit Windows
Server 2003 system. The crash happens at the SHGetFolderPath() call in
pqGetHomeDirectory(). A program can acquire that function via shfolder.dll or
via
Noah Misch n...@leadboat.com writes:
I reproduced narwhal's problem using its toolchain on another 32-bit Windows
Server 2003 system. The crash happens at the SHGetFolderPath() call in
pqGetHomeDirectory(). A program can acquire that function via shfolder.dll or
via shell32.dll; we've used
On Mon, Oct 20, 2014 at 11:06:54AM -0400, Tom Lane wrote:
Noah Misch n...@leadboat.com writes:
I don't expect to understand the mechanism
behind it, but I recommend we switch back to linking libpq with shell32.dll.
The MSVC build already does that in all supported branches, and it feels
On 2014-10-20 01:03:31 -0400, Noah Misch wrote:
On Wed, Oct 15, 2014 at 12:53:03AM -0400, Noah Misch wrote:
On Tue, Oct 14, 2014 at 07:07:17PM -0400, Tom Lane wrote:
Dave Page dp...@pgadmin.org writes:
On Tue, Oct 14, 2014 at 11:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I think we're
On Mon, Oct 20, 2014 at 10:24:47PM +0200, Andres Freund wrote:
On 2014-10-20 01:03:31 -0400, Noah Misch wrote:
On Wed, Oct 15, 2014 at 12:53:03AM -0400, Noah Misch wrote:
I happened to try the same contrib/dblink test suite on PostgreSQL built
with
modern MinGW-w64
On 10/15/2014 01:53 AM, Craig Ringer wrote:
On 10/15/2014 12:53 PM, Noah Misch wrote:
Windows Server 2003 isn't even EOL yet. I'd welcome a buildfarm member with
that OS and a modern toolchain.
It's possible to run multiple buildfarm animals on a single Windows
instance, each with a
It seems we left this in broken state. Do we need to do more here to
fix narwhal, or do we want to retire narwhal now? Something else? Are
we waiting on someone in particular to do something specific?
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7
Alvaro Herrera alvhe...@2ndquadrant.com writes:
It seems we left this in broken state. Do we need to do more here to
fix narwhal, or do we want to retire narwhal now? Something else? Are
we waiting on someone in particular to do something specific?
I think we're hoping that somebody will
On Tue, Oct 14, 2014 at 11:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
It seems we left this in broken state. Do we need to do more here to
fix narwhal, or do we want to retire narwhal now? Something else? Are
we waiting on someone in particular
On 10/14/2014 06:44 PM, Dave Page wrote:
On Tue, Oct 14, 2014 at 11:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
It seems we left this in broken state. Do we need to do more here to
fix narwhal, or do we want to retire narwhal now? Something
Dave Page dp...@pgadmin.org writes:
On Tue, Oct 14, 2014 at 11:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I think we're hoping that somebody will step up and investigate how
narwhal's problem might be fixed. However, the machine's owner (Dave)
doesn't appear to have the time/interest to do
On Tue, Oct 14, 2014 at 07:07:17PM -0400, Tom Lane wrote:
Dave Page dp...@pgadmin.org writes:
On Tue, Oct 14, 2014 at 11:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I think we're hoping that somebody will step up and investigate how
narwhal's problem might be fixed.
I have planned to look at
On 10/15/2014 12:53 PM, Noah Misch wrote:
Windows Server 2003 isn't even EOL yet. I'd welcome a buildfarm member with
that OS and a modern toolchain.
It's possible to run multiple buildfarm animals on a single Windows
instance, each with a different toolchain.
There's the chance of
(Top post, on phone)
The @number part is optional. It indicates an export ordinal. (You don't want
to know, if you do, see MSDN).
If you remove them or change them then binaries linked to the older version
will fail to link to the newer; it breaks binary compat. The ordinals are part
of the
(2014/02/18 0:02), Dave Page wrote:
On Mon, Feb 17, 2014 at 2:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Page dp...@pgadmin.org writes:
On Fri, Feb 14, 2014 at 5:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
(BTW, narwhal is evidently not trying to build plpython. I wonder
why not?)
Not
Hiroshi Inoue in...@tpf.co.jp writes:
(2014/02/12 3:03), Tom Lane wrote:
Also, the only remaining usage of dllwrap is in src/bin/pgevent/Makefile.
Do we need that either?
Sorry for the late reply.
Attached is a patch to remove dllwarp from pgevent/Makefile.
Pushed, thanks.
Hiroshi Inoue in...@tpf.co.jp writes:
Attached is a patch to remove dllwarp from pgevent/Makefile.
Actually, it looks like this patch doesn't work at all:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jacanadt=2014-02-20%2001%3A00%3A53
Did I fat-finger the commit somehow? I made a
Tom Lane escribió:
Hiroshi Inoue in...@tpf.co.jp writes:
Attached is a patch to remove dllwarp from pgevent/Makefile.
Actually, it looks like this patch doesn't work at all:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jacanadt=2014-02-20%2001%3A00%3A53
Did I fat-finger the
(2014/02/20 10:32), Tom Lane wrote:
Hiroshi Inoue in...@tpf.co.jp writes:
Attached is a patch to remove dllwarp from pgevent/Makefile.
Actually, it looks like this patch doesn't work at all:
Strangely enough it works here though I see double EXPORTS lines
in libpgeventdll.def.
Hiroshi Inoue in...@tpf.co.jp writes:
Seems EXPORTS line in exports.txt should be removed.
Done.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
(2014/02/12 15:31), Inoue, Hiroshi wrote:
(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.
On Fri, Feb 14, 2014 at 5:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
Hiroshi Inoue in...@tpf.co.jp writes:
One thing I'm wondering about is that plperl is linking perlxx.lib
not libperlxx.a. I made a patch following plpython and it also
works here.
Is it worth trying?
I hadn't
On 02/16/2014 07:03 AM, Andres Freund wrote:
On 2014-02-15 17:48:00 -0500, Tom Lane wrote:
Marco Atzeri marco.atz...@gmail.com writes:
32 $ grep -rH in6addr_any *
cygwin/in6.h:extern const struct in6_addr in6addr_any;
cygwin/version.h: in6addr_any, in6addr_loopback.
So how come
Hi,
I just wanted to mention that it should probably not be too hard to
emulate the current windows behaviour in gcc/clang elf targets. Somebody
(won't be me) could add a --emulate-windows-linkage configure flag or
such.
By mapping PGDLLIMPORT to__attribute__((section(...))) it should be
Dave Page dp...@pgadmin.org writes:
On Fri, Feb 14, 2014 at 5:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
(BTW, narwhal is evidently not trying to build plpython. I wonder
why not?)
Not sure - it's certainly installed on the box. I've enabled it for
now, and will see what happens.
Sigh ...
On Mon, Feb 17, 2014 at 2:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Page dp...@pgadmin.org writes:
On Fri, Feb 14, 2014 at 5:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
(BTW, narwhal is evidently not trying to build plpython. I wonder
why not?)
Not sure - it's certainly installed on the
On 2014-02-17 15:02:15 +, Dave Page wrote:
On Mon, Feb 17, 2014 at 2:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Not sure - it's certainly installed on the box. I've enabled it for
now, and will see what happens.
Sigh ... stop the presses.
In 9.3, narwhal is *still* showing a
Andres Freund and...@2ndquadrant.com writes:
On 2014-02-17 15:02:15 +, Dave Page wrote:
On Mon, Feb 17, 2014 at 2:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
In 9.3, narwhal is *still* showing a PGDLLIMPORT-type failure that no
other Windows critter is unhappy about:
Well, as we know,
On 2014-02-17 10:21:12 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-02-17 15:02:15 +, Dave Page wrote:
On Mon, Feb 17, 2014 at 2:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
In 9.3, narwhal is *still* showing a PGDLLIMPORT-type failure that no
other Windows
Andres Freund and...@2ndquadrant.com writes:
On 2014-02-17 10:21:12 -0500, Tom Lane wrote:
Although on second thought, the lack of complaints from other Windows
animals can probably be blamed on the fact that we didn't back-port
any of the recent hacking on the Windows build processes. Maybe
Marco, Andrew:
On 2014-02-15 22:11:37 +0100, Marco Atzeri wrote:
../../src/timezone/localtime.o ../../src/timezone/strftime.o
../../src/timezone/pgtz.o ../../src/port/libpgport_srv.a
../../src/common/libpgcommon_srv.a -lintl -lssl -lcrypto -lcrypt -lldap -o
postgres
Hiroshi Inoue in...@tpf.co.jp writes:
(2014/02/15 2:32), Tom Lane wrote:
And what happens is this:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=narwhaldt=2014-02-14%2017%3A00%3A02
namely, it gets through plperl now and then chokes with the same
symptoms on pltcl. So I guess we need
On 16/02/2014 15:43, Andres Freund wrote:
Marco, Andrew:
On 2014-02-15 22:11:37 +0100, Marco Atzeri wrote:
../../src/timezone/localtime.o ../../src/timezone/strftime.o
../../src/timezone/pgtz.o ../../src/port/libpgport_srv.a
../../src/common/libpgcommon_srv.a -lintl -lssl -lcrypto -lcrypt
Marco Atzeri marco.atz...@gmail.com writes:
On 16/02/2014 15:43, Andres Freund wrote:
Could either of you try whether compiling with the attached hack fixes
anything on cygwin?
on cygwin32 bit it works, but it stops later on
---
sl -lcrypto -lz
On 2014-02-16 12:57:46 -0500, Tom Lane wrote:
Marco Atzeri marco.atz...@gmail.com writes:
On 16/02/2014 15:43, Andres Freund wrote:
Could either of you try whether compiling with the attached hack fixes
anything on cygwin?
on cygwin32 bit it works, but it stops later on
Andres Freund and...@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
On 2014-02-16 13:25:58 -0500, Tom Lane wrote:
Andres Freund and...@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
(2014/02/15 11:42), Tom Lane wrote:
Hiroshi Inoue in...@tpf.co.jp writes:
(2014/02/15 2:32), Tom Lane wrote:
(BTW, narwhal is evidently not trying to build plpython. I wonder
why not?)
Due to *initializer element is not constant* error which also can be
see on my old machine.
Hmm,
On 2014-02-12 14:11:10 -0500, Tom Lane wrote:
Marco Atzeri marco.atz...@gmail.com writes:
On 12/02/2014 19:19, Andres Freund wrote:
On 2014-02-12 19:13:07 +0100, Marco Atzeri wrote:
About PGDLLIMPORT , my build log is full of warning: ‘optarg’ redeclared
without dllimport attribute:
Andres Freund and...@2ndquadrant.com writes:
On 2014-02-12 14:11:10 -0500, Tom Lane wrote:
Marco Atzeri marco.atz...@gmail.com writes:
from /usr/include/getopt.h
extern char __declspec(dllimport) *optarg; /* argument associated
with option */
Hm. All of our files that use getopt also
On 2014-02-15 10:16:50 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-02-12 14:11:10 -0500, Tom Lane wrote:
Marco Atzeri marco.atz...@gmail.com writes:
from /usr/include/getopt.h
extern char __declspec(dllimport) *optarg; /* argument associated
with
Andres Freund and...@2ndquadrant.com writes:
On 2014-02-15 10:16:50 -0500, Tom Lane wrote:
The best thing probably is not to have the duplicate declarations on
platforms that don't need 'em. Unfortunately, I seem to recall that
the current coding was arrived at to forestall link problems on
On 2014-02-15 10:59:17 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-02-15 10:16:50 -0500, Tom Lane wrote:
The best thing probably is not to have the duplicate declarations on
platforms that don't need 'em. Unfortunately, I seem to recall that
the current
Andres Freund and...@2ndquadrant.com writes:
On 2014-02-15 10:59:17 -0500, Tom Lane wrote:
I don't have time right now to research it (have to go shovel snow),
but I think that at least some of the issue was that we needed the
externs when we force use of our src/port implementation.
I think
On 2014-02-15 12:16:58 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-02-15 10:59:17 -0500, Tom Lane wrote:
I don't have time right now to research it (have to go shovel snow),
but I think that at least some of the issue was that we needed the
externs when we
Andres Freund and...@2ndquadrant.com writes:
On 2014-02-15 18:21:56 +0100, Andres Freund wrote:
On 2014-02-15 12:16:58 -0500, Tom Lane wrote:
Yeah, there are enough copies of that stuff that centralizing them
sounds like a great idea. Call it pg_getopt.h, perhaps?
Patch attached. I am not
Andres Freund and...@2ndquadrant.com writes:
Patch attached.
Committed with some cosmetic adjustments --- thanks!
I am not sure whether HAVE_GETOPT is the best condition
to use, since it's set by configure by a link based check, same goes for
HAVE_INT_OPTERR. The other choices would be
On 2014-02-15 14:35:02 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
Patch attached.
Committed with some cosmetic adjustments --- thanks!
I am not sure whether HAVE_GETOPT is the best condition
to use, since it's set by configure by a link based check, same goes
On 12/02/2014 17:39, 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 the Cygwin build works more like
the other
On 2014-02-15 21:49:43 +0100, Marco Atzeri wrote:
On 12/02/2014 17:39, 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
On 15/02/2014 21:54, Andres Freund wrote:
Please pull and retry, that already might fix it. The reason it's
probably failing is the warnings about declspec you reported earlier.
See 60ff2fdd9970ba29f5267317a5e7354d2658c1e5
Greetings,
Andres Freund
that is fine.
there is a different one,
On 2014-02-15 22:11:37 +0100, Marco Atzeri wrote:
On 15/02/2014 21:54, Andres Freund wrote:
Please pull and retry, that already might fix it. The reason it's
probably failing is the warnings about declspec you reported earlier.
See 60ff2fdd9970ba29f5267317a5e7354d2658c1e5
Greetings,
Andres Freund and...@2ndquadrant.com writes:
On 2014-02-15 22:11:37 +0100, Marco Atzeri wrote:
../../src/timezone/localtime.o ../../src/timezone/strftime.o
../../src/timezone/pgtz.o ../../src/port/libpgport_srv.a
../../src/common/libpgcommon_srv.a -lintl -lssl -lcrypto -lcrypt -lldap -o
On 2014-02-15 17:26:30 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-02-15 22:11:37 +0100, Marco Atzeri wrote:
../../src/timezone/localtime.o ../../src/timezone/strftime.o
../../src/timezone/pgtz.o ../../src/port/libpgport_srv.a
Marco Atzeri marco.atz...@gmail.com writes:
32 $ grep -rH in6addr_any *
cygwin/in6.h:extern const struct in6_addr in6addr_any;
cygwin/version.h: in6addr_any, in6addr_loopback.
So how come there's a declspec on the getopt.h variables, but not this
one?
Andres Freund and...@2ndquadrant.com writes:
On 2014-02-15 17:26:30 -0500, Tom Lane wrote:
The interesting question here is why it used to work. There is no
extern for in6addr_any in our code, so there must have been a
declaration of that constant in some system header. Which one, and
what
On 15/02/2014 23:37, Andres Freund wrote:
On 2014-02-15 17:26:30 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-02-15 22:11:37 +0100, Marco Atzeri wrote:
../../src/timezone/localtime.o ../../src/timezone/strftime.o
../../src/timezone/pgtz.o
On 2014-02-15 17:48:00 -0500, Tom Lane wrote:
Marco Atzeri marco.atz...@gmail.com writes:
32 $ grep -rH in6addr_any *
cygwin/in6.h:extern const struct in6_addr in6addr_any;
cygwin/version.h: in6addr_any, in6addr_loopback.
So how come there's a declspec on the getopt.h
Andres Freund and...@2ndquadrant.com writes:
It might be that ipv6 never worked for mingw and cygwin, and in6addr_any
just resolved to some magic thunk --auto-import created...
Yeah, it would not be surprising if this exercise is exposing bugs
we didn't even know we had.
On 2014-02-15 18:26:46 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
It might be that ipv6 never worked for mingw and cygwin, and in6addr_any
just resolved to some magic thunk --auto-import created...
Yeah, it would not be surprising if this exercise is exposing bugs
(2014/02/15 2:32), Tom Lane wrote:
I wrote:
Hiroshi Inoue in...@tpf.co.jp writes:
One thing I'm wondering about is that plperl is linking perlxx.lib
not libperlxx.a. I made a patch following plpython and it also
works here.
Is it worth trying?
I hadn't noticed that part of plpython's
(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,
Hiroshi Inoue in...@tpf.co.jp writes:
(2014/02/12 8:30), Tom Lane wrote:
Not very clear what's going on there; could this be a problem in
narwhal's admittedly-ancient toolchain?
The error doesn't occur here (un)fortunately.
One thing I'm wondering about is that plperl is linking perlxx.lib
I wrote:
Hiroshi Inoue in...@tpf.co.jp writes:
One thing I'm wondering about is that plperl is linking perlxx.lib
not libperlxx.a. I made a patch following plpython and it also
works here.
Is it worth trying?
I hadn't noticed that part of plpython's Makefile before. Man,
that's an ugly
(2014/02/15 2:32), Tom Lane wrote:
I wrote:
Hiroshi Inoue in...@tpf.co.jp writes:
One thing I'm wondering about is that plperl is linking perlxx.lib
not libperlxx.a. I made a patch following plpython and it also
works here.
Is it worth trying?
I hadn't noticed that part of plpython's
Hiroshi Inoue in...@tpf.co.jp writes:
(2014/02/15 2:32), Tom Lane wrote:
(BTW, narwhal is evidently not trying to build plpython. I wonder
why not?)
Due to *initializer element is not constant* error which also can be
see on my old machine.
Hmm, isn't that one of the symptoms of
(2014/02/13 9:51), Hiroshi Inoue wrote:
(2014/02/12 12:28), Inoue, Hiroshi wrote:
(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.
Hiroshi Inoue in...@tpf.co.jp writes:
Rebuild with --disable-auto-import causes errors in contrib on
both machines. Errors occur in pg_buffercache, pg_stat_statements,
postgres_fdw and test_shm_mq.
Yeah, that's the idea: we want to get the same failures as on MSVC.
I'm going to put in
Craig Ringer cr...@2ndquadrant.com writes:
Great, that's what I was hoping to see - proper errors where we've
omitted things, not silent miscompilation.
And, just to make sure that ain't nobody happy ... brolga, our one
operational Cygwin animal, is still building without complaints.
We really
On 2014-02-12 10:58:20 -0500, Tom Lane wrote:
Craig Ringer cr...@2ndquadrant.com writes:
Great, that's what I was hoping to see - proper errors where we've
omitted things, not silent miscompilation.
And, just to make sure that ain't nobody happy ... brolga, our one
operational Cygwin
Andres Freund and...@2ndquadrant.com writes:
On 2014-02-12 10:58:20 -0500, Tom Lane wrote:
Anybody know *exactly* what --enable-auto-import does? The name
is, um, suggestive.
My ld(1)'s manpage has three screen's worth of details... Most of it
seems to be on
On 2014-02-12 11:26:56 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-02-12 10:58:20 -0500, Tom Lane wrote:
Anybody know *exactly* what --enable-auto-import does? The name
is, um, suggestive.
My ld(1)'s manpage has three screen's worth of details... Most of
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 the Cygwin build works more like
the other Windows builds?
Hm, I don't see a big
On 2014-02-12 11:39:43 -0500, Tom Lane wrote:
I'm going to go remove that switch and see if brolga starts failing.
If it does, I'll be satisfied that we understand the issues here.
The manpage also has a --disable-auto-import, but doesn't document
wheter enabling or disabling is the default...
On Wed, Feb 12, 2014 at 11:39:43AM -0500, 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 the Cygwin build works
On 2014-02-12 11:50:41 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-02-12 11:39:43 -0500, Tom Lane wrote:
I'm going to go remove that switch and see if brolga starts failing.
If it does, I'll be satisfied that we understand the issues here.
The manpage
Andres Freund and...@2ndquadrant.com writes:
Some release notes I just found seem to suggest it is
http://sourceware.org/binutils/docs-2.17/ld/WIN32.html :
This feature is enabled with the `--enable-auto-import' command-line
option, although it is enabled by default on cygwin/mingw.
Curious
Andres Freund and...@2ndquadrant.com writes:
On 2014-02-12 11:39:43 -0500, Tom Lane wrote:
I'm going to go remove that switch and see if brolga starts failing.
If it does, I'll be satisfied that we understand the issues here.
The manpage also has a --disable-auto-import, but doesn't document
On 12/02/2014 17:26, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-02-12 10:58:20 -0500, Tom Lane wrote:
Anybody know *exactly* what --enable-auto-import does? The name
is, um, suggestive.
My ld(1)'s manpage has three screen's worth of details... Most of it
seems to
On 2014-02-12 19:13:07 +0100, Marco Atzeri wrote:
On 12/02/2014 17:26, 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 the Cygwin build works more like
the other Windows builds?
If I am not wrong
On 12/02/2014 19:19, Andres Freund wrote:
On 2014-02-12 19:13:07 +0100, Marco Atzeri wrote:
On 12/02/2014 17:26, 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 the Cygwin build works more like
the other
Marco Atzeri marco.atz...@gmail.com writes:
On 12/02/2014 19:19, Andres Freund wrote:
On 2014-02-12 19:13:07 +0100, Marco Atzeri wrote:
About PGDLLIMPORT , my build log is full of warning: âoptargâ
redeclared
without dllimport attribute: previous dllimport ignored
That should be fixed
On 2/11/14, 7:04 PM, Craig Ringer wrote:
I don't see any use for that with plperl, but it might be a valid thing
to be doing for (e.g.) hstore.dll. Though you can't really link to it
from another module anyway, you have to go through the fmgr to get
access to its symbols at rutime, so we can
On February 12, 2014 10:23:21 PM CET, Peter Eisentraut pete...@gmx.net wrote:
On 2/11/14, 7:04 PM, Craig Ringer wrote:
I don't see any use for that with plperl, but it might be a valid
thing
to be doing for (e.g.) hstore.dll. Though you can't really link to it
from another module anyway, you
Andres Freund and...@2ndquadrant.com writes:
On February 12, 2014 10:23:21 PM CET, Peter Eisentraut pete...@gmx.net
wrote:
There are cases where one module needs symbols from another directly.
Would that be affected by this?
I don't think we have real infrastructure for that yet. Neither
On 2/12/14, 4:30 PM, Andres Freund wrote:
There are cases where one module needs symbols from another directly.
Would that be affected by this?
I don't think we have real infrastructure for that yet. Neither from the POV
of loading several .so's, nor from a symbol visibility. Afaics we'd
Peter Eisentraut pete...@gmx.net writes:
There are cases where one module needs symbols from another directly.
Would that be affected by this?
It works reasonably well on other platforms.
Of course, we can barely build extension modules on Windows, so maybe
this is a bit much to ask. But
On February 12, 2014 10:35:06 PM CET, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@2ndquadrant.com writes:
On February 12, 2014 10:23:21 PM CET, Peter Eisentraut
pete...@gmx.net wrote:
There are cases where one module needs symbols from another
directly.
Would that be affected by
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 from the python
DLL.
Wow. Has anyone been in touch with the Python package
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 the Cygwin build works more like
the other
On 02/13/2014 05:23 AM, Peter Eisentraut wrote:
On 2/11/14, 7:04 PM, Craig Ringer wrote:
I don't see any use for that with plperl, but it might be a valid thing
to be doing for (e.g.) hstore.dll. Though you can't really link to it
from another module anyway, you have to go through the fmgr to
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 from the python
DLL.
Wow. Has anyone
On 02/13/2014 05:35 AM, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On February 12, 2014 10:23:21 PM CET, Peter Eisentraut pete...@gmx.net
wrote:
There are cases where one module needs symbols from another directly.
Would that be affected by this?
I don't think we have
On 02/13/2014 05:35 AM, Peter Eisentraut wrote:
On 2/12/14, 4:30 PM, Andres Freund wrote:
There are cases where one module needs symbols from another directly.
Would that be affected by this?
I don't think we have real infrastructure for that yet. Neither from the POV
of loading several
Craig Ringer cr...@2ndquadrant.com writes:
However, from the reading I've done recently, I'm pretty sure that if
you fail to declare __declspec(dllimport) on the importing side, you
actually land up statically linking to a thunk function that in turn
calls the real function in the DLL. So it
On 2014-02-13 07:58:09 +0800, Craig Ringer wrote:
On 02/13/2014 05:35 AM, Peter Eisentraut wrote:
On 2/12/14, 4:30 PM, Andres Freund wrote:
There are cases where one module needs symbols from another directly.
Would that be affected by this?
I don't think we have real infrastructure for
On 02/13/2014 08:26 AM, Andres Freund wrote:
It gets worse, too. Say you want hstore to export a couple of symbols.
Those symbols must be __declspec(dllexport) while everything else in
headers must be __declspec(dllimport). This means you can't just use
PGDLLIMPORT. You must define a
(2014/02/12 12:28), Inoue, Hiroshi wrote:
(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
1 - 100 of 201 matches
Mail list logo
