narwhal and PGDLLIMPORT
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 variables, which aren't marked PGDLLIMPORT.
Hm, well, that would be an easy change ... but that code was committed
last March. How is it that we didn't notice this long ago?
What this seems to indicate is that narwhal is the only buildfarm
animal that has a need for PGDLLIMPORT marks on global variables that
are referenced by extensions. Furthermore, nobody has attempted to
build 9.3 on a platform that needs that (or at least they've not
reported failure to us).
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.
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 require it --- but
if there are any, I'd sure demand that there be an active buildfarm
instance to keep us from breaking the case again in future.
Thoughts?
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
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 require it --- but
if there are any, I'd sure demand that there be an active buildfarm
instance to keep us from breaking the case again in future.
Weren't there more recent cases of needing to add PGDLLIMPORTs? I
certainly remember pushing code to Craig's jenkins instance which made
me do so for recent msvc
builds... E.g. 7d7eee8bb702d7796a0d7c5886c1f4685f2e2806 and
708c529c7fdeba9387825d746752fc6f439d781e just a few days ago seems to be
some of those cases.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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 referencing the DateStyle
and IntervalStyle variables, which aren't marked PGDLLIMPORT.
Hm, well, that would be an easy change ... but that code was committed
last March. How is it that we didn't notice this long ago?What this seems to indicate is that narwhal is the only buildfarm
animal that has a need for PGDLLIMPORT marks on global variables that
are referenced by extensions. Furthermore, nobody has attempted to
build 9.3 on a platform that needs that (or at least they've not
reported failure to us).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.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 require it --- but
if there are any, I'd sure demand that there be an active buildfarm
instance to keep us from breaking the case again in future.Thoughts?
I don't think that it's Windows 2003 that matters so much here as the
fact that it's a very old version of gcc. For example, my fairly old
buildfarm animal frogmouth, which will be decommissioned soon when
WindowsNT is totally unsupported, runs gcc 4.5.0, whereas narwhal runs
3.4.2. If anyone is really using such an old version, I think they
should stop, immediately.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
no more-interesting Windows build methods that require it --- but
if there are any, I'd sure demand that there be an active buildfarm
instance to keep us from breaking the case again in future.Weren't there more recent cases of needing to add PGDLLIMPORTs? I
certainly remember pushing code to Craig's jenkins instance which made
me do so for recent msvc
builds... E.g. 7d7eee8bb702d7796a0d7c5886c1f4685f2e2806 and
708c529c7fdeba9387825d746752fc6f439d781e just a few days ago seems to be
some of those cases.
And indeed, currawong failed with a link time error:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=currawong&dt=2014-01-17%2013%3A30%3A21
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?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andres Freund <andres@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 more-interesting Windows build methods that require it --- but
if there are any, I'd sure demand that there be an active buildfarm
instance to keep us from breaking the case again in future.
Weren't there more recent cases of needing to add PGDLLIMPORTs?
Yeah, which makes the plot even thicker. If references to those
variables failed, how did we not notice postgres_fdw's issue?
I don't claim to know exactly what's going on, but I think we need
to find out.
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
Andres Freund <andres@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 different link-time
switch to be used. If so, could we arrange to use that switch
all the time, and thus get rid of the need for PGDLLIMPORT marks?
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
On 2014-02-01 21:04:44 -0500, Tom Lane wrote:
Andres Freund <andres@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 different link-time
switch to be used. If so, could we arrange to use that switch
all the time, and thus get rid of the need for PGDLLIMPORT marks?
Well, not because of libpq itself, but because it causes a def file to
be used. I am not sure how they are autogenerated, but it might already
cause. I fortunately have forgotten most of that uglyness.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sun, Feb 2, 2014 at 1:03 AM, Tom Lane <tgl@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 contrib/postgres_fdw is referencing the DateStyle
and IntervalStyle variables, which aren't marked PGDLLIMPORT.
Hm, well, that would be an easy change ... but that code was committed
last March. How is it that we didn't notice this long ago?What this seems to indicate is that narwhal is the only buildfarm
animal that has a need for PGDLLIMPORT marks on global variables that
are referenced by extensions. Furthermore, nobody has attempted to
build 9.3 on a platform that needs that (or at least they've not
reported failure to us).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.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 require it --- but
if there are any, I'd sure demand that there be an active buildfarm
instance to keep us from breaking the case again in future.
No objection here - though I should point out that it's not been
offline for a long time (aside from a couple of weeks in January) -
it's been happily building most pre-9.2 branches for ages. 9.1 seems
to be stuck, along with HEAD, and I forgot to add 9.3. I'm in the
process of cleaning that up as time allows, but am happy to drop it
instead if we no longer want to support anything that old. We
certainly don't use anything resembling that config for the EDB
installer builds.
I'm happy to replace it with something newer as time allows - what do
we consider to be the biggest gap? I have an MSDN subscription, so can
do any versions of Windows or VC++ (and obviously Mingw).
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Dave Page <dpage@pgadmin.org> writes:
On Sun, Feb 2, 2014 at 1:03 AM, Tom Lane <tgl@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 it's not been
offline for a long time (aside from a couple of weeks in January) -
it's been happily building most pre-9.2 branches for ages. 9.1 seems
to be stuck, along with HEAD, and I forgot to add 9.3. I'm in the
process of cleaning that up as time allows, but am happy to drop it
instead if we no longer want to support anything that old. We
certainly don't use anything resembling that config for the EDB
installer builds.
Further discussion pointed out that currawong, for example, seems to
want PGDLLIMPORT markings but is able to get by without them in
some cases that narwhal evidently doesn't like. So at this point,
desupporting narwhal's configuration is clearly premature --- we
should instead be looking into exactly what is causing the different
cases to fail or not fail.
I still have hopes that we might be able to get rid of PGDLLIMPORT
marks, but by actually understanding why they seem to be needed in
some cases and not others, not by just arbitrarily dropping support.
In the meantime, please do get HEAD running again on that machine.
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
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.I think we should give serious consideration to desupporting this
combination
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 too keen on assuming Microsoft will continue to offer free
toolchains that're usable for our purposes. They're crippling their free
build tools more and more with each release, which isn't a good trend.
If you wish to eliminate PGDLLIMPORT from the codebase the correct
approach would be building with --export-all-symbols (a MinGW extension
flag to gcc). That would make the MinGW builds consistent with the MSVC
build, which generates a .def file that exports all symbols.
As for why PGDLLIMPORT appears to be required in some places on the MSVC
build, so far it's looking like we auto-export functions, but not
necessarily variables. I'd need to read the fairly scary MSVC build
genreator scripts in detail to confirm that, to see how they produce
their DEF files; that'll have to wait until after I've got the
row-security work sorted out.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Feb 3, 2014 at 6:52 AM, Craig Ringer <craig@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 developers, but clearly no
developers are actually running such a build.I think we should give serious consideration to desupporting this
combinationI'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 too keen on assuming Microsoft will continue to offer free
toolchains that're usable for our purposes. They're crippling their free
build tools more and more with each release, which isn't a good trend.If you wish to eliminate PGDLLIMPORT from the codebase the correct
approach would be building with --export-all-symbols (a MinGW extension
flag to gcc). That would make the MinGW builds consistent with the MSVC
build, which generates a .def file that exports all symbols.As for why PGDLLIMPORT appears to be required in some places on the MSVC
build, so far it's looking like we auto-export functions, but not
necessarily variables.
In my experience, that is true.
During some contrib module development, while accessing a postgresql
variable
it was crashing on windows, while same was accessible in non-windows
platform.
I'd need to read the fairly scary MSVC build
genreator scripts in detail to confirm that, to see how they produce
their DEF files; that'll have to wait until after I've got the
row-security work sorted out.--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
--
Thanks & Regards,
Ashesh Vashi
EnterpriseDB INDIA: Enterprise PostgreSQL Company<http://www.enterprisedb.com>
*http://www.linkedin.com/in/asheshvashi*<http://www.linkedin.com/in/asheshvashi>
On 02/03/2014 11:10 AM, Ashesh Vashi wrote:
On Mon, Feb 3, 2014 at 6:52 AM, Craig Ringer <craig@2ndquadrant.com
<mailto:craig@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 developers, but clearly no
developers are actually running such a build.I think we should give serious consideration to desupporting this
combinationI'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 too keen on assuming Microsoft will continue to offer free
toolchains that're usable for our purposes. They're crippling their free
build tools more and more with each release, which isn't a good trend.If you wish to eliminate PGDLLIMPORT from the codebase the correct
approach would be building with --export-all-symbols (a MinGW extension
flag to gcc). That would make the MinGW builds consistent with the MSVC
build, which generates a .def file that exports all symbols.As for why PGDLLIMPORT appears to be required in some places on the MSVC
build, so far it's looking like we auto-export functions, but not
necessarily variables.In my experience, that is true.
During some contrib module development, while accessing a postgresql
variable
it was crashing on windows, while same was accessible in non-windows
platform.
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 Windows, 'cos
the 'nix build would break in the same place. That's all or nothing
though, there's no "vars hidden, procs exported" option in gcc.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Feb 3, 2014 at 6:52 AM, Craig Ringer <craig@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 developers, but clearly no
developers are actually running such a build.I think we should give serious consideration to desupporting this
combinationI'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 too keen on assuming Microsoft will continue to offer free
toolchains that're usable for our purposes. They're crippling their free
build tools more and more with each release, which isn't a good trend.If you wish to eliminate PGDLLIMPORT from the codebase the correct
approach would be building with --export-all-symbols (a MinGW extension
flag to gcc). That would make the MinGW builds consistent with the MSVC
build, which generates a .def file that exports all symbols.As for why PGDLLIMPORT appears to be required in some places on the MSVC
build, so far it's looking like we auto-export functions, but not
necessarily variables.
I could see both the variables (DateStyle and IntervalStyle) currently Tom
points out in both .def file and by using dumpbin utility.
I think these symbols are exported, the main reason of failure is that they
are not imported in postres_fdw as we have not used PGDLLIMPORT.
Looking at below code, as per my understanding for contrib modules
BUILDING_DLL is not defined and by using PGDLLIMPORT, it
can lead to import of the required variables.
#ifdef BUILDING_DLL
#define PGDLLIMPORT __declspec (dllexport)
#else /* not BUILDING_DLL */
#define PGDLLIMPORT __declspec (dllimport)
#endif
We need this for variables, but they are optional for functions. Please refer
below link:
http://msdn.microsoft.com/en-us/library/8fskxacy(v=vs.80).aspx
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sun, Feb 2, 2014 at 6:33 AM, Tom Lane <tgl@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 contrib/postgres_fdw is referencing the DateStyle
and IntervalStyle variables, which aren't marked PGDLLIMPORT.
Hm, well, that would be an easy change ... but that code was committed
last March. How is it that we didn't notice this long ago?What this seems to indicate is that narwhal is the only buildfarm
animal that has a need for PGDLLIMPORT marks on global variables that
are referenced by extensions.
I have tried to debug the part of code where we are using DateStyle and
IntervalStyle variables in postgres_fdw on my m/c
(Win 7 - 64 bit, MSVC2010) and found that there value is junk, to me the
problem looks exactly similar to what we have seen for test_shm_mq
modules few days back. I am not sure why it is passing on other
buildfarm m/c, but I think we need to put PGDLLIMPORT for global
variables we want to use in extensions.
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
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Amit Kapila <amit.kapila16@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 last year (on everything except narwhal) puts the lie to
that as a blanket assumption.
So what I want to know now is how come it wasn't failing; because then
we might be able to exploit that to eliminate the need for the PGDLLIMPORT
cruft everywhere. I've never been a fan of the fact that Windows insists
on its own private set of global symbol visibility rules. If we can make
that build work more like other platforms, it'll be a step forward IMO.
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
On Sun, Feb 2, 2014 at 5:22 PM, Craig Ringer <craig@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 too keen on assuming Microsoft will continue to offer free
toolchains that're usable for our purposes. They're crippling their free
build tools more and more with each release, which isn't a good trend.
I was under the impression that Microsoft had finally come around to
implementing a few C99 features in Visual Studio 2013 precisely
because they want there to be an open source ecosystem on Windows.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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 Windows, 'cos
the 'nix build would break in the same place. That's all or nothing
though, there's no "vars hidden, procs exported" option in gcc.
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 extensions
people have written. Most of those have been authored on *nix.
To make any form of sense we'd need to have a really separate API
layer between internal/external stuff. That doesn't seem likely to
arrive anytime soon, if ever.
I think all that would achieve is that we'd regularly need to backpatch
visibility fixes. And have countless pointless flames about which
variables to expose.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sun, Feb 2, 2014 at 3:59 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Dave Page <dpage@pgadmin.org> writes:
On Sun, Feb 2, 2014 at 1:03 AM, Tom Lane <tgl@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 it's not been
offline for a long time (aside from a couple of weeks in January) -
it's been happily building most pre-9.2 branches for ages. 9.1 seems
to be stuck, along with HEAD, and I forgot to add 9.3. I'm in the
process of cleaning that up as time allows, but am happy to drop it
instead if we no longer want to support anything that old. We
certainly don't use anything resembling that config for the EDB
installer builds.Further discussion pointed out that currawong, for example, seems to
want PGDLLIMPORT markings but is able to get by without them in
some cases that narwhal evidently doesn't like. So at this point,
desupporting narwhal's configuration is clearly premature --- we
should instead be looking into exactly what is causing the different
cases to fail or not fail.I still have hopes that we might be able to get rid of PGDLLIMPORT
marks, but by actually understanding why they seem to be needed in
some cases and not others, not by just arbitrarily dropping support.In the meantime, please do get HEAD running again on that machine.
Done: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=narwhal&dt=2014-02-03%2009%3A26%3A43
It's not happy though :-(
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Feb 3, 2014 at 5:45 AM, Dave Page <dpage@pgadmin.org> wrote:
Done: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=narwhal&dt=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
dllwrap -o pg_buffercache.dll --dllname pg_buffercache.dll --def
libpg_buffercachedll.def pg_buffercache_pages.o -L../../src/port
-L../../src/common -Wl,--allow-multiple-definition -L/mingw/lib
-Wl,--as-needed -L../../src/backend -lpostgres
Info: resolving _MainLWLockArray by linking to __imp__MainLWLockArray
(auto-import)
fu000001.o(.idata$3+0xc): undefined reference to `libpostgres_a_iname'
fu000002.o(.idata$3+0xc): undefined reference to `libpostgres_a_iname'
nmth000000.o(.idata$4+0x0): undefined reference to `_nm__MainLWLockArray'
I assume I should go stick a DLLIMPORT on MainLWLockArray, unless
somebody has another proposal.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas <robertmhaas@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.
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
