Обсуждение: problem with RH7.3 Pg7.3.4 binaries
(Not sure if hackers is the right place for this, but I'm not subscribed to all the lists!) The distributed 7.3.4 RPMs for RH 7.3 require libcrypto.so.3 and libssl.so.3, but there does not appear to be any official RH update for 7.3 containing these libs. I do have the latest RH openssl updates installed, but it only provides libssl.so.2 and libcrypto.so.2 and many many things break if I attempt to upgrade :-(, which is presumably why RH chose to backpatch security fixes rather than upgrade for this platform. I know building RPMs can be a major pain, but ISTM that builds should be published that don't break on vanilla installations. I'm prepared to help with fixing this if necessary. For now I've upgraded to 7.3.3 (the RPMs for this don't suffer the same problem on RH7.3). cheers andrew
Andrew Dunstan wrote: > I know building RPMs can be a major pain, but ISTM that builds should be > published that don't break on vanilla installations. I'm prepared to > help with fixing this if necessary. For now I've upgraded to 7.3.3 (the > RPMs for this don't suffer the same problem on RH7.3). > Sorry, that's my fault, not Lamar's. I built the 7.3 RPMs for him. Unfortunately I don't have a plain vanilla installation available -- I had forgotten that I upgraded ssl to something non-standard :( Perhaps if you have a vanilla 7.3 machine available, you could build new 7.3 RPMs from the source RPM and give them to Lamar for distribution? Joe
On Monday 04 August 2003 11:53, Joe Conway wrote: > Andrew Dunstan wrote: > > I know building RPMs can be a major pain, but ISTM that builds should be > > published that don't break on vanilla installations. I'm prepared to > > help with fixing this if necessary. For now I've upgraded to 7.3.3 (the > > RPMs for this don't suffer the same problem on RH7.3). > Sorry, that's my fault, not Lamar's. I built the 7.3 RPMs for him. > Unfortunately I don't have a plain vanilla installation available -- I > had forgotten that I upgraded ssl to something non-standard :( > Perhaps if you have a vanilla 7.3 machine available, you could build new > 7.3 RPMs from the source RPM and give them to Lamar for distribution? Until vanilla-built RH7.3 RPMs are available, I've removed them from the FTP site. I don't have an RH7.3 installation readily available for building. Joe, the RHAS binaries won't have this problem, right? To prevent this in the future, I'm going to state that anyone who wants to build RPMs for distribution needs to do so with a fully up to date vanilla installation of the target OS. Since I do this myself for whatever RPMs I'm personally building, it was an easy assumption to make that everyone would do this. My apologies. A minor rant: I seem to vacillate between providing only one set of RPMs versus providing whatever sets people can build for me. There is a definite tradeoff between having lots of sets available and having only good sets available. While I do my best to ensure only good sets are available, I am not able to test every set that is built. That is one reason I've not begun GPG-signing my RPMs -- if you want certified RPMs build them yourself. It isn't that hard. And when people are so impatient for RPMsets, then complain that the set didn't work -- well, it isn't the most encouraging thing in the world. You want guaranteed RPMs that will install on your machine the day of the release? You have three choices: build them yourself, pay someone to build them, or wait until the official set is available. My rate for building RPMs under those conditions is $100 per hour. (and I have been paid that rate before.) But the official set will only get uploaded once I've had the time to build it and test it. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute
Lamar Owen wrote: > Joe, the RHAS binaries won't have this problem, right? I don't think so -- the server I built those on is very much vanilla RHAS. But then this raises a question in my mind -- is vanilla a fully updated vanilla or "off the original CDs" vanilla? > To prevent this in the future, I'm going to state that anyone who wants to > build RPMs for distribution needs to do so with a fully up to date vanilla > installation of the target OS. Since I do this myself for whatever RPMs I'm > personally building, it was an easy assumption to make that everyone would do > this. My apologies. Sorry -- I'll be more cognizant of that in the future. Joe
On Monday 04 August 2003 13:00, Joe Conway wrote: > I don't think so -- the server I built those on is very much vanilla > RHAS. But then this raises a question in my mind -- is vanilla a fully > updated vanilla or "off the original CDs" vanilla? I've thus far used the definition that it is a fully-updated install, using the OS vendor's update packages that are dependencies of PostgreSQL. Updating to, say, a later KDE, or GNUcash, or whatnot is OK. But core libraries that PostgreSQL uses need to stay vanilla-updated. > Sorry -- I'll be more cognizant of that in the future. Hey, don't worry about it. I should have checked: that IS my responsibility. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute
Lamar Owen wrote: > On Monday 04 August 2003 13:00, Joe Conway wrote: > >>I don't think so -- the server I built those on is very much vanilla >>RHAS. But then this raises a question in my mind -- is vanilla a fully >>updated vanilla or "off the original CDs" vanilla? > > I've thus far used the definition that it is a fully-updated install, using > the OS vendor's update packages that are dependencies of PostgreSQL. > Updating to, say, a later KDE, or GNUcash, or whatnot is OK. But core > libraries that PostgreSQL uses need to stay vanilla-updated. I'll have to check, but I'd guess that the RHAS I built on was pretty close to "off the original CDs", i.e. not updated. I'll let you know. Joe
I agree with the definition of "vanilla install" below. I can't use the machine I was upgrading to build, unfortunately. Its a production machine I am prepping, (and is missing stuff the build process needs even if I wanted to monkey with it), which is precisely why I wanted to install from RPMs rather than just saying "screw it" and installing from a source tarball. I will see if I can get the old machine currently mouldering away in my attic to run 7.3 and build with it, maybe some time this week. (It's time like these you appreciate having lots of bandwidth to download ISOs). andrew Lamar Owen wrote: >On Monday 04 August 2003 13:00, Joe Conway wrote: > > >>I don't think so -- the server I built those on is very much vanilla >>RHAS. But then this raises a question in my mind -- is vanilla a fully >>updated vanilla or "off the original CDs" vanilla? >> >> > >I've thus far used the definition that it is a fully-updated install, using >the OS vendor's update packages that are dependencies of PostgreSQL. >Updating to, say, a later KDE, or GNUcash, or whatnot is OK. But core >libraries that PostgreSQL uses need to stay vanilla-updated. > > >
Joe Conway wrote: > Lamar Owen wrote: >> I've thus far used the definition that it is a fully-updated install, >> using the OS vendor's update packages that are dependencies of >> PostgreSQL. Updating to, say, a later KDE, or GNUcash, or whatnot is >> OK. But core libraries that PostgreSQL uses need to stay >> vanilla-updated. > > I'll have to check, but I'd guess that the RHAS I built on was pretty > close to "off the original CDs", i.e. not updated. I'll let you know. I just checked, and the RHAS that I built the RPMs on is pretty close to original, other than kernel and some driver updates. I'll let you decide whether to pull them or not, but they don't meet your "fully-updated install" criterion. Joe
On Monday 04 August 2003 13:57, Joe Conway wrote: > I just checked, and the RHAS that I built the RPMs on is pretty close to > original, other than kernel and some driver updates. I'll let you decide > whether to pull them or not, but they don't meet your "fully-updated > install" criterion. Hmmm... Tough call, but I think I'll leave them be, since they will install on a fully-updated installation. Although I can't imagine an RHAS install not updated, but that's a different topic. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute
Hi there, I have a RedHat 7.3 machine that can build the 7.3.4 RPMs if required - it only contains RPMs from the vanilla CD or from updates.redhat.com. I've just done a test build and everything seems OK except that the C compiler is passed the -mcpu=i686 flag - I'm guessing I need to somehow change this to i386 so it will binaries will run on actual i386 machines? Can someone point me in the right direction? Cheers, Mark. --- Mark Cave-Ayland Webbased Ltd. Tamar Science Park Derriford Plymouth PL6 8BX England Tel: +44 (0)1752 764445 Fax: +44 (0)1752 764446 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person.
Mark Cave-Ayland said: > Hi there, > > I have a RedHat 7.3 machine that can build the 7.3.4 RPMs if required - > it only contains RPMs from the vanilla CD or from updates.redhat.com. > I've just done a test build and everything seems OK except that the C > compiler is passed the -mcpu=i686 flag - I'm guessing I need to somehow > change this to i386 so it will binaries will run on actual i386 > machines? Can someone point me in the right direction? > The -mcpu flag doesn't do what you seems to think it does. It still generates i386 compatible code, but favours i686 processor timings etc. > > Cheers, > > Mark. Magnus
Hi Magnus, Thanks for that. I always believed that the mcpu flag could enable a C compiler to generate code that could use the extra instructions on the newer CPUs - perhaps one day I'll get around to reading the documentation ;) Anyway, I've posted the compiled RH 7.3 postgresql-7.3.4 RPMs at http://www.webbased.co.uk/mca/pgsql/. Andrew, if you are satisfied that these work correctly on your RH7.3 install, there is no problem with Lamar placing copies of them on the postgresql website for people to download. Cheers, Mark. --- Mark Cave-Ayland Webbased Ltd. Tamar Science Park Derriford Plymouth PL6 8BX England Tel: +44 (0)1752 764445 Fax: +44 (0)1752 764446 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. > -----Original Message----- > From: Magnus Naeslund(w) [mailto:mag@fbab.net] > Sent: 05 August 2003 10:59 > To: Mark Cave-Ayland > Cc: 'Joe Conway'; 'Andrew Dunstan'; 'Lamar Owen'; 'Postgresql Hackers' > Subject: Re: [HACKERS] problem with RH7.3 Pg7.3.4 binaries > > > > Mark Cave-Ayland said: > > Hi there, > > > > I have a RedHat 7.3 machine that can build the 7.3.4 RPMs > if required > > - it only contains RPMs from the vanilla CD or from > > updates.redhat.com. I've just done a test build and > everything seems > > OK except that the C compiler is passed the -mcpu=i686 flag - I'm > > guessing I need to somehow change this to i386 so it will binaries > > will run on actual i386 machines? Can someone point me in the right > > direction? > > > > The -mcpu flag doesn't do what you seems to think it does. > It still generates i386 compatible code, but favours i686 > processor timings etc. > > > > > Cheers, > > > > Mark. > > > Magnus >
Will check later today.
Extract from man gcc:
-mcpu=cpu-type Tune to cpu-type everything applicable about the generated code, except for the
ABIand the set of available instructions. The choices for cpu-type are i386, i486, i586, i686, pentium,
pentium- mmx, pentiumpro, pentium2, pentium3, pentium4, k6, k6-2, k6-3, athlon, athlon-tbird,
athlon-4,athlon-xp and athlon-mp.
While picking a specific cpu-type will schedule things appropri- ately for that particular chip, the
compilerwill not generate
any code that does not run on the i386 without the -march=cpu-type option being used. i586 is
equivalentto pentium and i686 is equivalent to pentiumpro. k6 and athlon are the AMD chips as
opposedto the Intel ones.
cheers
andrew
----- Original Message -----
From: "Mark Cave-Ayland" <m.cave-ayland@webbased.co.uk>
To: <mag@fbab.net>
Cc: "'Joe Conway'" <mail@joeconway.com>; "'Andrew Dunstan'"
<andrew@dunslane.net>; "'Lamar Owen'" <lowen@pari.edu>; "'Postgresql
Hackers'" <pgsql-hackers@postgresql.org>
Sent: Tuesday, August 05, 2003 6:28 AM
Subject: Re: [HACKERS] problem with RH7.3 Pg7.3.4 binaries
> Hi Magnus,
>
> Thanks for that. I always believed that the mcpu flag could enable a C
> compiler to generate code that could use the extra instructions on the
> newer CPUs - perhaps one day I'll get around to reading the
> documentation ;)
>
> Anyway, I've posted the compiled RH 7.3 postgresql-7.3.4 RPMs at
> http://www.webbased.co.uk/mca/pgsql/. Andrew, if you are satisfied that
> these work correctly on your RH7.3 install, there is no problem with
> Lamar placing copies of them on the postgresql website for people to
> download.
>
>
> Cheers,
>
> Mark.
>
> ---
>
> Mark Cave-Ayland
> Webbased Ltd.
> Tamar Science Park
> Derriford
> Plymouth
> PL6 8BX
> England
>
> Tel: +44 (0)1752 764445
> Fax: +44 (0)1752 764446
>
>
> This email and any attachments are confidential to the intended
> recipient and may also be privileged. If you are not the intended
> recipient please delete it from your system and notify the sender. You
> should not copy it or use it for any purpose nor disclose or distribute
> its contents to any other person.
>
> > -----Original Message-----
> > From: Magnus Naeslund(w) [mailto:mag@fbab.net]
> > Sent: 05 August 2003 10:59
> > To: Mark Cave-Ayland
> > Cc: 'Joe Conway'; 'Andrew Dunstan'; 'Lamar Owen'; 'Postgresql Hackers'
> > Subject: Re: [HACKERS] problem with RH7.3 Pg7.3.4 binaries
> >
> >
> >
> > Mark Cave-Ayland said:
> > > Hi there,
> > >
> > > I have a RedHat 7.3 machine that can build the 7.3.4 RPMs
> > if required
> > > - it only contains RPMs from the vanilla CD or from
> > > updates.redhat.com. I've just done a test build and
> > everything seems
> > > OK except that the C compiler is passed the -mcpu=i686 flag - I'm
> > > guessing I need to somehow change this to i386 so it will binaries
> > > will run on actual i386 machines? Can someone point me in the right
> > > direction?
> > >
> >
> > The -mcpu flag doesn't do what you seems to think it does.
> > It still generates i386 compatible code, but favours i686
> > processor timings etc.
> >
> > >
> > > Cheers,
> > >
> > > Mark.
> >
> >
> > Magnus
> >
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
On Tuesday 05 August 2003 08:14, Andrew Dunstan wrote: > Will check later today. When you do, let me know, so that I can post them. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute
Seems to be OK. See below.
BTW, for those interested, following up a note from Joe Conway I
discovered yesterday the Right Way (tm) to build RPMs (nothing Pg
specific in this). Basically, you set up some rpm macros like this in
~/.rpmmacros: %_topdir %(echo ${HOME}/rpm) %_tmppath %{_topdir}/tmp %packager Your Name
<yourusername@your.org>
and a directory tree something like this under your homedir: rpm rpm/BUILD rpm/RPMS rpm/RPMS/i386 rpm/RPMS/i586
rpm/RPMS/noarchrpm/SOURCES rpm/SPECS rpm/SRPMS rpm/tmp
adjusting the subdirs of RPMS appropriately.
now you can run rpmbuild -ba postgresql-7.3.4-1PGDG.src.rpm
and everything builds nicely (assuming your have the right stuff
installed). No need to build as root (building as root is Evil) nor to
install the source rpm before building.
Now having rescued the boat anchor \b\b\b\b\b\b\b old P1 box from the
attic I need to find a new use for it .....
cheers
andrew
-------------------------
[root@face pgsql]# rpm -Fhv postgresql-*.rpm
Preparing... ###########################################
[100%] 1:postgresql-docs ###########################################
[ 12%] 2:postgresql-jdbc ###########################################
[ 25%] 3:postgresql-libs ###########################################
[ 37%] 4:postgresql ###########################################
[ 50%] 5:postgresql-contrib ###########################################
[ 62%] 6:postgresql-devel ###########################################
[ 75%] 7:postgresql-server ###########################################
[ 87%] 8:postgresql-pl ###########################################
[100%]
[root@face pgsql]# /etc/init.d/postgresql stop [ OK ]
[root@face pgsql]# /etc/init.d/postgresql start
Starting postgresql service: [ OK ]
[root@face pgsql]# su - facedba -c "psql face"
Welcome to psql 7.3.4, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms \h for help with SQL commands \? for help on internal slash commands
\g or terminate with semicolon to execute query \q to quit
face=# select version(); version
-----------------------------------------------------------------PostgreSQL 7.3.4 on i386-redhat-linux-gnu, compiled by
GCC2.96
(1 row)
face=# \q
[root@face pgsql]#
-------------------------------------------------------
Lamar Owen wrote:
>On Tuesday 05 August 2003 08:14, Andrew Dunstan wrote:
>
>
>>Will check later today.
>>
>>
>
>When you do, let me know, so that I can post them.
>
>
BTW, the init file has this:
# chkconfig: - 85 15
I would modestly suggest changing this to something like 81 19. The
reason - these are the same settinga as httpd, and I normally want Pg
started up before the web server and shut down after the web server.
andrew
Andrew Dunstan wrote:
>
> Seems to be OK. See below.
>
> BTW, for those interested, following up a note from Joe Conway I
> discovered yesterday the Right Way (tm) to build RPMs (nothing Pg
> specific in this). Basically, you set up some rpm macros like this in
> ~/.rpmmacros:
> %_topdir %(echo ${HOME}/rpm)
> %_tmppath %{_topdir}/tmp
> %packager Your Name <yourusername@your.org>
> and a directory tree something like this under your homedir:
> rpm
> rpm/BUILD
> rpm/RPMS
> rpm/RPMS/i386
> rpm/RPMS/i586
> rpm/RPMS/noarch
> rpm/SOURCES
> rpm/SPECS
> rpm/SRPMS
> rpm/tmp
> adjusting the subdirs of RPMS appropriately.
>
> now you can run
> rpmbuild -ba postgresql-7.3.4-1PGDG.src.rpm
>
> and everything builds nicely (assuming your have the right stuff
> installed). No need to build as root (building as root is Evil) nor to
> install the source rpm before building.
>
> Now having rescued the boat anchor \b\b\b\b\b\b\b old P1 box from the
> attic I need to find a new use for it .....
>
> cheers
>
> andrew
> -------------------------
>
>
>
> [root@face pgsql]# rpm -Fhv postgresql-*.rpm
> Preparing...
> ########################################### [100%]
> 1:postgresql-docs ###########################################
> [ 12%]
> 2:postgresql-jdbc ###########################################
> [ 25%]
> 3:postgresql-libs ###########################################
> [ 37%]
> 4:postgresql ###########################################
> [ 50%]
> 5:postgresql-contrib ###########################################
> [ 62%]
> 6:postgresql-devel ###########################################
> [ 75%]
> 7:postgresql-server ###########################################
> [ 87%]
> 8:postgresql-pl ###########################################
> [100%]
> [root@face pgsql]# /etc/init.d/postgresql stop
> [ OK ]
> [root@face pgsql]# /etc/init.d/postgresql start
> Starting postgresql service: [ OK ]
> [root@face pgsql]# su - facedba -c "psql face"
> Welcome to psql 7.3.4, the PostgreSQL interactive terminal.
>
> Type: \copyright for distribution terms
> \h for help with SQL commands
> \? for help on internal slash commands
> \g or terminate with semicolon to execute query
> \q to quit
>
> face=# select version();
> version
> -----------------------------------------------------------------
> PostgreSQL 7.3.4 on i386-redhat-linux-gnu, compiled by GCC 2.96
> (1 row)
>
> face=# \q
> [root@face pgsql]#
> -------------------------------------------------------
> Lamar Owen wrote:
>
>> On Tuesday 05 August 2003 08:14, Andrew Dunstan wrote:
>>
>>
>>> Will check later today.
>>>
>>
>>
>> When you do, let me know, so that I can post them.
>>
>>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>