Thread: Stubborn Multibyte

I am working for a company in Japan.  I have two RedHat 6.1J machines that I
want Postgres on.  On one of them, I installed postgresql 7.0.2 RPMs off of
a CD I received, and everything works fine.  The second (same OS), has given
me nothing but trouble.  I installed the RPMs, and then when I tried to use
"createdb", it protested "MultiByte strings (MB) must be enabled to use this
function".  All the scoop I could find about that talked about
using --enable-multibyte during configure before compilation.  Hmm - can't
do that with an RPM.  So I removed the RPMs, downloaded the source for
7.1.1, configured, compiled, and installed, dutifully following the
instructions in postgresql.org's multibyte.html document.  These are the
commands I used:
   ./configure --enable-multibyte=EUC_JP --with-perl --with-odbc
   make
   make install
   su postgres
   /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data -E EUC_JP
   /usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data

Up to that point, everything was fine, except that the installation
instructions seem to think that /usr/local/pgsql/bin would somehow be added
to $PATH (all the examples of using commands specify no path).  But then,
the first time I tried createdb, it said "/usr/bin/postgres: cannot locate
executable" - why it wasn't looking in /usr/local/pgsql/bin I don't know.
So I copied /usr/local/pgsql/bin/postgres to /usr/bin - if that is a bad
idea, someone let me know (I figure when I have to do hacks like copying
files and adding things to $PATH after installation, something went wrong,
but...).  Then I tried createdb again, and got the same message as with the
RPMs - "MultiByte strings (MB) must be enabled to use this function"!  Argh!

Does somebody have any idea what is going wrong?

Thanks in advance for any help.

--------------------------------
Karen Ellrick
S & C Technology, Inc.
1-21-35 Kusatsu-shinmachi
Hiroshima  733-0834  Japan
(from U.S. 011-81, from Japan 0) 82-293-2838
--------------------------------

Update on my problem: I had another machine waiting in the wings, that would
eventually replace the one I am having trouble with regarding the multibyte
complaint.  I decided to try installing PostgreSQL 7.1.1 on that one, and it
worked.  So if I can get everything else working on the new machine, I will
just swap it out and ignore the fact that the present machine is being
mysteriously stubborn about multibyte errors.

However, on the new machine (which is also RedHat 6.1J), when I tried my
tried-and-true sequence of configuring/compiling/installing the combination
of Apache and PHP4 with related PostgreSQL files, I ran into a different
problem.  This is my sequence, after untarring all three packages
(theoretically it doesn't matter whether I install pgsql first or last, as
long as the untarred directory is there):
   cd apache_1.3.17
   ./configure –-prefix=/usr/apache
   cd ../php-4.0


 ./configure –-with-apache=../apache_1.3.17 –-with-pgsql=../postgresql-7.1.1
   make
   make install
   cd ../apache_1.3.17



./configure –-prefix=/usr/apache –-activate-module=src/modules/php4/libphp4.
a
   make
   make install

But this time (never before on two other machines) I get the following error
during PHP's make:
   In file included from pgsql.c:29:
   php_pgsql.h:32: postgres.h: No such file or directory

Anyone done this before, and had this message?  I am using the same tarballs
for PHP and Apache that I used on the previous two installations.  After it
failed the first time, I even tried untarring the previously used tarball
for postgresql (7.0.2) and pointing to it during configure, but the same
error appeared.  There are no shortage of files called postgres.h on the
machine, but I don't know where it is looking, and I don't think I should
have to start disecting the Makefile.  It worked before, so it shouldn't be
a typo or incompatibility, should it?

--------------------------------
Karen Ellrick
S & C Technology, Inc.
1-21-35 Kusatsu-shinmachi
Hiroshima  733-0834  Japan
(from U.S. 011-81, from Japan 0) 82-293-2838
--------------------------------

On Wed, 23 May 2001, Karen Ellrick wrote:


> during PHP's make:
>    In file included from pgsql.c:29:
>    php_pgsql.h:32: postgres.h: No such file or directory
>
> Anyone done this before, and had this message?  I am using the same tarballs
> for PHP and Apache that I used on the previous two installations.  After it
> failed the first time, I even tried untarring the previously used tarball
> for postgresql (7.0.2) and pointing to it during configure, but the same
> error appeared.  There are no shortage of files called postgres.h on the
> machine, but I don't know where it is looking, and I don't think I should
> have to start disecting the Makefile.  It worked before, so it shouldn't be
> a typo or incompatibility, should it?
>
I think a quick solution would be to include the directory where
postgres.h resides to path. It is by no means an answer to the problem but
should help if you just need things to work.

eg. export PATH=/usr/local/postgres/include:$PATH
    replace /usr/local/postgres/include with the path to postgres.h

- Einar Karttunen

