Re: PostgreSQL10 beta2 with ICU - initdb fails on MacOS

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

> Sandeep Thakkar <sandeep(dot)thakkar(at)enterprisedb(dot)com> writes:
> > On Thu, Jul 13, 2017 at 12:44 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> 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.
>
> Uh, so what did you do *exactly*?
>
> I changed the id and the loader_paths for ICU libs and also changed the
install name of ICU libs on postgres binary
$ otool -L postgres | grep icu
@loader_path/../lib/libicuuc.57.dylib (compatibility version 57.0.0,
current version 57.1.0)
@loader_path/../lib/libicui18n.57.dylib (compatibility version 57.0.0,
current version 57.1.0)

> >> 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?
>
> initdb completed successfully. I didn't try running any tests beyond
> that; I'm not sure that we have any regression tests that will exercise
> ICU locales.
>
> OK. I'll check at my end then.

> > As mentioned above instead of using DYLD_LIBRARY_PATH, I fixed the
> > loader_paths and am able to execute initdb and postgres binaries:
> > But, initdb -D data fails with error code "U_FILE_ACCESS_ERROR".
>
> Yeah, but notice that only two of the three interesting ICU libraries
> are actually linked into the postgres executable so far as otool and
> the dynamic linker are concerned. I suspect that the other one,
> libicudata, is dynamically loaded by the ICU code --- and in your
> configuration it fails to find that library. The error message is
> not definitive that that's what's happening, but it's suggestive.
> If that's the right interpretation, it means that setting
> DYLD_LIBRARY_PATH allows that third library to be found, but whatever
> you did doesn't.
>
> Yeah, I observed that otool -L lists only two of three ICU libs. But not
sure why it doesn't load the third one in my case. Here is the otool -D and
otool -L output on ICU libs:
$ otool -D ../lib/libicuuc.dylib
../lib/libicuuc.dylib:
libicuuc.57.dylib

$ otool -L ../lib/libicuuc.dylib
../lib/libicuuc.dylib:
libicuuc.57.dylib (compatibility version 57.0.0, current version 57.1.0)
@loader_path/../lib/libicudata.57.dylib (compatibility version 57.0.0,
current version 57.1.0)

$ otool -D ../lib/libicui18n.dylib
../lib/libicui18n.dylib:
libicui18n.57.dylib

$ otool -L ../lib/libicui18n.dylib
../lib/libicui18n.dylib:
libicui18n.57.dylib (compatibility version 57.0.0, current version 57.1.0)
@loader_path/../lib/libicuuc.57.dylib (compatibility version 57.0.0,
current version 57.1.0)
@loader_path/../lib/libicudata.57.dylib (compatibility version 57.0.0,
current version 57.1.0)

$ otool -D ../lib/libicudata.dylib
../lib/libicudata.dylib:
libicudata.57.dylib

$ otool -L ../lib/libicudata.dylib
../lib/libicudata.dylib:
libicudata.57.dylib (compatibility version 57.0.0, current version 57.1.0)

> I still think that this represents under-engineering by the ICU crew
> and not anything we're doing wrong.
>
> BTW, when I skimmed the "readme.html" docs in the ICU sources this
> morning, I noted that there were multiple ways you could configure
> it to find the ICU data. I did not read in detail, figuring that
> their default configuration would be sane, but maybe that was an
> overly charitable assumption.
>
> Sure, thanks for checking this out. It seems the issue is with ICU and
something I did which is why the libicudata.dylib is not able to load. I'll
dig deeper. Thanks for your help.

> regards, tom lane
>

--
Sandeep Thakkar
EDB