cvs breakage

Andrew Dunstan wrote:

Fresh cvs tip checkout.

If I configure with --prefix then cvs tip seems to fail make check -
initdb fails with a complaint about a missing symbol for
canonicalise_path. If I don't set the prefix then it works fine. I
don't have any funny LD_LIBRARY_PATH stuff set.

Further data point. The prefix used had a previous installation in it
done before the canonicalise_path change. If I use
--prefix=/totally/new/location I don't get this failure.

cheers

andrew

Andrew Dunstan wrote:

Fresh cvs tip checkout.

If I configure with --prefix then cvs tip seems to fail make check -
initdb fails with a complaint about a missing symbol for
canonicalise_path. If I don't set the prefix then it works fine. I don't
have any funny LD_LIBRARY_PATH stuff set.

That was a commit from yesterday. My guess is that you didn't make a
gmake distclean before running configure. We moved canonicalise_path
into /port from initdb. Maybe try ldconfig too.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Andrew Dunstan wrote:

If I configure with --prefix then cvs tip seems to fail make check -
initdb fails with a complaint about a missing symbol for
canonicalise_path. If I don't set the prefix then it works fine. I
don't have any funny LD_LIBRARY_PATH stuff set.

You need to do "make install" before "make check" or you need to compile
without rpath.

Peter Eisentraut wrote:

Andrew Dunstan wrote:

If I configure with --prefix then cvs tip seems to fail make check -
initdb fails with a complaint about a missing symbol for
canonicalise_path. If I don't set the prefix then it works fine. I
don't have any funny LD_LIBRARY_PATH stuff set.

You need to do "make install" before "make check" or you need to compile
without rpath.

I understood "make check" should be able to be run before an install.

Turning off rpath in src/Makefile.global did the trick. I'm amazed this
hasn't caught me before - maybe libpq has just been so stable it hasn't
made a difference ... Should the version number be bumped? or is this
just a developer gotcha?

anyway, thanks

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

Turning off rpath in src/Makefile.global did the trick. I'm amazed this
hasn't caught me before - maybe libpq has just been so stable it hasn't
made a difference ... Should the version number be bumped? or is this
just a developer gotcha?

If it hasn't been bumped since 7.4 then it needs to be. Bruce, don't
you normally do that at the start of a devel cycle?

regards, tom lane

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

Turning off rpath in src/Makefile.global did the trick. I'm amazed this
hasn't caught me before - maybe libpq has just been so stable it hasn't
made a difference ... Should the version number be bumped? or is this
just a developer gotcha?

If it hasn't been bumped since 7.4 then it needs to be. Bruce, don't
you normally do that at the start of a devel cycle?

I show this for interfaces/libpq/Makefile:

revision 1.96
date: 2003/11/30 06:09:50; author: momjian; state: Exp; lines: +2 -2
Bump all version numbers and version stamps mentioned in
RELEASE_CHANGES.

This is for the 7.5/HEAD tree, so it is bumped. What we don't do is
bump during development.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

This is for the 7.5/HEAD tree, so it is bumped. What we don't do is
bump during development.

No, we shouldn't do intermediate bumps during a devel cycle. Andrew,
did you have an earlier 7.5devel libpq.so installed someplace? If so
that's the gotcha you have to watch out for. The numbering is intended
to keep libpqs from different release cycles separate, but not within a
cycle.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

This is for the 7.5/HEAD tree, so it is bumped. What we don't do is
bump during development.

No, we shouldn't do intermediate bumps during a devel cycle. Andrew,
did you have an earlier 7.5devel libpq.so installed someplace? If so
that's the gotcha you have to watch out for. The numbering is intended
to keep libpqs from different release cycles separate, but not within a
cycle.

Yes, in the location pointed to by --prefix ...

I fully understand now. And it was fixed by truning off rpath.

Is this gotcha mentioned anywhere in documentation?

cheers

andrew

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

This is for the 7.5/HEAD tree, so it is bumped. What we don't do is
bump during development.

No, we shouldn't do intermediate bumps during a devel cycle. Andrew,
did you have an earlier 7.5devel libpq.so installed someplace? If so
that's the gotcha you have to watch out for. The numbering is intended
to keep libpqs from different release cycles separate, but not within a
cycle.

That's why I recommended ldconfig to clear out his symbol lookup cache.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Andrew Dunstan wrote:

I understood "make check" should be able to be run before an install.

Yes, it's one of our dirty little secrets.

Turning off rpath in src/Makefile.global did the trick. I'm amazed
this hasn't caught me before - maybe libpq has just been so stable it
hasn't made a difference ... Should the version number be bumped? or
is this just a developer gotcha?

The version number doesn't matter unless it's a major version change.
If you have an rpath set and there is a fittingly named library there,
the executables take that one no matter what you may have set via
LD_LIBRARY_PATH or other means.