Stubborn Multibyte

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

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

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.

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