Thread: postgres 7.2 make check problem
I am upgrading from 7.1 -> 7.2 ./configure --enable-multibyte=UNICODE make make check ============== creating temporary installation ============== ============== initializing database system ============== pg_regress: initdb failed Examine ./log/initdb.log for the reason. make[2]: *** [check] Error 2 make[2]: Leaving directory `/usr/src/postgresql-7.2/src/test/regress' make[1]: *** [check] Error 2 make[1]: Leaving directory `/usr/src/postgresql-7.2/src/test' make: *** [check] Error 2 contents of log Running with noclean mode on. Mistakes will not be cleaned up. /usr/src/postgresql-7.2/src/test/regress/./tmp_check/install//usr/loca l/pgsql/bi n/pg_encoding: error while loading shared libraries: /usr/src/postgresql-7.2/src /test/regress/./tmp_check/install//usr/local/pgsql/bin/pg_encoding: undefined sy mbol: pg_char_to_encoding initdb: pg_encoding failed Perhaps you did not configure PostgreSQL for multibyte support or the program was not successfully installed. Ok, so what's wrong? I haven't a clue. It appears to me that this should go smoothly. What more information would be helpful to diagnose the problem? make --version GNU Make version 3.79.1 gcc --version 2.95.3 uname -a Linux 2.4.17.4 #3 SMP Tue Mar 5 15:27:54 PST 2002 i686 unknown Michael Michael@Insulin-Pumpers.org Michael@Insulin-Pumpers.org
"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
On Sun, 10 Mar 2002, Tom Lane wrote: > "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.) > That's right. The old version is not mulitbyte and the new one needs to be for newer applications that require UNICODE. > > 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. > Well..... my solution was to do make install make check I've already done data dump, I can always go back and reinstall the older version. That seems to have worked. I still must check that the applications all work ok. Michael