Peter Eisentraut <[EMAIL PROTECTED]> writes:
> No we don't, because we set the rpath and our installation routines take
> care that in the target directory the libfoo.so.X is in fact the latest
> library. The only problem that make check has is that it bypasses the
> prober installation routine
Tom Lane wrote:
> On investigation, I can't find any sign that my Linux box does
> anything with library minor version numbers either. That seems to
> mean that we should be bumping the major version for every release
> (unless we made no externally visible changes at all, not even
> upward-compat
Csaba Nagy <[EMAIL PROTECTED]> writes:
> Looks like there's no minor version info at all in the binaries, I would
> say...
On investigation, I can't find any sign that my Linux box does anything
with library minor version numbers either. That seems to mean that we
should be bumping the major vers
On Thu, 2004-03-11 at 17:26, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> But shouldn't the minor-version bump between 7.3 and 7.4 libpq.so
> >> have prevented the dynamic linker from accepting the 7.3 libpq.so as
> >> the one to use? I thought the rule w
Tom Lane wrote:
> But shouldn't the minor-version bump between 7.3 and 7.4 libpq.so
> have prevented the dynamic linker from accepting the 7.3 libpq.so as
> the one to use? I thought the rule was "same major version as
> requested, minor version >= requested".
Maybe, but the directory search orde
[snip]
> The problem was that the new psql was linking to an older version of
> libpq.so (one that doesn't export get_progname()). As best I can tell
> that would have had to be a 7.3 libpq.so, which means there is something
> wrong here because the 7.3 libpq should have had a different minor
> nu
