On Thu, Jul 13, 2017 at 8:23 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Sandeep Thakkar <sandeep.thak...@enterprisedb.com> writes: > > On Thu, Jul 13, 2017 at 12:44 AM, Tom Lane <t...@sss.pgh.pa.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
