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 CANFyU96g2G1PxN+s8k1AXme__wqCRbNi4eS8HyGXGabchPca-Q@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>)
List pgsql-hackers


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


pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: [HACKERS] building libpq.a static library
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] PostgreSQL10 beta2 with ICU - initdb fails on MacOS