I gave up on 7.1.1 for now, although that is not ideal.  I looked around the
web some more, and saw a recommendation to someone who was using RPMs for
postgresql and had the same problem, saying to install the postgresql-devel
RPM as well.  I don't know how to do that with compiled source, but I then
realized that my successful installs have always been after a full set of
7.0.2 RPMs were already installed.  I tried a 7.1.1 RPM I found on
rpmfind.net, but it complained that it needed about 30 files I did not have.
So I just loaded the same old 7.0.2 RPMs I used before, and it all seems to
work (haven't made the database yet or tried to connect to the web serv.
Why I can't do it with compiled source, why my other machine complained of
disabled multibyte, and whether I will run into any of the bugs fixed in
7.1.1 will remain mysteries.

Now I have one more brand new thing I am seeing.  When I run psql or
createdb, I get a bunch of extra stuff on the screen at startup, \q time,
and any non-help command (including everything little thing it does to
process my request - a \d on an empty db gives me two full screenfuls of sql
and other stuff before saying "no relations").  It's like I have some
super-verbose switch turned on somewhere.  On startup, the first one is:
   010523.20:30:28.625 [14996] read_pg_options: verbose=2,query=2,syslog=0
...which I thought was a clue (the verbose level), but looking at my other
working installation, the pg_options file has the exact same parameters,
including verbose=2, and it doesn't spew all that stuff at me.  Any clues?

--------------------------------
Karen Ellrick
S & C Technology, Inc.
1-21-35 Kusatsu-shinmachi
Hiroshima  733-0834  Japan
(from U.S. 011-81, from Japan 0) 82-293-2838
--------------------------------

> -----Original Message-----
> From: pgsql-general-owner@postgresql.org
> [mailto:pgsql-general-owner@postgresql.org]On Behalf Of Einar Karttunen
> Sent: Wednesday, May 23, 2001 7:19 PM
> To: Karen Ellrick
> Cc: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] Install with Apache/PHP (Was "Stubborn Multibyte")
>
>
> On Wed, 23 May 2001, Karen Ellrick wrote:
>
>
> > during PHP's make:
> >    In file included from pgsql.c:29:
> >    php_pgsql.h:32: postgres.h: No such file or directory
> >
> > Anyone done this before, and had this message?  I am using the
> same tarballs
> > for PHP and Apache that I used on the previous two
> installations.  After it
> > failed the first time, I even tried untarring the previously
> used tarball
> > for postgresql (7.0.2) and pointing to it during configure, but the same
> > error appeared.  There are no shortage of files called postgres.h on the
> > machine, but I don't know where it is looking, and I don't
> think I should
> > have to start disecting the Makefile.  It worked before, so it
> shouldn't be
> > a typo or incompatibility, should it?
> >
> I think a quick solution would be to include the directory where
> postgres.h resides to path. It is by no means an answer to the problem but
> should help if you just need things to work.
>
> eg. export PATH=/usr/local/postgres/include:$PATH
>     replace /usr/local/postgres/include with the path to postgres.h
>
> - Einar Karttunen
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster

On Wed, 23 May 2001, Karen Ellrick wrote:

> I gave up on 7.1.1 for now, although that is not ideal.  I looked around the
> web some more, and saw a recommendation to someone who was using RPMs for
> postgresql and had the same problem, saying to install the postgresql-devel
> RPM as well.  I don't know how to do that with compiled source, but I then
> realized that my successful installs have always been after a full set of
> 7.0.2 RPMs were already installed.  I tried a 7.1.1 RPM I found on
> rpmfind.net, but it complained that it needed about 30 files I did not have.
> So I just loaded the same old 7.0.2 RPMs I used before, and it all seems to
> work (haven't made the database yet or tried to connect to the web serv.
> Why I can't do it with compiled source, why my other machine complained of
> disabled multibyte, and whether I will run into any of the bugs fixed in
> 7.1.1 will remain mysteries.

7.1.2 will/should be out soon.  Rather than searching out rpms that
may or may not work, why don't you try building from the source?  The
instructions for doing it are very simple and you could probably do it
in your sleep.  At least that way you'll know what you have and if you
still have problems you'll be starting from a known good starting point.

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net
         56K Nationwide Dialup from $16.00/mo at Pop4 Networking
        Online Campground Directory    http://www.camping-usa.com
       Online Giftshop Superstore    http://www.cloudninegifts.com
==========================================================================

Hi Karen,

It wouldn't hurt to update to at least PHP 4.0.5, as it fixes a bunch of
bugs, and also knows about the changes in the PostgreSQL naming of
include files, etc.

:-)

Apache 1.3.20 is also available last I checked too.

:-)

Regards and best wishes,

Justin Clift

Karen Ellrick wrote:
>
> Update on my problem: I had another machine waiting in the wings, that would
> eventually replace the one I am having trouble with regarding the multibyte
> complaint.  I decided to try installing PostgreSQL 7.1.1 on that one, and it
> worked.  So if I can get everything else working on the new machine, I will
> just swap it out and ignore the fact that the present machine is being
> mysteriously stubborn about multibyte errors.
>
> However, on the new machine (which is also RedHat 6.1J), when I tried my
> tried-and-true sequence of configuring/compiling/installing the combination
> of Apache and PHP4 with related PostgreSQL files, I ran into a different
> problem.  This is my sequence, after untarring all three packages
> (theoretically it doesn't matter whether I install pgsql first or last, as
> long as the untarred directory is there):
>    cd apache_1.3.17
>    ./configure --prefix=/usr/apache
>    cd ../php-4.0
>
>  ./configure --with-apache=../apache_1.3.17 --with-pgsql=../postgresql-7.1.1
>    make
>    make install
>    cd ../apache_1.3.17
>
> ./configure --prefix=/usr/apache --activate-module=src/modules/php4/libphp4.
> a
>    make
>    make install
>
> But this time (never before on two other machines) I get the following error
> during PHP's make:
>    In file included from pgsql.c:29:
>    php_pgsql.h:32: postgres.h: No such file or directory
>
> Anyone done this before, and had this message?  I am using the same tarballs
> for PHP and Apache that I used on the previous two installations.  After it
> failed the first time, I even tried untarring the previously used tarball
> for postgresql (7.0.2) and pointing to it during configure, but the same
> error appeared.  There are no shortage of files called postgres.h on the
> machine, but I don't know where it is looking, and I don't think I should
> have to start disecting the Makefile.  It worked before, so it shouldn't be
> a typo or incompatibility, should it?
>
> --------------------------------
> Karen Ellrick
> S & C Technology, Inc.
> 1-21-35 Kusatsu-shinmachi
> Hiroshima  733-0834  Japan
> (from U.S. 011-81, from Japan 0) 82-293-2838
> --------------------------------
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
     - Indira Gandhi

"Karen Ellrick" <k-ellrick@sctech.co.jp> writes:
> But this time (never before on two other machines) I get the following error
> during PHP's make:
>    In file included from pgsql.c:29:
>    php_pgsql.h:32: postgres.h: No such file or directory

Remove the unnecessary include of postgres.h in php_pgsql.h.  Or update
to a more recent version of PHP --- I know they fixed this in their CVS
awhile ago, hopefully there is a release with the fix in place by now...

            regards, tom lane

Hi everyone!

Thanks to various people for advice, including many answers from Vince
"off-line" while I was at home (whose address isn't a member of this mailing
list).  I cleaned up my directories as best I could, downloaded the newest
versions of everything, and took various pieces of advice about
configuration options, and finally it all worked.  For the record, in case
someone else has trouble with this apparently touchy combination of
programs, this is the sequence I used (for my needs - others may need
different options):

   cd postgresql-7.1.1



./configure --enable-multibyte=EUC_JP --with-perl --enable-odbc --enable-sys
log
   make
   make install
   cd ../apache_1.3.20
   ./configure --server-uid=httpd --server-gid=httpd
   make
   cd ../php-4.0.5
   ./configure --without-mysql --with-pgsql --with-apache=../apache_1.3.20
   make
   make install
   cd ../apache_1.3.20



./configure --activate-module=src/modules/php4/libphp4.a --server-uid=httpd
--server-gid=httpd
   make
   make install

I'm not sure if the make after the first configure of Apache is needed or
not, but Vince said "build" and "rebuild", so I took that to mean both
configure and make.  I did have to add /usr/local/pgsql/bin to $PATH - many
instructions I have seen seem to think it will already be there, but not on
my system.  Some important clues I learned are:
   * It's best to let PostgreSQL install into the default /usr/local/pgsql,
and then PHP can find everything with no pgsql directory specified.
   * Even if it has only been a couple months since the last time you did an
install, if you use a new version of one of the programs, get the newest of
all of them.

Hopes this will save a newbie some time and stress someday.

Karen

--------------------------------
Karen Ellrick
S & C Technology, Inc.
1-21-35 Kusatsu-shinmachi
Hiroshima  733-0834  Japan
(from U.S. 011-81, from Japan 0) 82-293-2838
--------------------------------

In article <GAELLCMOCEGMDMHDMIILAEONCHAA.k-ellrick@sctech.co.jp>, "Karen
Ellrick" <k-ellrick@sctech.co.jp> wrote:

    If you are building PostgreSQL on a system which already has an
ealier version of PostgreSQL installed using RPMs, I recommend that
you not build into the same directories that the RPMs install into. There
are two reasons for this:

    1. Having the two versions in different directories allows you to
choose between them while you're transitioning

    2. When you remove the old RPMs later, rpm won't remove
your new installation.

    If you're seeing mysterious problems with your new build, it
will probably work better if you rebuild after removing the old
postresql-devel RPM.

> I gave up on 7.1.1 for now, although that is not ideal.  I looked around
> the web some more, and saw a recommendation to someone who was using
> RPMs for postgresql and had the same problem, saying to install the