Complier warnings on mingw gcc 4.5.0
I compiled the source with mingw gcc 4.5.0, that has been released recently.
The compile was succeeded and worked well at least for simple queries,
but there were many warnings during the compile.
----
1. warning: '<symbol>' redeclared without dllimport attribute:
previous dllimport ignored
2. warning: unknown conversion type character 'm' in format
3. warning: unknown conversion type character 'l' in format
----
1 is easy to fix with the attached patch.
I wonder why mingw gcc < 4.5 can build codes without the fix...
For 2, we could remove __attribute__((format(printf))) on mingw, but
it also disables type checking for formatters. Are there better solutions?
I have not yet researched for 3, that might be most dangerous.
=# select version();
version
----------------------------------------------------------------------------------
PostgreSQL 9.0.1 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC)
4.5.0, 32-bit
(1 row)
OS: Windows 7 64bit
diff --git a/src/include/port/win32.h b/src/include/port/win32.h
index 988c1c9..31c877f 100644
*** a/src/include/port/win32.h
--- b/src/include/port/win32.h
***************
*** 58,64 ****
#define PGDLLIMPORT __declspec (dllimport)
#endif! #ifdef _MSC_VER
#define PGDLLEXPORT __declspec (dllexport)
#else
#define PGDLLEXPORT __declspec (dllimport)
--- 58,64 ----
#define PGDLLIMPORT __declspec (dllimport)
#endif! #if defined(_MSC_VER) || __GNUC__ >= 4
#define PGDLLEXPORT __declspec (dllexport)
#else
#define PGDLLEXPORT __declspec (dllimport)
--
Itagaki Takahiro
(2010/11/01 19:24), Itagaki Takahiro wrote:
I compiled the source with mingw gcc 4.5.0, that has been released recently.
The compile was succeeded and worked well at least for simple queries,
but there were many warnings during the compile.
----
1. warning: '<symbol>' redeclared without dllimport attribute:
previous dllimport ignored
2. warning: unknown conversion type character 'm' in format
3. warning: unknown conversion type character 'l' in format
----1 is easy to fix with the attached patch.
Is it safe to put back the patch you applied in
http://archives.postgresql.org/pgsql-committers/2010-05/msg00338.php
in the case __GNUC__ >=4?
regards,
Hiroshi Inoue
Show quoted text
I wonder why mingw gcc< 4.5 can build codes without the fix...
*** a/src/include/port/win32.h --- b/src/include/port/win32.h *************** *** 58,64 **** #define PGDLLIMPORT __declspec (dllimport) #endWindows 7 64bitdiff --git a/src/include/port/win32.h b/src/include/port/win32.h indexif! #ifdef _MSC_VER #define PGDLLEXPORT __declspec (dllexport) #else #define PGDLLEXPORT __declspec (dllimport) --- 58,64 ---- #define PGDLLIMPORT __declspec (dllimport) #endif! #if defined(_MSC_VER) || __GNUC__>= 4
#define PGDLLEXPORT __declspec (dllexport)
#else
#define PGDLLEXPORT __declspec (dllimport)
On Tue, Nov 2, 2010 at 6:02 AM, Hiroshi Inoue <inoue@tpf.co.jp> wrote:
1. warning: '<symbol>' redeclared without dllimport attribute:
previous dllimport ignoredIs it safe to put back the patch you applied in
http://archives.postgresql.org/pgsql-committers/2010-05/msg00338.php
in the case __GNUC__ >=4?
Hmmm, I didn't test compiling with gcc version between 3.5 and 4.4.
Does anyone test them? If it works only on gcc 4.5, I'll also add
_GNUC_MINOR__ >= 5 for the check.
--
Itagaki Takahiro
(2010/11/02 8:31), Itagaki Takahiro wrote:
On Tue, Nov 2, 2010 at 6:02 AM, Hiroshi Inoue<inoue@tpf.co.jp> wrote:
1. warning: '<symbol>' redeclared without dllimport attribute:
previous dllimport ignoredIs it safe to put back the patch you applied in
http://archives.postgresql.org/pgsql-committers/2010-05/msg00338.php
in the case __GNUC__>=4?Hmmm, I didn't test compiling with gcc version between 3.5 and 4.4.
Does anyone test them? If it works only on gcc 4.5, I'll also add
_GNUC_MINOR__>= 5 for the check.
The problem which was fixed by your old patch is at runtime not
at compilation time. Is it fixed with gcc 4.5?
regards,
Hiroshi Inoue
On Tue, Nov 2, 2010 at 8:43 AM, Hiroshi Inoue <inoue@tpf.co.jp> wrote:
The problem which was fixed by your old patch is at runtime not
at compilation time. Is it fixed with gcc 4.5?
Now it works as far as simple test, including core functions and
dynamic modules. So, I think the fix for dllexport is safe enough
for mingw gcc 4.5.
BTW, with out without the above fix, regression test failed with
weird error if the server is built with gcc 4.5. However, server
can run if I started it manually with PGPORT or -o "--port=X".
We might need another fix for the issue.
----
LOG: database system was shut down at 2010-11-02 10:32:13 JST
LOG: database system is ready to accept connections
LOG: autovacuum launcher started
FATAL: parameter "port" cannot be changed without restarting the server
(repeated)
----
--
Itagaki Takahiro
On Mon, Nov 1, 2010 at 7:24 PM, Itagaki Takahiro
<itagaki.takahiro@gmail.com> wrote:
1. warning: '<symbol>' redeclared without dllimport attribute:
previous dllimport ignored
I discussed with Hiroshi-san about the dllimport issue, and he pointed
out that __declspec(dllexport) and dllwrap cannot work well together.
So, the most suitable fix would be just removing __declspec (dllimport)
from PGDLLEXPORT for mingw.
diff --git a/src/include/port/win32.h b/src/include/port/win32.h
index 988c1c9..3417ab5 100644
*** a/src/include/port/win32.h
--- b/src/include/port/win32.h
***************
*** 61,67 ****
#ifdef _MSC_VER
#define PGDLLEXPORT __declspec (dllexport)
#else
! #define PGDLLEXPORT __declspec (dllimport)
#endif
#else /* not CYGWIN, not MSVC, not MingW */
#define PGDLLIMPORT
--- 61,67 ----
#ifdef _MSC_VER
#define PGDLLEXPORT __declspec (dllexport)
#else
! #define PGDLLEXPORT
#endif
#else /* not CYGWIN, not MSVC, not MingW */
#define PGDLLIMPORT--
Itagaki Takahiro
On 11/01/2010 10:10 PM, Itagaki Takahiro wrote:
On Tue, Nov 2, 2010 at 8:43 AM, Hiroshi Inoue<inoue@tpf.co.jp> wrote:
The problem which was fixed by your old patch is at runtime not
at compilation time. Is it fixed with gcc 4.5?Now it works as far as simple test, including core functions and
dynamic modules. So, I think the fix for dllexport is safe enough
for mingw gcc 4.5.BTW, with out without the above fix, regression test failed with
weird error if the server is built with gcc 4.5. However, server
can run if I started it manually with PGPORT or -o "--port=X".
We might need another fix for the issue.
----
LOG: database system was shut down at 2010-11-02 10:32:13 JST
LOG: database system is ready to accept connections
LOG: autovacuum launcher started
FATAL: parameter "port" cannot be changed without restarting the server
(repeated)
----
I have just run into this when trying to set up a new buildfarm member
running Mingw. Is there a fix? Is anyone working on it? Or do I just
need to downgrade the compiler?
cheers
andrew
Andrew Dunstan <andrew@dunslane.net> writes:
On 11/01/2010 10:10 PM, Itagaki Takahiro wrote:
BTW, with out without the above fix, regression test failed with
weird error if the server is built with gcc 4.5. However, server
can run if I started it manually with PGPORT or -o "--port=X".
We might need another fix for the issue.
----
LOG: database system was shut down at 2010-11-02 10:32:13 JST
LOG: database system is ready to accept connections
LOG: autovacuum launcher started
FATAL: parameter "port" cannot be changed without restarting the server
(repeated)
I have just run into this when trying to set up a new buildfarm member
running Mingw. Is there a fix? Is anyone working on it? Or do I just
need to downgrade the compiler?
It smells a little bit like an optimization bug. Does dialing down to
-O0 make it go away?
regards, tom lane
On 12/13/2010 12:01 PM, Tom Lane wrote:
Andrew Dunstan<andrew@dunslane.net> writes:
On 11/01/2010 10:10 PM, Itagaki Takahiro wrote:
BTW, with out without the above fix, regression test failed with
weird error if the server is built with gcc 4.5. However, server
can run if I started it manually with PGPORT or -o "--port=X".
We might need another fix for the issue.
----
LOG: database system was shut down at 2010-11-02 10:32:13 JST
LOG: database system is ready to accept connections
LOG: autovacuum launcher started
FATAL: parameter "port" cannot be changed without restarting the server
(repeated)I have just run into this when trying to set up a new buildfarm member
running Mingw. Is there a fix? Is anyone working on it? Or do I just
need to downgrade the compiler?It smells a little bit like an optimization bug. Does dialing down to
-O0 make it go away?
Sadly, no. I'm testing downgrading the compiler now.
cheers
andrew
Andrew Dunstan <andrew@dunslane.net> writes:
On 12/13/2010 12:01 PM, Tom Lane wrote:
It smells a little bit like an optimization bug. Does dialing down to
-O0 make it go away?
Sadly, no. I'm testing downgrading the compiler now.
Mph. FWIW, I see that my last build of Postgres for Fedora 14 would
have been with gcc 4.5.1, because that's what F14 is shipping. And
that passed its regression tests on at least x86 and x86_64. Maybe
you should pester the mingw folk for a compiler update.
regards, tom lane
On 12/13/2010 01:12 PM, Tom Lane wrote:
Andrew Dunstan<andrew@dunslane.net> writes:
On 12/13/2010 12:01 PM, Tom Lane wrote:
It smells a little bit like an optimization bug. Does dialing down to
-O0 make it go away?Sadly, no. I'm testing downgrading the compiler now.
Mph. FWIW, I see that my last build of Postgres for Fedora 14 would
have been with gcc 4.5.1, because that's what F14 is shipping. And
that passed its regression tests on at least x86 and x86_64. Maybe
you should pester the mingw folk for a compiler update.
Further digging shows some weirdness. This doesn't appear to be
compiler-related. I've rolled back all the way to gcc 3.5. It is
triggered by the following line in pg_regress.c, commenting out of which
causes the problem to go away (although of course it causes the
regression tests to fail):
putenv(new_pgoptions);
cheers
andrew
On Mon, Dec 13, 2010 at 22:29, Andrew Dunstan <andrew@dunslane.net> wrote:
On 12/13/2010 01:12 PM, Tom Lane wrote:
Andrew Dunstan<andrew@dunslane.net> writes:
On 12/13/2010 12:01 PM, Tom Lane wrote:
It smells a little bit like an optimization bug. Does dialing down to
-O0 make it go away?Sadly, no. I'm testing downgrading the compiler now.
Mph. FWIW, I see that my last build of Postgres for Fedora 14 would
have been with gcc 4.5.1, because that's what F14 is shipping. And
that passed its regression tests on at least x86 and x86_64. Maybe
you should pester the mingw folk for a compiler update.Further digging shows some weirdness. This doesn't appear to be
compiler-related. I've rolled back all the way to gcc 3.5. It is triggered
by the following line in pg_regress.c, commenting out of which causes the
problem to go away (although of course it causes the regression tests to
fail):putenv(new_pgoptions);
Take a look at 741e4ad7de9e0069533d90efdd5b1fc9f3a64c81.
If you enable that codepath to run on mingw, does it fix it? (it's
msvc only now)
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Andrew Dunstan <andrew@dunslane.net> writes:
Further digging shows some weirdness. This doesn't appear to be
compiler-related. I've rolled back all the way to gcc 3.5. It is
triggered by the following line in pg_regress.c, commenting out of which
causes the problem to go away (although of course it causes the
regression tests to fail):
putenv(new_pgoptions);
Oh really ... are we using src/port/unsetenv.c on that platform?
I wonder if that little hack is incompatible with latest mingw
libraries ...
regards, tom lane
On 12/13/2010 04:34 PM, Tom Lane wrote:
Andrew Dunstan<andrew@dunslane.net> writes:
Further digging shows some weirdness. This doesn't appear to be
compiler-related. I've rolled back all the way to gcc 3.5. It is
triggered by the following line in pg_regress.c, commenting out of which
causes the problem to go away (although of course it causes the
regression tests to fail):
putenv(new_pgoptions);Oh really ... are we using src/port/unsetenv.c on that platform?
I wonder if that little hack is incompatible with latest mingw
libraries ...
It is using pgwin32_putenv() and pgwin32_unsetenv(). It appears not to
be related to how the environment is set at all, but to how the backend
is handling PGOPTIONS.
Here's a TCP level dump of traffic showing the problem. The client is on
Linux.
18:34:03.106882 IP aurelia.34700 > 192.168.10.109.postgres: Flags [P.],
seq 9:86, ack 2, win 46, options [nop,nop,TS val 1504831233 ecr
1085898], length 77
0x0000: 4500 0081 f95d 4000 4006 aaf3 c0a8 0a68 E....]@.@......h
0x0010: c0a8 0a6d 878c 1538 a55b 18ce c920 b723 ...m...8.[.....#
0x0020: 8018 002e 07ae 0000 0101 080a 59b1 e701 ............Y...
0x0030: 0010 91ca 0000 004d 0003 0000 7573 6572 .......M....user
0x0040: 0070 6772 756e 6e65 7200 6461 7461 6261 .pgrunner.databa
0x0050: 7365 0070 6f73 7467 7265 7300 6f70 7469 se.postgres.opti
0x0060: 6f6e 7300 2d63 206c 6f67 5f6d 696e 5f6d ons.-c.log_min_m
0x0070: 6573 7361 6765 733d 7761 726e 696e 6700 essages=warning.
0x0080: 00 .
18:34:03.209847 IP 192.168.10.109.postgres > aurelia.34700: Flags [P.],
seq 2:129, ack 86, win 65450, options [nop,nop,TS val 1085900 ecr
1504831233], length 127
0x0000: 4500 00b3 9fd3 4000 8006 c44b c0a8 0a6d E.....@....K...m
0x0010: c0a8 0a68 1538 878c c920 b723 a55b 191b ...h.8.....#.[..
0x0020: 8018 ffaa df54 0000 0101 080a 0010 91cc .....T..........
0x0030: 59b1 e701 5200 0000 0800 0000 0045 0000 Y...R........E..
0x0040: 0075 5346 4154 414c 0043 3535 5030 3200 .uSFATAL.C55P02.
0x0050: 4d70 6172 616d 6574 6572 2022 706f 7274 Mparameter."port
0x0060: 2220 6361 6e6e 6f74 2062 6520 6368 616e ".cannot.be.chan
0x0070: 6765 6420 7769 7468 6f75 7420 7265 7374 ged.without.rest
0x0080: 6172 7469 6e67 2074 6865 2073 6572 7665 arting.the.serve
0x0090: 7200 4667 7563 2e63 004c 3437 3934 0052 r.Fguc.c.L4794.R
0x00a0: 7365 745f 636f 6e66 6967 5f6f 7074 696f set_config_optio
0x00b0: 6e00 00 n..
cheers
andrew
On 12/13/2010 06:45 PM, I wrote:
[ problem on Mingw with 'FATAL: parameter "port" cannot be changed
without restarting the server' if client connection options are sent ]
It appears not to be related to how the environment is set at all, but
to how the backend is handling PGOPTIONS.
Regina Obe has pointed out to me, and I have confirmed, that this does
not happen with REL8_4_STABLE. So either we have introduced a bug since
then or something we have done since then has tickled a Mingw bug.
cheers
andrew
Andrew Dunstan <andrew@dunslane.net> writes:
On 12/13/2010 06:45 PM, I wrote:
[ problem on Mingw with 'FATAL: parameter "port" cannot be changed
without restarting the server' if client connection options are sent ]
Regina Obe has pointed out to me, and I have confirmed, that this does
not happen with REL8_4_STABLE. So either we have introduced a bug since
then or something we have done since then has tickled a Mingw bug.
Hm. Does it happen in 9.0, or just HEAD?
regards, tom lane
On 12/14/2010 12:10 PM, Tom Lane wrote:
Andrew Dunstan<andrew@dunslane.net> writes:
On 12/13/2010 06:45 PM, I wrote:
[ problem on Mingw with 'FATAL: parameter "port" cannot be changed
without restarting the server' if client connection options are sent ]Regina Obe has pointed out to me, and I have confirmed, that this does
not happen with REL8_4_STABLE. So either we have introduced a bug since
then or something we have done since then has tickled a Mingw bug.Hm. Does it happen in 9.0, or just HEAD?
Yes, it happens on 9.0. I guess I need to start some git triangulation.
cheers
andrew
Andrew Dunstan <andrew@dunslane.net> writes:
On 12/13/2010 04:34 PM, Tom Lane wrote:
Oh really ... are we using src/port/unsetenv.c on that platform?
I wonder if that little hack is incompatible with latest mingw
libraries ...
It is using pgwin32_putenv() and pgwin32_unsetenv(). It appears not to
be related to how the environment is set at all, but to how the backend
is handling PGOPTIONS.
Mmm, right. Even if that was messed up, it could only manifest as
pg_regress shipping a bogus connection request packet. But speaking of
which ...
Here's a TCP level dump of traffic showing the problem. The client is on
Linux.
18:34:03.106882 IP aurelia.34700 > 192.168.10.109.postgres: Flags [P.],
seq 9:86, ack 2, win 46, options [nop,nop,TS val 1504831233 ecr
1085898], length 77
0x0000: 4500 0081 f95d 4000 4006 aaf3 c0a8 0a68 E....]@.@......h
0x0010: c0a8 0a6d 878c 1538 a55b 18ce c920 b723 ...m...8.[.....#
0x0020: 8018 002e 07ae 0000 0101 080a 59b1 e701 ............Y...
0x0030: 0010 91ca 0000 004d 0003 0000 7573 6572 .......M....user
0x0040: 0070 6772 756e 6e65 7200 6461 7461 6261 .pgrunner.databa
0x0050: 7365 0070 6f73 7467 7265 7300 6f70 7469 se.postgres.opti
0x0060: 6f6e 7300 2d63 206c 6f67 5f6d 696e 5f6d ons.-c.log_min_m
0x0070: 6573 7361 6765 733d 7761 726e 696e 6700 essages=warning.
0x0080: 00 .
This seems quite odd now that I look at it. The packet contents imply
that libpq saw PGOPTIONS="-c log_min_messages=warning" and no other
environment variables that would cause it to append stuff to the
connection request. Which is not at all how pg_regress ought to behave,
even assuming that the buildfarm script sets up PGOPTIONS that way.
I'd expect to see settings for timezone, datestyle, and intervalstyle
in there. What was the client here exactly?
Another line of attack is that we know from the response packet that the
failure is being reported at guc.c:4794. It would be really useful to
know what the call stack is there. Could you change that elog to an
elog(PANIC) and get a stack trace from the ensuing core dump?
regards, tom lane
On 12/14/2010 12:42 PM, Tom Lane wrote:
This seems quite odd now that I look at it. The packet contents imply
that libpq saw PGOPTIONS="-c log_min_messages=warning" and no other
environment variables that would cause it to append stuff to the
connection request. Which is not at all how pg_regress ought to behave,
even assuming that the buildfarm script sets up PGOPTIONS that way.
I'd expect to see settings for timezone, datestyle, and intervalstyle
in there. What was the client here exactly?
Maybe I didn't explain this properly. The trace was not from pg_regress.
It was from a connection from a standard Linux psql client.
Another line of attack is that we know from the response packet that the
failure is being reported at guc.c:4794. It would be really useful to
know what the call stack is there. Could you change that elog to an
elog(PANIC) and get a stack trace from the ensuing core dump?
I can try that. Not sure how easy that is on Windows.
cheers
andrew
On 12/14/2010 12:42 PM, Tom Lane wrote:
Another line of attack is that we know from the response packet that the
failure is being reported at guc.c:4794. It would be really useful to
know what the call stack is there. Could you change that elog to an
elog(PANIC) and get a stack trace from the ensuing core dump?
That didn't work. But git bisect says it's this commit that's to blame:
<https://github.com/postgres/postgres/commit/e710b65c1c56ca7b91f662c63d37ff2e72862a94>
It's too late to dig further now.
cheers
andrew
