Op 4 Feb 2003 (15:12), schreef Jules Alberts <jules(dot)alberts(at)arbodienst-limburg(dot)nl>:
> Op 5 Feb 2003 (0:54), schreef Matthew Horoschun <mhoroschun(at)canprint(dot)com(dot)au>:
> > Hi Jules,
> > On Wednesday, February 5, 2003, at 12:06 AM, Peter De Muer (Work)
> > wrote:
> > > try making a soft link libpq.so.2 to the libpq.so.3 file that comes
> > > with
> > > PHP 7.3.1.
> > >>
> > >> This is a known issue, but the only solution I could google was
> > >> compiling a recent PHP from source or creating a softlink from
> > >> libpq.so.3 to libpq.so.2. I read that the link is a bad solution, but
> > >> I
> > >> really don't like compiling and installing PHP from source.
> > I think he wanted to avoid the soft link (or hard link for that
> > matter)... Its not a neat solution. Generally the whole reason for
> > changing library major numbers it to let the users know that the
> > exports have changed and that you'll need to recompile your client!
> > http://www.postgresql.org/news.php?NewsID=105
> > >> I normally do all my packages with RPM and I'm afraid doing PHP from
> > >> source will mess this up. What will happen if I install PHP 4.3.0 from
> > >> source now, and later do an update on a more recent version with rpm?
> > >> Would I have to deinstall 4.3.0 first? How?
> > You're right. Its good practice to use your package system wherever
> > possible. However, how about using a RPM source package?
> > ftp://ftp.redhat.com/pub/redhat/linux/7.3/en/os/i386/SRPMS/php-4.1.2-
> > 7.src.rpm
> Hello Matthew, thanks for your reaction. Would using a src RPM make any
> difference? I guess I would do a ./configure, make and make install and
> wonder just as much where alle the binaries etc. have ended up as if
> when I had used a tarball source install (pardon my Dutch :-).
> Are applications made ("maked") from source RPMs easier to deinstall as
> apps made from tarball sources?
I tried to do a source install (what I don't really want) of PHP. It
doesn't work, complains about not finding libpq-fe.h, even when I
specify the correct postgresql path. I know there probably is a
solution for this too, but what's next?
Well, life's short and there's a lot of work to do. I'm going back to
7.2 with binary RPMs.
In response to
pgsql-admin by date
|Next:||From: Muhammad Shariq Muzaffar||Date: 2003-02-05 10:10:51|
|Subject: Lock timeout detection in postgres 7.3.1|
|Previous:||From: Yudha Setiawan||Date: 2003-02-05 07:15:00|
|Subject: Script Trigger|
pgsql-php by date
|Next:||From: Martin Marques||Date: 2003-02-05 12:43:31|
|Subject: Re: 7.3.1 BREAKS COMPATIBILITY with the latest PHP4 (due to|
|Previous:||From: Jules Alberts||Date: 2003-02-04 14:12:44|
|Subject: Re: 7.3.1 update gives PHP libpq.so.2 problem|