Noah Misch 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 fix.
> ...
> l
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
> > pqGetHomeDirecto
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
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 (i686-4.9.1-re
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 writes:
> > > > On Tue, Oct 14, 2014 at 11:38 PM, Tom Lane wrote:
> > > >> I think we're hoping that somebody
On Mon, Oct 20, 2014 at 11:06:54AM -0400, Tom Lane wrote:
> Noah Misch 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
> > right
> >
Noah Misch 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 the former meth
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 writes:
> > > On Tue, Oct 14, 2014 at 11:38 PM, Tom Lane wrote:
> > >> I think we're hoping that somebody will step up and investigate how
> > >> narwhal's problem
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 different
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 interacti
On Tue, Oct 14, 2014 at 07:07:17PM -0400, Tom Lane wrote:
> Dave Page writes:
> > On Tue, Oct 14, 2014 at 11:38 PM, Tom Lane 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 reproducing narwhal's prob
Dave Page writes:
> On Tue, Oct 14, 2014 at 11:38 PM, Tom Lane 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 that.
> It's a time issue right
On 10/14/2014 06:44 PM, Dave Page wrote:
On Tue, Oct 14, 2014 at 11:38 PM, Tom Lane wrote:
Alvaro Herrera 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 Tue, Oct 14, 2014 at 11:38 PM, Tom Lane wrote:
> Alvaro Herrera 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 thi
Alvaro Herrera 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 step up and investigate
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 Su
(2014/02/18 0:02), Dave Page wrote:
On Mon, Feb 17, 2014 at 2:58 PM, Tom Lane wrote:
Dave Page writes:
On Fri, Feb 14, 2014 at 5:32 PM, Tom Lane 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 enable
(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 li
Hiroshi Inoue 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:
http://www.postgresql.org/mailpref/pgsql-hackers
(2014/02/20 10:32), Tom Lane wrote:
> Hiroshi Inoue 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.
> http://buildfarm.postg
Tom Lane escribió:
> Hiroshi Inoue 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=jacana&dt=2014-02-20%2001%3A00%3A53
>
> Did I fat-finger the commit
Hiroshi Inoue 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=jacana&dt=2014-02-20%2001%3A00%3A53
Did I fat-finger the commit somehow? I made a couple of cosmet
Hiroshi Inoue 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.
(2014/02/12 15:31), Inoue, Hiroshi wrote:
> (2014/02/12 3:03), Tom Lane wrote:
>> Hiroshi Inoue 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.
>
Andres Freund 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 we
>> should thi
On 2014-02-17 10:21:12 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-02-17 15:02:15 +, Dave Page wrote:
> >> On Mon, Feb 17, 2014 at 2:58 PM, Tom Lane wrote:
> >>> In 9.3, narwhal is *still* showing a PGDLLIMPORT-type failure that no
> >>> other Windows critter is unhappy about:
Andres Freund writes:
> On 2014-02-17 15:02:15 +, Dave Page wrote:
>> On Mon, Feb 17, 2014 at 2:58 PM, Tom Lane wrote:
>>> In 9.3, narwhal is *still* showing a PGDLLIMPORT-type failure that no
>>> other Windows critter is unhappy about:
>> Well, as we know, Narwhal is really quite old now. I
On 2014-02-17 15:02:15 +, Dave Page wrote:
> On Mon, Feb 17, 2014 at 2:58 PM, Tom Lane 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 PGDLLIMPOR
On Mon, Feb 17, 2014 at 2:58 PM, Tom Lane wrote:
> Dave Page writes:
>> On Fri, Feb 14, 2014 at 5:32 PM, Tom Lane 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
Dave Page writes:
> On Fri, Feb 14, 2014 at 5:32 PM, Tom Lane 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 ... stop the presses.
In 9.3, nar
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
relativel
On 02/16/2014 07:03 AM, Andres Freund wrote:
> On 2014-02-15 17:48:00 -0500, Tom Lane wrote:
>> Marco Atzeri 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
On Fri, Feb 14, 2014 at 5:32 PM, Tom Lane wrote:
> I wrote:
>> Hiroshi Inoue 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
On 2014-02-16 13:25:58 -0500, Tom Lane wrote:
> Andres Freund 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
Andres Freund 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 doabl
On 2014-02-16 12:57:46 -0500, Tom Lane wrote:
> Marco Atzeri 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
> > ---
Marco Atzeri 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 -lreadline -lcrypt -o
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 -ll
Hiroshi Inoue writes:
> (2014/02/15 2:32), Tom Lane wrote:
>> And what happens is this:
>> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=narwhal&dt=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 the s
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
> libpq/auth.o:auth.c:(
(2014/02/15 2:32), Tom Lane wrote:
> I wrote:
>> Hiroshi Inoue 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 Ma
On 2014-02-15 18:26:46 -0500, Tom Lane wrote:
> Andres Freund 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
Andres Freund 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.
regards, tom lane
On 2014-02-15 17:48:00 -0500, Tom Lane wrote:
> Marco Atzeri 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 thi
On 15/02/2014 23:37, Andres Freund wrote:
On 2014-02-15 17:26:30 -0500, Tom Lane wrote:
Andres Freund 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/com
Marco Atzeri 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?
regards, tom lane
--
Se
Andres Freund 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 linkage is i
On 2014-02-15 17:26:30 -0500, Tom Lane wrote:
> Andres Freund 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
Andres Freund 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
>> postgres
>> libpq/a
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
>
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 21:49:43 +0100, Marco Atzeri wrote:
> On 12/02/2014 17:39, Tom Lane wrote:
> >Andres Freund 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 Cyg
On 12/02/2014 17:39, Tom Lane wrote:
Andres Freund 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'
On 2014-02-15 14:35:02 -0500, Tom Lane wrote:
> Andres Freund 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_I
Andres Freund 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 relying on HAVE_GETOPT_H
Andres Freund 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 sure whether
On 2014-02-15 12:16:58 -0500, Tom Lane wrote:
> Andres Freund 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 o
Andres Freund 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 that'd be solv
On 2014-02-15 10:59:17 -0500, Tom Lane wrote:
> Andres Freund 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 ar
Andres Freund 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 weird
>> platform
On 2014-02-15 10:16:50 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-02-12 14:11:10 -0500, Tom Lane wrote:
> >> Marco Atzeri writes:
> >>> from /usr/include/getopt.h
> >>> extern char __declspec(dllimport) *optarg; /* argument associated
> >>> with option */
>
> >> Hm. All of
Andres Freund writes:
> On 2014-02-12 14:11:10 -0500, Tom Lane wrote:
>> Marco Atzeri writes:
>>> from /usr/include/getopt.h
>>> extern char __declspec(dllimport) *optarg; /* argument associated
>>> with option */
>> Hm. All of our files that use getopt also do
>> extern char *optarg;
>
On 2014-02-12 14:11:10 -0500, Tom Lane wrote:
> Marco Atzeri 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 dlli
(2014/02/15 11:42), Tom Lane wrote:
> Hiroshi Inoue 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, is
Hiroshi Inoue 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 inadequacies in
--
(2014/02/15 2:32), Tom Lane wrote:
> I wrote:
>> Hiroshi Inoue 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 Ma
I wrote:
> Hiroshi Inoue 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 techniq
Hiroshi Inoue 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
> not libp
(2014/02/12 8:30), Tom Lane wrote:
> I wrote:
>> Hiroshi Inoue 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, n
Hiroshi Inoue 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 PGDLLIMPORT macros t
(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 writes:
> I tried MINGW port with the attached change and successfully built
> src and contrib and all pararell regression tests were OK
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 http://www.2ndQuadra
(2014/02/13 8:21), Tom Lane wrote:
> Craig Ringer 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 pyth
On 13/02/2014 00:17, Craig Ringer wrote:
On 02/13/2014 12:39 AM, Tom Lane wrote:
Andres Freund 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 mo
(2014/02/12 12:28), Inoue, Hiroshi wrote:
> (2014/02/12 8:30), Tom Lane wrote:
>> I wrote:
>>> Hiroshi Inoue 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-nestin
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 def
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 in
Craig Ringer 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 works, but at a per
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
On 02/13/2014 05:35 AM, Tom Lane wrote:
> Andres Freund writes:
>> On February 12, 2014 10:23:21 PM CET, Peter Eisentraut
>> 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 th
Craig Ringer 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 been in tou
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 fm
On 02/13/2014 12:39 AM, Tom Lane wrote:
> Andres Freund 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 build
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 mai
On February 12, 2014 10:35:06 PM CET, Tom Lane wrote:
>Andres Freund writes:
>> On February 12, 2014 10:23:21 PM CET, Peter Eisentraut
> 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 infrastruc
Peter Eisentraut 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 as long
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 w
Andres Freund writes:
> On February 12, 2014 10:23:21 PM CET, Peter Eisentraut
> 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 severa
On February 12, 2014 10:23:21 PM CET, 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
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 ca
Marco Atzeri 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 then.
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 Window
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 "--e
On 12/02/2014 17:26, Tom Lane wrote:
Andres Freund 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 http://www.freebs
Andres Freund 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
> wheter enabling
Andres Freund 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 ... narwhal is ming
On 2014-02-12 11:50:41 -0500, Tom Lane wrote:
> Andres Freund 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 --d
On Wed, Feb 12, 2014 at 11:39:43AM -0500, Tom Lane wrote:
> Andres Freund 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
> >> t
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...
Andres Freund 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 advantage in detec
1 - 100 of 202 matches
Mail list logo
