Bad link Makefile patch
I built the v8.0.3 product from postgresql-8.0.3-1PGDG.src.rpm on
RedHat9 (I'm thinking the source RPM for RH9 should not have exactly the
same name as the FC3 version, since they are different files). When I
tried to roll it into an RPM CD builder transaction, I got 'RPM
dependency errors': "CRITICAL ERROR: Unable to resolve dependency
libecpg.so.3 for postgresql-libs" and "CRITICAL ERROR: Unable to resolve
dependency libpq.so.3 for postgresql-libs". I was only including the
base rpm, -server, and -lib in the RPM transaction set.
The culprit was a nasty bit at $TOP/src/Makefile.shlib:243. This piece
insures that for the link step of libecpg.so.5.0 and
libecpg_compat.so.2.0, /usr/lib is searched for libpq and libecpg.so
_before_ the locally built copy is searched.
At least for libecpg.so.5.0 and libecpg_compat.so.2.0, the attached
patch fixes the problem. Not sure if there would be other instances in
-contrib, etc.
Hope this helps and that I'm not redundant with your other fans.
Regards,
Mark
Attachments:
userlib_link.patchapplication/octet-stream; name=userlib_link.patchDownload+8-4
So, my co-workers chided me mercilessly to get the -contrib RPM working
as well; so the full patch is now attached.
BTW, I did search the archive and this problem did not stick out; but it
could be my crummy reference skills. And, no, I didn't read all 3500
emails since the v8.0.3 release.
Also, there's some good chance that the binary RPMs on the
postgresql.org FTP site have the same flaw that I encountered as
described below.
Regards,
Mark
On Wed, 6 Jul 2005 09:08:50 -0700
Mark Deric <laguna@laguna1.com> wrote:
Show quoted text
I built the v8.0.3 product from postgresql-8.0.3-1PGDG.src.rpm on
RedHat9 (I'm thinking the source RPM for RH9 should not have exactly
the same name as the FC3 version, since they are different files).
When I tried to roll it into an RPM CD builder transaction, I got 'RPM
dependency errors': "CRITICAL ERROR: Unable to resolve dependency
libecpg.so.3 for postgresql-libs" and "CRITICAL ERROR: Unable to
resolve dependency libpq.so.3 for postgresql-libs". I was only
including the base rpm, -server, and -lib in the RPM transaction set.The culprit was a nasty bit at $TOP/src/Makefile.shlib:243. This
piece insures that for the link step of libecpg.so.5.0 and
libecpg_compat.so.2.0, /usr/lib is searched for libpq and libecpg.so
_before_ the locally built copy is searched.At least for libecpg.so.5.0 and libecpg_compat.so.2.0, the attached
patch fixes the problem. Not sure if there would be other instances
in-contrib, etc.Hope this helps and that I'm not redundant with your other fans.
Regards,
Mark
Attachments:
userlib_link.patchapplication/octet-stream; name=userlib_link.patchDownload+11-5
Mark Deric <laguna@laguna1.com> writes:
So, my co-workers chided me mercilessly to get the -contrib RPM working
as well; so the full patch is now attached.
I think this overlaps or may be redundant with the patch that Peter E.
recently proposed; have you been following the thread about buildfarm
failures?
http://archives.postgresql.org/pgsql-hackers/2005-07/msg00178.php
regards, tom lane
Tom Lane wrote:
Mark Deric <laguna@laguna1.com> writes:
So, my co-workers chided me mercilessly to get the -contrib RPM working
as well; so the full patch is now attached.I think this overlaps or may be redundant with the patch that Peter E.
recently proposed; have you been following the thread about buildfarm
failures?http://archives.postgresql.org/pgsql-hackers/2005-07/msg00178.php
I am going to assume this issue was resolved by Peter's patch.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073