Thread: unix socket location confusion
- on OS X 10.10.2 - downloaded 9.3.6 sources - ./configure --with-openssl --prefix=/my/specific/location/pg-9.3 - make & install - cd /my/specific/location/ - pg-9.3/bin/postmaster -D... - socket is created in /tmp, as expected - pg-9.3/bin/psql mydb - gives error about not being able to connect to /var/pgsql_socket/.s.PGSQL.5432 - ??? env shows that I have no PG-related environment variables set; existing postgresql.conf in the data dir does not specifyunix_directories, leaving it at the default /tmp. So why is the freshly-built psql trying to check /var/pgsql_socket/ instead of /tmp? Did it perhaps get linked to a clientdylib from a different build, thanks to Apple's tools using a search path that led outside the build for the libs??? I know how to specify things the way I want, but I thought I'd bring this up because there's a whole ton of confusion onStackOverflow about this issue, with a lot of bad guessing going on. I built from straight-up sources, and I'm specifyingthe paths to the specific executables I want to run, and still seeing the problem. (And, FWIW, I've long had multipleversions of PG built on my system for different projects, and never seen this problem before.) -- Scott Ribe scott_ribe@elevated-dev.com http://www.elevated-dev.com/ https://www.linkedin.com/in/scottribe/ (303) 722-0567 voice
Scott Ribe <scott_ribe@elevated-dev.com> writes:
> - on OS X 10.10.2
> - downloaded 9.3.6 sources
> - ./configure --with-openssl --prefix=/my/specific/location/pg-9.3
> - make & install
> - cd /my/specific/location/
> - pg-9.3/bin/postmaster -D...
> - socket is created in /tmp, as expected
> - pg-9.3/bin/psql mydb
> - gives error about not being able to connect to /var/pgsql_socket/.s.PGSQL.5432
> - ???
OS X ships with a libpq that's configured that way:
$ ls -l /usr/lib/libpq*
-rwxr-xr-x 1 root wheel 155696 Sep 9 2014 /usr/lib/libpq.5.5.dylib
lrwxr-xr-x 1 root wheel 15 Oct 18 13:00 /usr/lib/libpq.5.dylib -> libpq.5.5.dylib
lrwxr-xr-x 1 root wheel 15 Oct 18 13:00 /usr/lib/libpq.dylib -> libpq.5.5.dylib
$ strings /usr/lib/libpq.5.5.dylib | grep var
/var/pgsql_socket
$ strings /usr/lib/libpq.5.5.dylib | grep tmp
$
Evidently your psql is linking to this libpq and not the one you built.
You can fix that with suitable use of rpath; although I'm not sure why
an out-of-the-box build doesn't do that for you. It works fine for
me:
$ otool -L ~/testversion/bin/psql
/Users/tgl/testversion/bin/psql:
/Users/tgl/testversion/lib/libpq.5.dylib (compatibility version 5.0.0, current version 5.8.0)
/usr/lib/libedit.3.dylib (compatibility version 2.0.0, current version 3.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)
and I don't believe I'm using any nondefault switches to get that.
regards, tom lane
I wrote:
> Evidently your psql is linking to this libpq and not the one you built.
> You can fix that with suitable use of rpath; although I'm not sure why
> an out-of-the-box build doesn't do that for you. It works fine for
> me:
> $ otool -L ~/testversion/bin/psql
> /Users/tgl/testversion/bin/psql:
> /Users/tgl/testversion/lib/libpq.5.dylib (compatibility version 5.0.0, current version 5.8.0)
> /usr/lib/libedit.3.dylib (compatibility version 2.0.0, current version 3.0.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)
> and I don't believe I'm using any nondefault switches to get that.
I poked around a bit more and remembered what it is that makes it work:
you need an -install_name switch when building libpq.dylib (and then the
link of psql has to be sure to reference that .dylib file). For example
I see this as part of the libpq link step:
-install_name '/Users/tgl/testversion/lib/libpq.5.dylib'
after having configured with "--prefix=/Users/tgl/testversion".
So this works only if your libpq.dylib is actually installed at the
location that was expected when you built it. The recipe you gave
looks like it should have done that, but I'm suspicious that the
answer is somewhere near here.
regards, tom lane
On Mar 22, 2015, at 4:43 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > So this works only if your libpq.dylib is actually installed at the > location that was expected when you built it. The recipe you gave > looks like it should have done that, but I'm suspicious that the > answer is somewhere near here. Oh, take me out back and shoot me now ;-) The one step I left out of my description of the process was the one immediately after make install where I decided I didnot like the name of the folder I had built into, and re-named it. I am surprised though, that with a full path to libpq,when that path does not exist, the loader searches and finds a system lib instead of just failing. It's questionable whether the PG executables should be built with full or relative paths to the libs, both have their owndisadvantages. But might be worth considering --relative-rpath someday? Or an option to link the frickin' static librariesin and avoid the whole issue of mismatches. -- Scott Ribe scott_ribe@elevated-dev.com http://www.elevated-dev.com/ https://www.linkedin.com/in/scottribe/ (303) 722-0567 voice
Scott Ribe <scott_ribe@elevated-dev.com> writes:
> On Mar 22, 2015, at 4:43 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> So this works only if your libpq.dylib is actually installed at the
>> location that was expected when you built it. The recipe you gave
>> looks like it should have done that, but I'm suspicious that the
>> answer is somewhere near here.
> Oh, take me out back and shoot me now ;-)
Uh huh :-(
> It's questionable whether the PG executables should be built with full or relative paths to the libs, both have their
owndisadvantages. But might be worth considering --relative-rpath someday? Or an option to link the frickin' static
librariesin and avoid the whole issue of mismatches.
We're entirely at the mercy of the platform's dynamic loader when it comes
to things like this. I don't think I trust Darwin's loader with relative
paths; though come to think of it, Linux's loader may be no better. Way
too many opportunities to screw up there.
As for static libraries, there are good reasons why those aren't superior
solutions. Red Hat for instance has a blanket policy against shipping
static libraries (with only very narrow exceptions), and I believe the
same is true of many other vendors.
regards, tom lane
On Mar 22, 2015, at 10:54 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > We're entirely at the mercy of the platform's dynamic loader when it comes > to things like this. I don't think I trust Darwin's loader with relative > paths; though come to think of it, Linux's loader may be no better. Way > too many opportunities to screw up there. It actually does work, I've used it. But I never found any documentation about it, and it was a damned PITA to figure out. > As for static libraries, there are good reasons why those aren't superior > solutions. Red Hat for instance has a blanket policy against shipping > static libraries (with only very narrow exceptions), and I believe the > same is true of many other vendors. Yep. Good & bad both ways. Anyway, I clearly need to not nest specific version builds with the dbs that use that version. I need to build all versionsinto /usr/local/pgsql-XYZ and then symlink as needed. -- Scott Ribe scott_ribe@elevated-dev.com http://www.elevated-dev.com/ https://www.linkedin.com/in/scottribe/ (303) 722-0567 voice