Re: [HACKERS] PostgreSQL10 beta2 with ICU - initdb fails on MacOS - Mailing list pgsql-hackers
From | Sandeep Thakkar |
---|---|
Subject | Re: [HACKERS] PostgreSQL10 beta2 with ICU - initdb fails on MacOS |
Date | |
Msg-id | CANFyU96DhRC=kx=EzReHoePkKmVAcBiwAGmaSGj6q_kzFy0cLQ@mail.gmail.com Whole thread Raw |
In response to | Re: [HACKERS] PostgreSQL10 beta2 with ICU - initdb fails on MacOS (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: [HACKERS] PostgreSQL10 beta2 with ICU - initdb fails on MacOS
(Tom Lane <tgl@sss.pgh.pa.us>)
|
List | pgsql-hackers |
On Thu, Jul 13, 2017 at 12:44 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Sandeep Thakkar <sandeep.thakkar@enterprisedb.com> writes:
> On Wed, Jul 12, 2017 at 8:13 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Ugh. Please provide details about the hand-built ICU --- what version,
>> what configure options did you use for it, etc.
> I tried with ICU 53.1 and 57.1 and the results is same.
> There was no configure options other than --prefix.
Well, when I try that on macOS, I get an ICU installation that's basically
nonfunctional, apparently because they forgot to specify -install_name
while linking the dylibs. The symptom looks a bit different:
$ initdb
dyld: Library not loaded: libicui18n.57.dylib
Referenced from: /Users/tgl/testversion/bin/postgres
Reason: image not found
but it's clear from otool that the dynamic linker doesn't know where
to find the ICU libraries:
$ otool -L ~/testversion/bin/postgres
/Users/tgl/testversion/bin/postgres:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.60.2)
libicui18n.57.dylib (compatibility version 57.0.0, current version 57.1.0)
libicuuc.57.dylib (compatibility version 57.0.0, current version 57.1.0)
and this is evidently because the libraries themselves don't know where
they live:
$ otool -D /usr/local/icu-57.1/lib/libicui18n.57.dylib
/usr/local/icu-57.1/lib/libicui18n.57.dylib:
libicui18n.57.dylib
Right. I got that and I fixed the names and loader_paths for ICU libs and postgres and that is why initdb in my case got going and didn't complain about library not found.
Compare to what you get for a properly built dylib:
$ otool -D /usr/local/ssl-1.1.0e/lib/libssl.1.1.dylib
/usr/local/ssl-1.1.0e/lib/libssl.1.1.dylib:
/usr/local/ssl-1.1.0e/lib/libssl.1.1.dylib
I can make it work by setting DYLD_LIBRARY_PATH:
$ DYLD_LIBRARY_PATH=/usr/local/icu-57.1/lib initdb
... goes through normally ...
You mean you are able to initialize cluster after this? Or you just executed initdb and found that it doesn't complain about ICU lib location? As mentioned above instead of using DYLD_LIBRARY_PATH, I fixed the loader_paths and am able to execute initdb and postgres binaries:
$ ./initdb -V
initdb (PostgreSQL) 10beta2
$ ./postgres -V
postgres (PostgreSQL) 10beta2
But, initdb -D data fails with error code "U_FILE_ACCESS_ERROR".
but that hardly qualifies as a production-grade solution.
I've not dug into the ICU sources to see what it would take to get the
correct link option applied. But the short answer seems to be that ICU
is not up to speed for installation in non-default locations on macOS.
For the record's sake, I configured icu4c-57_1-src.tgz like this:
$ ./runConfigureICU MacOSX --prefix=/usr/local/icu-57.1
and since there's no pkg-config on this machine, I did this to
configure Postgres:
$ ICU_CFLAGS=" " ICU_LIBS="-licui18n -licuuc -licudata" ./configure [usual options] --with-icu --with-includes=/usr/local/icu-57.1/include --with-libraries=/usr/local/ icu-57.1/lib
It's possible that if I did have pkg-config installed, it would have
produced some different value for ICU_LIBS, but I rather doubt it.
I'm not sure that it's possible to fix this on the consumer executable's
link line anyway.
yes, we use the same flags during configure.
regards, tom lane
Sandeep Thakkar
EDB
pgsql-hackers by date: