"Michael" <michael@insulin-pumpers.org> writes:
> I am upgrading from 7.1 -> 7.2
> ./configure --enable-multibyte=UNICODE
Was your 7.1 installation built with multibyte support?
(I'm betting not.)
> make check
> /test/regress/./tmp_check/install//usr/local/pgsql/bin/pg_encoding:
> undefined sy mbol: pg_char_to_encoding initdb: pg_encoding failed
I believe what is happening here is that the dynamic loader is trying
to link to the installed version of libpq.so (viz, your 7.1 version,
which I'm guessing has no multibyte support) instead of the newly
built version that's been placed in the temporary installation.
pg_regress tries to override the dynamic loader's search path by setting
LD_LIBRARY_PATH, but that does not work on all platforms. In
particular, on Linux I believe the RPATH information placed into the
executables takes precedence over LD_LIBRARY_PATH. So, because you've
got already-installed libraries sitting at the same place where the
7.2 libraries will ultimately be installed, those get picked up in
preference to the right ones.
This is pretty much a catch-22 situation :-(. AFAICS the only way we
could make pre-installation "make check" proof against this problem on
Linux is to not set RPATH in the executables; which would certainly make
the finished installation less reliable, so it seems like a bad idea
to do it just to make "make check" work.
If you've got an idea how to get around this problem we'd love to hear
about it. In the meantime I think you will have to install at least the
multibyte-aware libpq.so before you can do "make check". Or, if you are
feeling too paranoid to do that, you could rebuild 7.2 with a --prefix
pointing to someplace different than where 7.1 is installed, so that the
RPATH search doesn't find the 7.1 library.
regards, tom lane
