I wrote:
> I still think that this represents under-engineering by the ICU crew
> and not anything we're doing wrong.
After some more examination of their readme.html, I tried this:
$ ./runConfigureICU MacOSX --prefix=/usr/local/icu-57.1 --enable-rpath
and that gave me sane-looking libraries:
$ otool -L /usr/local/icu-57.1/lib/libicui18n.57.1.dylib
/usr/local/icu-57.1/lib/libicui18n.57.1.dylib:
/usr/local/icu-57.1/lib/libicui18n.57.dylib (compatibility version
57.0.0, current version 57.1.0)
/usr/local/icu-57.1/lib/libicuuc.57.dylib (compatibility version
57.0.0, current version 57.1.0)
/usr/local/icu-57.1/lib/libicudata.57.dylib (compatibility version
57.0.0, current version 57.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1238.60.2)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
307.5.0)
--- note that now libicudata is shown as a dependency. And then
configuring Postgres as I showed before leads to executables that
build, and initdb, and pass regression tests, and have a bunch
of ICU entries in pg_collation, without needing to fool with
DYLD_LIBRARY_PATH.
Their configure --help claims
--enable-rpath use rpath when linking default is only if necessary
but apparently that's for small values of "necessary" :-(
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
