Thread: cvs breakage
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. 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. > 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, Pennsylvania19073
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
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, Pennsylvania19073
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
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: > 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.96date: 2003/11/30 06:09:50; author: momjian; state: Exp; lines: +2 -2Bump all version numbers and versionstamps mentioned inRELEASE_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, Pennsylvania19073
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
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.