Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

Andrew Dunstan writes: > It's working, but I don't think it's right :-) In particular, I don't > believe this, or rather I don't believe that its converse is false: > /* If not HAVE_GETOPT, we are using src/port/getopt.c, which has > optreset */ Yeah, that was a 90% solution. I had fir

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

On 12/15/2010 11:53 PM, Tom Lane wrote: OK, patch committed so we can get testing from the existing buildfarm members, but please try on your new installation too. It's working, but I don't think it's right :-) In particular, I don't believe this, or rather I don't

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

Andrew Dunstan writes: > On 12/15/2010 08:46 PM, Tom Lane wrote: >> We can't change the meaning of HAVE_INT_OPTRESET because that would >> break the declaration logic in getopt.c. I'm thinking we have to >> complicate the #if logic in postmaster.c and postgres.c. > I agree. >> Will look >> into

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

On 12/15/2010 08:46 PM, Tom Lane wrote: I believe #2 is in fact necessary. When I tried just #1 before it failed. What's the best way to do #2 cleanly? We can't change the meaning of HAVE_INT_OPTRESET because that would break the declaration logic in getopt.c. I'm thinking we have to compli

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

Andrew Dunstan writes: > On 12/15/2010 07:24 PM, Tom Lane wrote: >> Should we backpatch either of these things? > Yes. We need it to back at least to 9.0. On reflection I think we probably better fix it back to 8.2, since we're supposedly supporting Windows on all those branches, and somebody mi

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

On 12/15/2010 07:24 PM, Tom Lane wrote: Huh, I wonder why it doesn't match what's in sourceforge CVS? Sourceforge's CVS is way out of date. CVS tip for the getopt.h is here:

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

