| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
| Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, Hiroshi Inoue <inoue(at)tpf(dot)co(dot)jp>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Complier warnings on mingw gcc 4.5.0 |
| Date: | 2010-12-15 16:12:17 |
| Message-ID: | 6849.1292429537@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> 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 getopt(), in particular the arrangements to cause getopt
to behave sanely when we invoke it on a different argc array the second
time around. If that were failing for some reason, you could imagine
getopt seeing 'postgres' as the next switch to parse, which could lead
to the reported failure.
Hence:
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?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2010-12-15 16:17:02 | Re: CommitFest wrap-up |
| Previous Message | Florian Pflug | 2010-12-15 16:07:24 | Re: hstores in pl/python |