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 <[EMAIL PROTECTED]> wrote: > 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 >
userlib_link.patch
Description: Binary data
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
