Re: PostgreSQL10 beta2 with ICU - initdb fails on MacOS

On Thu, Jul 13, 2017 at 12:44 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Sandeep Thakkar <sandeep(dot)thakkar(at)enterprisedb(dot)com> writes:
> > On Wed, Jul 12, 2017 at 8:13 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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