On 12/15/2010 07:24 PM, Tom Lane wrote: So I concur with the previous suggestions: 1. Make this problem go away by forcing use of our getopt code on mingw. 2. Make sure we reset optreset when using our code. (Probably not really necessary, but let's just be careful.) Should we backpatch ei

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

Andrew Dunstan writes: > On 12/15/2010 06:42 PM, Tom Lane wrote: >> Hm, where did you get this? > I downloaded > > > which is allegedly the source for the l

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

On 12/15/2010 06:42 PM, Tom Lane wrote: Andrew Dunstan writes: Mingw code attached. Hm, where did you get this? Because it does have optreset, albeit in a gratuitously ABI-incompatible fashion: #ifdef _BSD_SOURCE /* * BSD adds the non-standard `optreset' feature, for reinitialisation

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

Andrew Dunstan writes: > Mingw code attached. Hm, where did you get this? Because it does have optreset, albeit in a gratuitously ABI-incompatible fashion: > #ifdef _BSD_SOURCE > /* > * BSD adds the non-standard `optreset' feature, for reinitialisation > * of `getopt' parsing. We support thi

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

On 12/15/2010 04:26 PM, Tom Lane wrote: Anyway seems like the next step is to compare the Fedora getopt code with mingw's ... Mingw code attached. cheers andrew #ifndef __GETOPT_H__ /* * getopt.h * * $Id: getopt.h,v 1.4 2009/01/04 17:35:36 keithmarshall Exp $

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

Andrew Dunstan writes: > On my Fedora box, man 3 getopt says this: > A program that scans multiple argument vectors, or rescans the same > vector more than once, and wants to make use of GNU extensions such > as '+' and '-' at the start of optstring, or changes the value of > P

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

On 12/15/2010 03:52 PM, Tom Lane wrote: Andrew Dunstan writes: And here is where it changed: * A replacement implementation for the getopt() family of functions, adding support for the GNU getopt_long_only() function

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

Andrew Dunstan writes: > And here is where it changed: > > * A replacement implementation for the getopt() family of functions, >adding support for the GNU getopt_long_only() function. Users >should note that th

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

On 12/15/2010 02:22 PM, Andrew Dunstan wrote: On 12/15/2010 02:06 PM, Tom Lane wrote: Andrew Dunstan writes: And the attached hack allowed "make check" to succeed. I think the logic in tcop/postgres.c and postmaster/postmaster.c is probably wrong. If we are using our getopt/getopt_long, we

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

On 12/15/2010 02:06 PM, Tom Lane wrote: Andrew Dunstan writes: And the attached hack allowed "make check" to succeed. I think the logic in tcop/postgres.c and postmaster/postmaster.c is probably wrong. If we are using our getopt/getopt_long, we want to be setting optreset, whether or not conf

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

Andrew Dunstan writes: > And the attached hack allowed "make check" to succeed. > I think the logic in tcop/postgres.c and postmaster/postmaster.c is > probably wrong. If we are using our getopt/getopt_long, we want to be > setting optreset, whether or not configure found one in the system > l

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

On 12/15/2010 12:28 PM, Andrew Dunstan wrote: I think you're probably right. narwhal reports having optreset, but my Mingw reports not having it, so this looks like a likely culprit. And the attached hack allowed "make check" to succeed. I think the logic in tcop/postgres.c and postmast

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

On 12/15/2010 11:49 AM, Tom Lane wrote: Magnus Hagander writes: On Wed, Dec 15, 2010 at 17:43, Tom Lane wrote: Do we use configure at all on a mingw build? If we don't, then HAVE_INT_OPTRESET is surely not getting defined. We do use configure on mingw. The output from a regular mingw conf

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

Magnus Hagander writes: > On Wed, Dec 15, 2010 at 17:43, Tom Lane wrote: >> Do we use configure at all on a mingw build?  If we don't, then >> HAVE_INT_OPTRESET is surely not getting defined. > We do use configure on mingw. The output from a regular mingw > configure run formed the base for the

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

On Wed, Dec 15, 2010 at 17:43, Tom Lane wrote: > Andrew Dunstan writes: >> On 12/15/2010 11:12 AM, Tom Lane wrote: >>> 1. Is that build using src/port/getopt.c, or a library-supplied getopt? >>> What about getopt_long.c? >>> >>> 2. Is HAVE_INT_OPTRESET getting defined?  Should it be? > >> I had t

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

Andrew Dunstan writes: > On 12/15/2010 11:12 AM, Tom Lane wrote: >> 1. Is that build using src/port/getopt.c, or a library-supplied getopt? >> What about getopt_long.c? >> >> 2. Is HAVE_INT_OPTRESET getting defined? Should it be? > I had the same thought. I did try forcing use of our getopt and

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

On 12/15/2010 11:12 AM, Tom Lane wrote: Alvaro Herrera writes: This bug seems closely related to process_postgres_switches. I guess it'd be useful to add some debugging printouts there to figure out what's being passed the second time around. It strikes me that the most obvious source for a

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

Alvaro Herrera writes: > This bug seems closely related to process_postgres_switches. I guess > it'd be useful to add some debugging printouts there to figure out > what's being passed the second time around. It strikes me that the most obvious source for a platform dependency there would be get

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

On 12/15/2010 10:17 AM, Tom Lane wrote: Alvaro Herrera writes: Excerpts from Andrew Dunstan's message of mié dic 15 02:08:24 -0300 2010: That didn't work. But git bisect says it's this commit that's to blame:

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

Alvaro Herrera writes: > Excerpts from Andrew Dunstan's message of mié dic 15 02:08:24 -0300 2010: >> That didn't work. But git bisect says it's this commit that's to blame: >> > Hmm I wonder if this is reprod

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

Excerpts from Andrew Dunstan's message of mié dic 15 02:08:24 -0300 2010: > > 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 st

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

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 th

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

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_reg

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

Andrew Dunstan 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 re

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

On 12/14/2010 12:10 PM, Tom Lane wrote: Andrew Dunstan 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, t

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

Andrew Dunstan 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

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

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.

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

On 12/13/2010 04:34 PM, Tom Lane wrote: Andrew Dunstan 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 awa

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

Andrew Dunstan 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 th

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

On Mon, Dec 13, 2010 at 22:29, Andrew Dunstan wrote: > > > On 12/13/2010 01:12 PM, Tom Lane wrote: >> >> Andrew Dunstan  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,

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

On 12/13/2010 01:12 PM, Tom Lane wrote: Andrew Dunstan 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 Po

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

Andrew Dunstan 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

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

On 12/13/2010 12:01 PM, Tom Lane wrote: Andrew Dunstan 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

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

Andrew Dunstan 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 anothe

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

On 11/01/2010 10:10 PM, Itagaki Takahiro wrote: On Tue, Nov 2, 2010 at 8:43 AM, Hiroshi Inoue 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

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

On Mon, Nov 1, 2010 at 7:24 PM, Itagaki Takahiro wrote: > 1. warning: '' 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 s

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

On Tue, Nov 2, 2010 at 8:43 AM, Hiroshi Inoue 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 enoug

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

(2010/11/02 8:31), Itagaki Takahiro wrote: On Tue, Nov 2, 2010 at 6:02 AM, Hiroshi Inoue wrote: 1. warning: '' redeclared without dllimport attribute: previous dllimport ignored Is it safe to put back the patch you applied in http://archives.postgresql.org/pgsql-committers/2010-05/msg00338.ph

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

On Tue, Nov 2, 2010 at 6:02 AM, Hiroshi Inoue wrote: >> 1. warning: '' redeclared without dllimport attribute: >> previous dllimport ignored > > 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? Hmmm,

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

(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: '' redeclared without dllimport attribu