
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

Tue, 09 Mar 2004 15:21:31 -0500
Andrew Dunstan <andrew@dunslane.net>
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

Tue, 09 Mar 2004 16:07:54 -0500
Andrew Dunstan <andrew@dunslane.net>
Re: 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.

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

Tue, 9 Mar 2004 16:10:48 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: cvs breakage
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.


Tue, 9 Mar 2004 22:11:45 +0100
Peter Eisentraut <peter_e@gmx.net>
Re: cvs breakage
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

Tue, 09 Mar 2004 17:29:39 -0500
Andrew Dunstan <andrew@dunslane.net>
Re: cvs breakage
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

Tue, 09 Mar 2004 17:53:20 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: cvs breakage 
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

Tue, 9 Mar 2004 17:57:18 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: cvs breakage
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

Tue, 09 Mar 2004 18:00:56 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: cvs breakage 
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

Tue, 09 Mar 2004 18:05:39 -0500
Andrew Dunstan <andrew@dunslane.net>
Re: cvs breakage
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

Tue, 9 Mar 2004 18:14:11 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: cvs breakage
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.


Wed, 10 Mar 2004 08:36:09 +0100
Peter Eisentraut <peter_e@gmx.net>
Re: cvs breakage