Обсуждение: Why is libcurses added to build by configure?
Does anyone understand why configure.in wants to include libcurses in
$(LIBS) ? There is no program in the PostgreSQL distribution that uses
that library (at least, I could not find any reference to curses.h).
On HPUX 10, including libcurses causes problems because it defines a
select() routine that has nothing to do with the select() system call.
There is a hack in Makefile.hpux that gets around this (by linking -lc
ahead of the libraries chosen by configure), but that is going to cause
problems for supporting HPUX 10.01, because signal considerations demand
that -lBSD come first on that platform.
I would like to pull out the configure.in code that adds -lcurses to
LIBS, but I'm hesitant to do it at this late stage in the release cycle
without knowing why it was there in the first place. Did we use to have
a frontend that used curses, or something like that?
regards, tom lane
On Fri, 30 Oct 1998, Tom Lane wrote:
> Does anyone understand why configure.in wants to include libcurses in
> $(LIBS) ? There is no program in the PostgreSQL distribution that uses
> that library (at least, I could not find any reference to curses.h).
>
> On HPUX 10, including libcurses causes problems because it defines a
> select() routine that has nothing to do with the select() system call.
> There is a hack in Makefile.hpux that gets around this (by linking -lc
> ahead of the libraries chosen by configure), but that is going to cause
> problems for supporting HPUX 10.01, because signal considerations demand
> that -lBSD come first on that platform.
>
> I would like to pull out the configure.in code that adds -lcurses to
> LIBS, but I'm hesitant to do it at this late stage in the release cycle
> without knowing why it was there in the first place. Did we use to have
> a frontend that used curses, or something like that?
Good stuff, you are learning...do not pull anything out, period.
Don't add anything in, period. There was a reason for it, but it was
sooooo long ago that I don't recall what it was. It has worked up until
now, and if only HPUX 10.01 is reporting a problem with it...leave it.
Mark it as un-supported at this time, and work at fixing it post-release.
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
On 30-Oct-98 Tom Lane wrote:
> Does anyone understand why configure.in wants to include libcurses in
> $(LIBS) ? There is no program in the PostgreSQL distribution that uses
> that library (at least, I could not find any reference to curses.h).
I'm guessing here, but could it be a replacement for things like readline?
I know old OS versions could have any number of things stuck to it, and
after some of the things I've seen HP-UX do over the years, nothing really
surprises me anymore.
>
> On HPUX 10, including libcurses causes problems because it defines a
> select() routine that has nothing to do with the select() system call.
> There is a hack in Makefile.hpux that gets around this (by linking -lc
> ahead of the libraries chosen by configure), but that is going to cause
> problems for supporting HPUX 10.01, because signal considerations demand
> that -lBSD come first on that platform.
>
> I would like to pull out the configure.in code that adds -lcurses to
> LIBS, but I'm hesitant to do it at this late stage in the release cycle
> without knowing why it was there in the first place. Did we use to have
> a frontend that used curses, or something like that?
How wise would that be at this time? That may be something to do at
a time like a minor version release.
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null # include <std/disclaimers.h>
TEAM-OS2 Online Searchable Campground Listings http://www.camping-usa.com "There is no outfit less
entitledto lecture me about bloat than the federal government" -- Tony Snow
==========================================================================
> I would like to pull out the configure.in code that adds -lcurses to
> LIBS, but I'm hesitant to do it at this late stage in the release
> cycle without knowing why it was there in the first place.
Yup. I think we are pretty much frozen by now. Seems like a v6.5 thing
since it may have effects on other platforms.
- Tom
psql (at least in 6.3.2) uses curses and readline. I know this because I tried to compile under a SuSE 5.3 distribution. Configure couldn't find the curses library, so it wasn't added to LIBS, so the linker didn't try to use it, so psql had unresolved references, all of which seems to indicate (even without reading the sources) that *something* in there wants curses. I.e., it's not just configure. Interestingly, failing to find curses did NOT stop configure, it went on to make everything. "make all" didn't stop when psql failed to build either - it went on to report all well at the end. Not until "make install" did the failure become evident (though it was logged of course). Regards, K. Am 30-Oct-98 schrieb Tom Lane: > Does anyone understand why configure.in wants to include libcurses in > $(LIBS) ? There is no program in the PostgreSQL distribution that uses > that library (at least, I could not find any reference to curses.h). > > On HPUX 10, including libcurses causes problems because it defines a > select() routine that has nothing to do with the select() system call. > There is a hack in Makefile.hpux that gets around this (by linking -lc > ahead of the libraries chosen by configure), but that is going to cause > problems for supporting HPUX 10.01, because signal considerations demand > that -lBSD come first on that platform. > > I would like to pull out the configure.in code that adds -lcurses to > LIBS, but I'm hesitant to do it at this late stage in the release cycle > without knowing why it was there in the first place. Did we use to have > a frontend that used curses, or something like that? > > regards, tom lane > --- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (auer@kom.id.ethz.ch) Geschaeft/work +41-1-6327531 Kommunikation, ETHZ RZ Privat/home +41-1-4517941 Clausiusstrasse 59 Fax +41-1-6321225 CH-8092 ZUERICH Switzerland
Karl Auer <auer@kom.id.ethz.ch> writes:
> psql (at least in 6.3.2) uses curses and readline. I know this because
> I tried to compile under a SuSE 5.3 distribution.
Hmm. psql does use readline, but there's no direct dependency on
curses. (I verified this by building without curses; it works, here.)
Perhaps there are some implementations of readline that depend on
curses? The GNU libreadline I have here appears to use termcap,
but not curses. There might be other versions though.
I think it would be possible to extend configure to detect which
library(s) libreadline depends on, and only include those in the link.
But that's not something to risk at this stage...
regards, tom lane
Tom Lane wrote: > > Karl Auer <auer@kom.id.ethz.ch> writes: > > psql (at least in 6.3.2) uses curses and readline. I know this because > > I tried to compile under a SuSE 5.3 distribution. > > Hmm. psql does use readline, but there's no direct dependency on > curses. (I verified this by building without curses; it works, here.) > > Perhaps there are some implementations of readline that depend on > curses? The GNU libreadline I have here appears to use termcap, > but not curses. There might be other versions though. > > I think it would be possible to extend configure to detect which > library(s) libreadline depends on, and only include those in the link. > But that's not something to risk at this stage... readline needs terminfo/termcap. On many Linux systems terminfo support is in the [n]curses library. Phil
Phil Thompson <phil@river-bank.demon.co.uk> writes:
> readline needs terminfo/termcap. On many Linux systems terminfo support
> is in the [n]curses library.
In fact, what I discovered after some further tracking of dependencies
is that the routines needed by readline are available in *either*
libtermcap or libcurses on HPUX. According to Horton's _Portable C
Software_, having a separate libtermcap is Berkeley practice and folding
it into libcurses is a SysV-ism.
So, the safest approach seems to be to leave configure alone and solve
the select()-in-libcurses problem with some hackery in Makefile.hpux.
regards, tom lane
Doesn't work here :-) I suspect you are correct, because now that I inspect the makefile output more closely, it is libreadline that has the unresolved references, not any object file in the source tree. Regards, K. Am 31-Oct-98 schrieb Tom Lane: > Karl Auer <auer@kom.id.ethz.ch> writes: >> psql (at least in 6.3.2) uses curses and readline. I know this because >> I tried to compile under a SuSE 5.3 distribution. > > Hmm. psql does use readline, but there's no direct dependency on > curses. (I verified this by building without curses; it works, here.) > > Perhaps there are some implementations of readline that depend on > curses? The GNU libreadline I have here appears to use termcap, > but not curses. There might be other versions though. > > I think it would be possible to extend configure to detect which > library(s) libreadline depends on, and only include those in the link. > But that's not something to risk at this stage... > > regards, tom lane > --- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (auer@kom.id.ethz.ch) Geschaeft/work +41-1-6327531 Kommunikation, ETHZ RZ Privat/home +41-1-4517941 Clausiusstrasse 59 Fax +41-1-6321225 CH-8092 ZUERICH Switzerland