Обсуждение: HPUX 10.01 build issues and solutions.
Hi. I just built postgresql 6.4 beta 4 on HPUX 10.01. This was not a clean compile +, and I had to make minor modifications to get it to compile. First of all, hpux 10.01 does not define SA_RESTART at all (10.20 does, but 10.01 does not). + To compile under 10.01, you cant define USE_POSIX_SIGNALS in os.h I fixed this + by just deleting these lines from os.h: #ifdef HPUX_10 #define USE_POSIX_SIGNALS #endif Secondly, lex on hpux 10.01 has problems as well. I got the following errors due to lex on 10.01: make -C lib all make[3]: Entering directory `/home/schout/pgsql/src/interfaces/ecpg/lib' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/home/schout/pgsql/src/interfaces/ecpg/lib' make -C preproc all make[3]: Entering directory `/home/schout/pgsql/src/interfaces/ecpg/preproc' lex pgc.l "pgc.l" line 333: warning 45: Non-portable Character Class "pgc.l" line 333: warning 45: Non-portable Character Class "pgc.l" line 471: warning 45: Non-portable Character Class "pgc.l" line 471: warning 45: Non-portable Character Class "pgc.l" line 471: warning 45: Non-portable Character Class "pgc.l" line 471: warning 45: Non-portable Character Class "pgc.l" line 475: warning 45: Non-portable Character Class "pgc.l" line 475: warning 45: Non-portable Character Class "pgc.l" line 536: warning 45: Non-portable Character Class "pgc.l" line 536: warning 45: Non-portable Character Class "pgc.l" line 585: warning 45: Non-portable Character Class "pgc.l" line 585: warning 45: Non-portable Character Class "pgc.l" line 674: warning 48: Undefined start condition <EOF "pgc.l" line 708: error 14: Too many transitions, Try using %a num 671/1000 nodes(%e), 1482/2500 positions(%p), 168/500 (%n), 14470 transitions, 89 +5/1000 packed char classes(%k), 2000/2000 packed transitions(%a), 0/0 output sl +ots(%o) make[3]: *** [pgc.c] Error 1 make[3]: Leaving directory `/home/schout/pgsql/src/interfaces/ecpg/preproc' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/schout/pgsql/src/interfaces/ecpg' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/schout/pgsql/src/interfaces' make: *** [all] Error 2 I got around this problem by installing flex-2.5.4a from prep.ai.mit.edu, and sym linking /usr/bin/lex to /opt/gnu/bin/flex (where I installed flex). After that, everything pretty much went smoothly. I did have to manually commen +t out the rules to build libpq++ because apparently ecgs wont let you specify the + "-c" and "-o" flags together, but that is not a big deal to me since I dont +intend to use the libpq++ interface on this machine anyways. It would be nice if there + was a --disable-libpq++ rule for configure that would allow you to specify that + you did not want to use it. And possibly something similar like --with-flex=/opt/gnu/bin/flex to override the choice of /usr/bin/flex (maybe the +se already exist??). Anyways, Some food for thought. Im sure its too late to address these for the + upcoming 6.4 release, but maybe for the next minor release ;) Mike
mschout@gkg.net writes:
> hpux 10.01 does not define SA_RESTART at all (10.20 does, but 10.01
> does not).
Hmm. I wonder if we'd be better off to treat 10.01 as being like HPUX 9?
I think the choice between posix and non-posix signals is the main
difference that we care about...
> Secondly, lex on hpux 10.01 has problems as well.
A lot of systems have inadequate lexes installed. There is supposed to
be a test early in the install to see if your lex is up to snuff (and if
not it'll tell you to get flex). Either that's not working, or ecpg is
exercising some new stuff that the test doesn't check for. I don't know
enough about lex to try to improve the test --- anyone care to work on
that?
> It would be nice if there was a --disable-libpq++ rule for configure
> that would allow you to specify that you did not want to use it.
There is, it's spelled "--without-CXX". This needs to be documented
better, but we're working on the install doc even now.
> And possibly something similar like --with-flex=/opt/gnu/bin/flex to
> override the choice of /usr/bin/flex (maybe these already exist??).
configure will select flex in preference to lex if it finds flex in your
PATH --- and if you have more than one flex in your PATH, the first one
gets picked. Perhaps you just needed to re-run configure with an
appropriate PATH? Alternatively, you can force the choice by setting
the LEX and LEXLIB environment variables before running configure (also
undocumented I fear).
Finally, there's always the option of editing Makefile.global
afterwards. Right now it can be a bit tedious to look through all the
files that configure emits, but we're going to try to consolidate the
configuration decisions into just a couple of files in future releases.
(BTW, hackers, I think this is an excellent example of why hand-editable
configure output is a good thing. It's not that Mike *couldn't* have
persuaded configure to do what he needed, it's that it's not always so
obvious how to do that ... and editing the resulting Makefile.global
might be a lot easier than figuring out how to make configure do the
right thing.)
regards, tom lane
> mschout@gkg.net writes: > > hpux 10.01 does not define SA_RESTART at all (10.20 does, but 10.01 > > does not). > > Hmm. I wonder if we'd be better off to treat 10.01 as being like HPUX 9? > I think the choice between posix and non-posix signals is the main > difference that we care about... > > > Secondly, lex on hpux 10.01 has problems as well. > > A lot of systems have inadequate lexes installed. There is supposed to > be a test early in the install to see if your lex is up to snuff (and if > not it'll tell you to get flex). Either that's not working, or ecpg is > exercising some new stuff that the test doesn't check for. I don't know > enough about lex to try to improve the test --- anyone care to work on > that? It just checks for buggy flex 2.5.3, that almost everyone had in early 6.* releases. Not sure how many people still have that version, but I am sure we will require the test for several more years. The big problem was that the bug only showed errors once you started to use PostgreSQL, and the errors were very unclear. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
mschout@gkg.net writes:
> hpux 10.01 does not define SA_RESTART at all (10.20 does, but 10.01
> does not). To compile under 10.01, you cant define USE_POSIX_SIGNALS
> in os.h I fixed this by just deleting these lines from os.h:
> #ifdef HPUX_10
> #define USE_POSIX_SIGNALS
> #endif
I don't think that will work completely --- it may compile, but you will
not get the right behavior of signals. You need BSD signal semantics if
you don't have POSIX signals, and to get that on HPUX 10 you had better
modify makefiles/Makefile.hpux to link libBSD before libc. In the codeifneq ($(HPUX_MAJOR), 09) LDFLAGS:= -Wl,-E -lc
$(LDFLAGS)endif
add -lBSD before -lc.
Since it's not clear where between HPUX 10.01 and 10.20 HP added POSIX
signal support, I can't easily fix this on the basis of testing the OS
version number. That's the wrong approach anyway, really. I am
thinking that the right approach is to stop depending on the port header
files to tell us whether to use POSIX signals, and instead to have
configure auto-detect it. It would be easy to see whether <signal.h>
contains a definition for SA_RESTART, and that probably would do as a
configure test for POSIX signals. (We'd better make sure that the
template files can override the test, of course, in case the platform
has the SA_RESTART macro but POSIX signals don't work right...)
I don't think we should risk a change of that magnitude so close before
a major release, but I will work on it after 6.4 is out the door. For
6.4 we will have to offer the above workaround to anyone who needs to
build for HPUX 10.01.
regards, tom lane
On Fri, 30 Oct 1998, Tom Lane wrote:
> Finally, there's always the option of editing Makefile.global
> afterwards. Right now it can be a bit tedious to look through all the
> files that configure emits, but we're going to try to consolidate the
> configuration decisions into just a couple of files in future releases.
We are? *raised eyebrow*
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
The Hermit Hacker <scrappy@hub.org> writes:
> On Fri, 30 Oct 1998, Tom Lane wrote:
>> ... Right now it can be a bit tedious to look through all the
>> files that configure emits, but we're going to try to consolidate the
>> configuration decisions into just a couple of files in future releases.
> We are? *raised eyebrow*
Well, it's on my to-do list...
regards, tom lane
On Sat, 31 Oct 1998, Tom Lane wrote:
> The Hermit Hacker <scrappy@hub.org> writes:
> > On Fri, 30 Oct 1998, Tom Lane wrote:
> >> ... Right now it can be a bit tedious to look through all the
> >> files that configure emits, but we're going to try to consolidate the
> >> configuration decisions into just a couple of files in future releases.
>
> > We are? *raised eyebrow*
>
> Well, it's on my to-do list...
I do not agree with the requirement to consolidate the
configuration decisions into just a couple of files...we do nothing
differently, as it is now, then any other large package does it, and I do
not see a requirement to change from what currently works.
If a particular port doesn't "configure" correctly, then fix the
problem, but fixing it doesn't mean consolidate what currently exists...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
The Hermit Hacker <scrappy@hub.org> writes:
> I do not agree with the requirement to consolidate the
> configuration decisions into just a couple of files...we do nothing
> differently, as it is now, then any other large package does it, and I do
> not see a requirement to change from what currently works.
What we have now works OK for run-of-the-mill installations on supported
platforms. It's not very friendly for people who have slightly
nonstandard setups. We've seen at least one actual example of that
since the discussion started (not counting Thomas' original complaint,
which I suppose you could write off as pilot error ... but if even
Thomas doesn't understand how to configure Postgres, then it must be a
pretty closely held secret...). I expect a pass through the pgsql-admin
archives would turn up a bunch more examples.
Also, while I have seen packages that use configure to rewrite a ton of
subdirectory Makefiles (GNU Emacs, for example), I think they have
simpler and less failure-prone configuration setups than we do. Emacs,
for example, isn't trying to interface to both Tcl/Tk and Perl --- two
packages that are out there in multiple versions and have no well
defined installation location.
Autoconf configure scripts are inherently not 100% reliable. They are
heuristic tests that maybe will work 95% or 99% or even 99.9% of the
time, but trying to make them absolutely bulletproof for *any* target
system setup is folly. Good practice is to provide a manual override
path for any decision the script makes. Now, we can do that either by
adding configure script options or by making it reasonably convenient
to hand-modify the results of configure. I submit that it is
counterproductive to have a list of script options that approaches the
size of Makefile.global.in + config.h.in. That will just confuse the
average person who has no need for most of those options.
Also, to bring the discussion back to Thomas' original complaint, what
of Makefile.custom? If editing Makefile.global stops being a useful
technique because we've put copies of configuration settings in too many
other places, then Makefile.custom is also a useless way of customizing
the system.
In fact there's an even more direct issue, namely the port files.
Roughly speaking, Makefile.port is capable of altering decisions
expressed in Makefile.global, and os.h is capable of altering decisions
expressed in config.h. If we scatter configuration settings everywhere,
then those two files no longer have their hands on all the levers, and
writing new port files becomes more difficult if not impossible.
Furthermore, that style of working makes it more likely that developers
will break existing ports, by causing configure to write some choice
into some file without noticing that the port files for a platform other
than their own want to override that choice.
(Yeah, I know that we'd like to reduce dependence on the port files
by having configure auto-detect more things. But I don't expect to be
able to eliminate the port files entirely --- there will always be some
things that it's not really practical to make configure detect.)
So I believe that it's good style and good sense to try to centralize
the results of configure in as few files as possible, preferably just
those two.
regards, tom lane