On 07/08/2015 08:50 PM, Tom Lane wrote:
Heikki Linnakangas writes:
The only scenario where you might now get warnings if we switch to
upstream version, and didn't before, is if one of the flags makes
pthreads to work, but also creates compiler warnings, while another flag
later in the list woul
Heikki Linnakangas writes:
> The only scenario where you might now get warnings if we switch to
> upstream version, and didn't before, is if one of the flags makes
> pthreads to work, but also creates compiler warnings, while another flag
> later in the list would make it work without warnings.
On 07/08/2015 04:38 PM, Tom Lane wrote:
Heikki Linnakangas writes:
I suggest that we revert that work-around for that GCC bug, and stop
testing the pthread flags as soon as we find one that works.
OK ...
Then we can
also remove the test for whether the compiler produces any warnings.
Don'
Heikki Linnakangas writes:
> I suggest that we revert that work-around for that GCC bug, and stop
> testing the pthread flags as soon as we find one that works.
OK ...
> Then we can
> also remove the test for whether the compiler produces any warnings.
Don't see how that follows?
> AFAICS,
On 03/21/2015 01:06 AM, Max Filippov wrote:
On Fri, Mar 20, 2015 at 3:43 PM, Max Filippov wrote:
Ok, one more attempt: maybe instead of checking that stderr is empty
we could check that stderr has changed in the presence of the option
that we test?
The patch:
http://www.postgresql.org/message
On Thu, Apr 30, 2015 at 3:51 PM, Robert Haas wrote:
> On Wed, Apr 8, 2015 at 2:31 AM, Max Filippov wrote:
>> On Sat, Mar 21, 2015 at 2:06 AM, Max Filippov wrote:
>>> On Fri, Mar 20, 2015 at 3:43 PM, Max Filippov wrote:
Ok, one more attempt: maybe instead of checking that stderr is empty
>>
On Wed, Apr 8, 2015 at 2:31 AM, Max Filippov wrote:
> On Sat, Mar 21, 2015 at 2:06 AM, Max Filippov wrote:
>> On Fri, Mar 20, 2015 at 3:43 PM, Max Filippov wrote:
>>> Ok, one more attempt: maybe instead of checking that stderr is empty
>>> we could check that stderr has changed in the presence o
On Sat, Mar 21, 2015 at 2:06 AM, Max Filippov wrote:
> On Fri, Mar 20, 2015 at 3:43 PM, Max Filippov wrote:
>> Ok, one more attempt: maybe instead of checking that stderr is empty
>> we could check that stderr has changed in the presence of the option
>> that we test?
>
> The patch:
> http://www.
On Fri, Mar 20, 2015 at 3:43 PM, Max Filippov wrote:
> Ok, one more attempt: maybe instead of checking that stderr is empty
> we could check that stderr has changed in the presence of the option
> that we test?
The patch:
http://www.postgresql.org/message-id/1426860321-13586-1-git-send-email-jcmv
On Fri, Mar 20, 2015 at 2:51 PM, Andrew Gierth
wrote:
>> "Robert" == Robert Haas writes:
> >> Then maybe stderr tests should grep output for a specific option,
> >> the one we're currently testing, not just any noise?
>
> Robert> That sounds awfully fragile to me. It can't really be safe
> "Robert" == Robert Haas writes:
>> Then maybe stderr tests should grep output for a specific option,
>> the one we're currently testing, not just any noise?
Robert> That sounds awfully fragile to me. It can't really be safe to
Robert> assume we know precisely what the warning messages
By the way, acx-pthread.m4 has an outdated link to upstream
acx_pthread.m4. The correct link is
http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=history;f=m4/ax_pthread.m4
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA,
Andres Freund wrote:
> On 2015-03-20 10:23:51 -0300, Alvaro Herrera wrote:
> > Andres Freund wrote:
> > > FWIW, I think emitting such errors at link time is utterly pointless and
> > > rather annoying. I can see a point of emitting them them when compiling
> > > code that uses deprecated functions.
On 2015-03-20 10:23:51 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
> > FWIW, I think emitting such errors at link time is utterly pointless and
> > rather annoying. I can see a point of emitting them them when compiling
> > code that uses deprecated functions. But we quite obviously can't d
Andres Freund wrote:
> Hi,
>
> On 2015-03-20 03:14:48 +0300, Max Filippov wrote:
> > and the toolchain emits the following warning at linking step:
> >
> > libcrypto.so: warning: gethostbyname is obsolescent, use
> > getnameinfo() instead.
>
> FWIW, I think emitting such errors at link time is
Hi,
On 2015-03-20 03:14:48 +0300, Max Filippov wrote:
> and the toolchain emits the following warning at linking step:
>
> libcrypto.so: warning: gethostbyname is obsolescent, use
> getnameinfo() instead.
FWIW, I think emitting such errors at link time is utterly pointless and
rather annoying.
On Fri, Mar 20, 2015 at 3:05 PM, Robert Haas wrote:
> On Fri, Mar 20, 2015 at 7:01 AM, Max Filippov wrote:
>> On Fri, Mar 20, 2015 at 6:08 AM, Tom Lane wrote:
>>> We don't want every link step producing a useless warning.
>>> Ideally, "make -s" would print nothing whatsoever; to the extent that
On Fri, Mar 20, 2015 at 08:05:48AM -0400, Robert Haas wrote:
> On Fri, Mar 20, 2015 at 7:01 AM, Max Filippov wrote:
> > On Fri, Mar 20, 2015 at 6:08 AM, Tom Lane wrote:
> >> We don't want every link step producing a useless warning.
> >> Ideally, "make -s" would print nothing whatsoever; to the e
On Fri, Mar 20, 2015 at 7:01 AM, Max Filippov wrote:
> On Fri, Mar 20, 2015 at 6:08 AM, Tom Lane wrote:
>> We don't want every link step producing a useless warning.
>> Ideally, "make -s" would print nothing whatsoever; to the extent that
>> tools produce unsuppressable routine chatter, that's ev
On Fri, Mar 20, 2015 at 6:08 AM, Tom Lane wrote:
> We don't want every link step producing a useless warning.
> Ideally, "make -s" would print nothing whatsoever; to the extent that
> tools produce unsuppressable routine chatter, that's evil because it
> makes it harder to notice actually-useful w
On Fri, Mar 20, 2015 at 5:20 AM, Andrew Gierth
wrote:
>> "Max" == Max Filippov writes:
>
> Max> Sorry, I must be not clear enough: why checking compiler/linker
> Max> output instead of checking their exit code or presence of produced
> Max> object/ executable files?
>
> Going by the commen
Andrew Gierth writes:
> "Max" == Max Filippov writes:
> Max> Sorry, I must be not clear enough: why checking compiler/linker
> Max> output instead of checking their exit code or presence of produced
> Max> object/ executable files?
> Going by the comment some lines above, my guess would be "b
On Fri, Mar 20, 2015 at 05:15:51AM +0300, Max Filippov wrote:
> On Fri, Mar 20, 2015 at 5:09 AM, Bruce Momjian wrote:
> > On Fri, Mar 20, 2015 at 04:51:55AM +0300, Max Filippov wrote:
> >> xtensa-linux-gcc -o conftest -Wall -Wmissing-prototypes
> >> -Wpointer-arith -Wdeclaration-after-statement -W
> "Max" == Max Filippov writes:
Max> Sorry, I must be not clear enough: why checking compiler/linker
Max> output instead of checking their exit code or presence of produced
Max> object/ executable files?
Going by the comment some lines above, my guess would be "because some
compilers acce
On Fri, Mar 20, 2015 at 5:09 AM, Bruce Momjian wrote:
> On Fri, Mar 20, 2015 at 04:51:55AM +0300, Max Filippov wrote:
>> xtensa-linux-gcc -o conftest -Wall -Wmissing-prototypes
>> -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels
>> -Wmissing-format-attribute -Wformat-security -fno-stri
On Fri, Mar 20, 2015 at 04:51:55AM +0300, Max Filippov wrote:
> xtensa-linux-gcc -o conftest -Wall -Wmissing-prototypes
> -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels
> -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing
> -fwrapv -fexcess-precision=standard -D_LARGEFI
>> if test "`(eval $ac_link 2>&1 1>&5)`" = "" && test "`(eval
>> $ac_compile 2>&1 1>&5)`" = ""; then
FWIW, I happened to run into this recently on IRC with someone having
compile problems on FreeBSD (10.1); they were using some nonstandard
compile flags, and configure's pthread test was breakin
Hi Tom,
On Fri, Mar 20, 2015 at 3:50 AM, Tom Lane wrote:
> Max Filippov writes:
>> when PostgreSQL is cross-compiled in the Buildroot with uClibc toolchain
>> it may not correctly detect compiler/linker flags for threading. [1]
>> The reason is that config/acx_pthread.m4:146 uses compiler and li
Max Filippov writes:
> when PostgreSQL is cross-compiled in the Buildroot with uClibc toolchain
> it may not correctly detect compiler/linker flags for threading. [1]
> The reason is that config/acx_pthread.m4:146 uses compiler and linker
> stdout and stderr to make decision if acx_pthread_ok shou
Hi,
when PostgreSQL is cross-compiled in the Buildroot with uClibc toolchain
it may not correctly detect compiler/linker flags for threading. [1]
The reason is that config/acx_pthread.m4:146 uses compiler and linker
stdout and stderr to make decision if acx_pthread_ok should be yes or no:
if te
30 matches
Mail list logo
