Обсуждение: BUG #1865: isinf wrongly dectected under Solaris 9

The following bug has been logged online:

Bug reference:      1865
Logged by:          Bob Friesenhahn
Email address:      bfriesen@simple.dallas.tx.us
PostgreSQL version: 7.4.8
Operating system:   Solaris 9 (SPARC)
Description:        isinf wrongly dectected under Solaris 9
Details:

Using GCC 4.0.1 on Solaris 9 the configure test for isinf incorrectly
detects success so postgres does not link.

Bob Friesenhahn wrote:
> Using GCC 4.0.1 on Solaris 9 the configure test for isinf incorrectly
> detects success so postgres does not link.

Please provide the config.log file and the tail end of the failing build
log (at least the failing command and the error message).

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Bob Friesenhahn wrote:
> The config.log and a build log are attached.

It's puzzling why the test program compiles and links without complaint
when the isinf() function does not exist.  Can you try to isolate the
test program from configure and see what is going on?

> Note that there are
> actually two bugs in the build but the build terminates due to the
> isinf bug.  The failure to link due to -lreadline needing -lcurses
> does not occur until later.

In the logs you sent, configure decides to use -ledit, which is
something different altogether.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

On Thu, 8 Sep 2005, Peter Eisentraut wrote:

> Bob Friesenhahn wrote:
>> The config.log and a build log are attached.
>
> It's puzzling why the test program compiles and links without complaint
> when the isinf() function does not exist.  Can you try to isolate the
> test program from configure and see what is going on?

I will see what I can do when I find the time.  I do recall
encountering one other package which had this identical problem but I
don't recall what that package was.  It seems likely that it is
somehow related to using GCC 4.0.1.

>> Note that there are
>> actually two bugs in the build but the build terminates due to the
>> isinf bug.  The failure to link due to -lreadline needing -lcurses
>> does not occur until later.
>
> In the logs you sent, configure decides to use -ledit, which is
> something different altogether.

Ugh.  I do think that readline 5.0 itself has a minor bug in that ldd
on libreadline.so does not show a dependency on the curses library,
even though it is obviously required.  This means that the linkage of
libreadline.so is incomplete.

% ldd /usr/local/lib/libreadline.so.5
warning: ldd: /usr/local/lib/libreadline.so.5: is not executable
         libgcc_s.so.1 =>         /usr/local/lib/libgcc_s.so.1
         libc.so.1 =>     /lib/libc.so.1
         libdl.so.1 =>    /lib/libdl.so.1
         /usr/platform/SUNW,Sun-Blade-2500/lib/libc_psr.so.1

Bob
======================================
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

Bob Friesenhahn <bfriesen@simple.dallas.tx.us> writes:
> Ugh.  I do think that readline 5.0 itself has a minor bug in that ldd
> on libreadline.so does not show a dependency on the curses library,
> even though it is obviously required.  This means that the linkage of
> libreadline.so is incomplete.

That's fairly standard I fear.  Certainly libreadline is like that on
my Fedora machine (and it doesn't stop our configure script from getting
it right).

It may be that the presence of both libedit and libreadline is what's
messing things up.  I seem to recall fixing configure to deal with that
[ digs in logs ... ] oh, here we go:

2004-11-30 01:13  tgl

    * config/programs.m4, configure, configure.in: Fix readline/libedit
    selection code to prefer readline over libedit reliably (ie,
    regardless of which libraries they depend on).    Also make sure that
    we don't select headers that obviously belong to the wrong one of
    the two libraries.  This was discussed back around 4-Sep but seems
    to have slipped through the cracks.  The header selection could be
    checked more closely, perhaps, but let's see if this is good
    enough.

This fix is present in 8.0 and later.

            regards, tom lane

On Sat, 10 Sep 2005, Tom Lane wrote:

> Bob Friesenhahn <bfriesen@simple.dallas.tx.us> writes:
>> Ugh.  I do think that readline 5.0 itself has a minor bug in that ldd
>> on libreadline.so does not show a dependency on the curses library,
>> even though it is obviously required.  This means that the linkage of
>> libreadline.so is incomplete.
>
> That's fairly standard I fear.  Certainly libreadline is like that on
> my Fedora machine (and it doesn't stop our configure script from getting
> it right).
>
> It may be that the presence of both libedit and libreadline is what's
> messing things up.  I seem to recall fixing configure to deal with that
> [ digs in logs ... ] oh, here we go:

That certainly seems like a reasonable conclusion.  I would be
perfectly happy to use libedit rather than libreadline, but I wrongly
assumed that without it command line editing would not function.

Thanks for identifying the cause of the problem.

Bob
======================================
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/