Re: [HACKERS] PostgreSQL10 beta2 with ICU - initdb fails on MacOS - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] PostgreSQL10 beta2 with ICU - initdb fails on MacOS
Date
Msg-id 23676.1499886860@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] PostgreSQL10 beta2 with ICU - initdb fails on MacOS  (Sandeep Thakkar)
Responses Re: [HACKERS] PostgreSQL10 beta2 with ICU - initdb fails on MacOS  (Sandeep Thakkar)
List pgsql-hackers
Sandeep Thakkar <> writes:
> On Wed, Jul 12, 2017 at 8:13 PM, Tom Lane <> 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
(compatibilityversion 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

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 ...

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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: [HACKERS] idea: custom log_line_prefix components besidesapplication_name
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Function Volatility and Views Unexpected Behavior