Обсуждение: make check failure for 8.4.0
I took the 8.4.0 release tarball and tried to build it on one of our
production servers which is currently running 8.3.7. We routinely
build multiple versions of PostgreSQL on a machine, using --prefix to
place them. Something seems broken for 8.4.0. Not sure how best to
proceed.
I ran:
----------
tar -xjf postgresql-8.4.0.tar.bz2
cd postgresql-8.4.0/
./configure --prefix=/usr/local/pgsql-8.4.0 --enable-integer-datetimes
--enable-debug --disable-nls --with-libxml
make
make check
-----------
and had these failures:
----------
test create_function_1 ... FAILED
triggers ... FAILED
----------
Files attached. It appears that some phase of the make or make check
picked up production libraries instead of libraries from the build.
Hmmm.... I tried on another machine with very similar configuration
and it worked.
Both machines report (substituting <hostname> for the actual name):
SUSE Linux Enterprise Server 10 (x86_64)
VERSION = 10
PATCHLEVEL = 2
Linux <hostname> 2.6.16.60-0.39.3-smp #1 SMP Mon May 11 11:46:34 UTC
2009 x86_64 x86_64 x86_64 GNU/Linux
What should I check?
-Kevin
Вложения
Kevin Grittner wrote: > I took the 8.4.0 release tarball and tried to build it on one of our > production servers which is currently running 8.3.7. We routinely > build multiple versions of PostgreSQL on a machine, using --prefix to > place them. Something seems broken for 8.4.0. Not sure how best to > proceed. > > I ran: > > ---------- > tar -xjf postgresql-8.4.0.tar.bz2 > cd postgresql-8.4.0/ > ./configure --prefix=/usr/local/pgsql-8.4.0 --enable-integer-datetimes > --enable-debug --disable-nls --with-libxml > make > make check > ----------- > > and had these failures: > > ---------- > test create_function_1 ... FAILED > triggers ... FAILED > ---------- > > Files attached. It appears that some phase of the make or make check > picked up production libraries instead of libraries from the build. > > Hmmm.... I tried on another machine with very similar configuration > and it worked. > > Both machines report (substituting <hostname> for the actual name): > > SUSE Linux Enterprise Server 10 (x86_64) > VERSION = 10 > PATCHLEVEL = 2 > > Linux <hostname> 2.6.16.60-0.39.3-smp #1 SMP Mon May 11 11:46:34 UTC > 2009 x86_64 x86_64 x86_64 GNU/Linux > > What should I check? > > > Can we look at the make log? cheers andrew
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> ERROR: incompatible library "/home/kgrittn/postgresql-8.4.0/src/test/regress/refint.so": version mismatch
> DETAIL: Server is version 8.4, library is version 8.3.
That's just bizarre. Could you try strace'ing the backend while doing
that CREATE FUNCTION command (or it should be enough to just try to LOAD
that file by name)? That should provide some evidence about what's
happening. It seems like the dynamic linker must be ignoring the file
it's told to load and loading something else instead, but that's weird
enough that I want strace proof of it...
regards, tom lane
On Sat, Jul 18, 2009 at 12:30 AM, Tom Lane<tgl@sss.pgh.pa.us> wrote: > "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes: >> ERROR: incompatible library "/home/kgrittn/postgresql-8.4.0/src/test/regress/refint.so": version mismatch >> DETAIL: Server is version 8.4, library is version 8.3. > > That's just bizarre. Could you try strace'ing the backend while doing > that CREATE FUNCTION command (or it should be enough to just try to LOAD > that file by name)? That should provide some evidence about what's > happening. It seems like the dynamic linker must be ignoring the file > it's told to load and loading something else instead, but that's weird > enough that I want strace proof of it... Really? That's not how I read it. I read it as the build process in the contrib directory built these modules using the pgxs configuration from his 8.3 install. -- greg http://mit.edu/~gsstark/resume.pdf
Greg Stark <gsstark@mit.edu> writes:
> Really? That's not how I read it. I read it as the build process in
> the contrib directory built these modules using the pgxs configuration
> from his 8.3 install.
Hm, maybe, but it's not supposed to do that (and I would think we'd have
noticed such a problem before --- surely most hackers have pre-existing
installations of PG in their PATH when they build test versions).
Anyway I'd like to have some hard data before speculating too much.
regards, tom lane
Tom Lane wrote: > Greg Stark <gsstark@mit.edu> writes: > >> Really? That's not how I read it. I read it as the build process in >> the contrib directory built these modules using the pgxs configuration >> from his 8.3 install. >> > > Hm, maybe, but it's not supposed to do that (and I would think we'd have > noticed such a problem before --- surely most hackers have pre-existing > installations of PG in their PATH when they build test versions). > Anyway I'd like to have some hard data before speculating too much. > > That's why I asked to see the make log. Maybe some environment setting affected things? cheers andrew
Andrew Dunstan <andrew@dunslane.net> wrote: > That's why I asked to see the make log. Maybe some environment > setting affected things? Bingo! A few weeks back I had been experimenting with using the PGXS compiles for our extensions, rather than expanding our tarballs in the build tree and just doing make and sudo make install there. On the failing machine, the session I used has USE_PGXS defined. I unset that and out of paranoia I did a make distclean and started over. This time the same steps worked fine. Out of curiosity, where is the make log to which you refer? -Kevin
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Bingo! A few weeks back I had been experimenting with using the PGXS
> compiles for our extensions, rather than expanding our tarballs in the
> build tree and just doing make and sudo make install there. On the
> failing machine, the session I used has USE_PGXS defined.
Hah. I wonder whether it's possible for an in-tree build to
intentionally undefine that? We could do something likeoverride USE_PGXS :=
in contrib/Makefile but I'm not sure if that results in the
variable being "undefined".
regards, tom lane
On Sat, July 18, 2009 1:35 pm, Kevin Grittner wrote: > > Out of curiosity, where is the make log to which you refer? > Just the output from make. e.g. make > make.log 2>&1 cheers andrew
Kevin Grittner wrote: > Andrew Dunstan <andrew@dunslane.net> wrote: > > > That's why I asked to see the make log. Maybe some environment > > setting affected things? > > Bingo! A few weeks back I had been experimenting with using the PGXS > compiles for our extensions, rather than expanding our tarballs in the > build tree and just doing make and sudo make install there. On the > failing machine, the session I used has USE_PGXS defined. I unset > that and out of paranoia I did a make distclean and started over. This seems like a bug in the PGXS stuff that oughta be fixed. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Kevin Grittner wrote:
>> Bingo! A few weeks back I had been experimenting with using the PGXS
>> compiles for our extensions, rather than expanding our tarballs in the
>> build tree and just doing make and sudo make install there. On the
>> failing machine, the session I used has USE_PGXS defined. I unset
>> that and out of paranoia I did a make distclean and started over.
> This seems like a bug in the PGXS stuff that oughta be fixed.
Well, PGXS per se is just doing what it was told to. What I was
thinking is that we should arrange to un-define USE_PGXS during a
standard in-tree build of contrib/. It's not quite clear to me
where that should happen though. Is contrib/Makefile the right place?
That would mean that issuing "make" within a contrib module directory
might behave differently from saying "make" at a higher level. Maybe
that's what we want --- I can certainly imagine wishing to activate
PGXS while building a contrib module, even if it happens to be inside
a Postgres source tree.
regards, tom lane