Thread: php and pgsql and rpm/compile
I have php installed from rpm. I'm trying to rpm the package php-pgsql-3.0.15.i386.rpm so that I can tie in to the postgres server. It is coming back with a dependency for libpq.so.2.0 I made a softlink to libpq.so.2.1 pointing to libpq.so.2.1, but it still has that dependency. I have /usr/local/pgsql/lib in the ld.so.conf file. I'm not sure what else to try, but I really hope the answer of "compile php" isn't the answer. Adam Lang Systems Engineer Rutgers Casualty Insurance Company
Nevermind... apparently if I rpm it with --nodeps it ignores it, but the php script still runs correctly. Adam Lang Systems Engineer Rutgers Casualty Insurance Company ----- Original Message ----- From: "Adam Lang" <aalang@rutgersinsurance.com> To: "PGSQL General" <pgsql-general@postgresql.org> Sent: Thursday, September 07, 2000 12:02 PM Subject: [GENERAL] php and pgsql and rpm/compile > I have php installed from rpm. I'm trying to rpm the package > php-pgsql-3.0.15.i386.rpm so that I can tie in to the postgres server. > > It is coming back with a dependency for libpq.so.2.0 > > I made a softlink to libpq.so.2.1 pointing to libpq.so.2.1, but it still has > that dependency. > > I have /usr/local/pgsql/lib in the ld.so.conf file. > > I'm not sure what else to try, but I really hope the answer of "compile php" > isn't the answer. > > Adam Lang > Systems Engineer > Rutgers Casualty Insurance Company
I had this problem a few weeks ago when I was setting up php and postgress. The easeist way (not recomended by my sysadmin =) ) was to rpm install all of my postgress programs, (postgress 7.02, server, test rpms) and then compiled php from scratch which was fairly painless I simply compiled php the following way to get postgress to work ./configure --with-mysql --with-pgsql --with-apache=../apache_1.3.12 --enabl e-track-vars --enable-xml Mike Sears Web Developer http://www.vianet.ca ----- Original Message ----- From: "Adam Lang" <aalang@rutgersinsurance.com> To: "PGSQL General" <pgsql-general@postgresql.org> Sent: Thursday, September 07, 2000 12:02 PM Subject: [GENERAL] php and pgsql and rpm/compile > I have php installed from rpm. I'm trying to rpm the package > php-pgsql-3.0.15.i386.rpm so that I can tie in to the postgres server. > > It is coming back with a dependency for libpq.so.2.0 > > I made a softlink to libpq.so.2.1 pointing to libpq.so.2.1, but it still has > that dependency. > > I have /usr/local/pgsql/lib in the ld.so.conf file. > > I'm not sure what else to try, but I really hope the answer of "compile php" > isn't the answer. > > Adam Lang > Systems Engineer > Rutgers Casualty Insurance Company >
Adam Lang wrote: > > I have php installed from rpm. I'm trying to rpm the package > php-pgsql-3.0.15.i386.rpm so that I can tie in to the postgres server. > > It is coming back with a dependency for libpq.so.2.0 The original packages distributed with RH 6.1 and 6.2 are for PostgreSQL 6.5.3 -- and the other RPM's built from that same distribution depend upon PostgreSQL 6.5.3's libpq -- which is 2.0. > I have /usr/local/pgsql/lib in the ld.so.conf file. > I'm not sure what else to try, but I really hope the answer of "compile php" > isn't the answer. You can install the 7.0.2 RPMset, grab the source RPM for php, rebuild it using (as root) rpm --rebuild php*.src.rpm, and install the freshly built packages with rpm -i from /usr/src/redhat/RPMS/i386. Of course, that rebuild will require a relatively complete development machine... -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Le 07.09.00 a 14:23, "Lamar Owen" m'ecrivait : > It is coming back with a dependency for libpq.so.2.0 I had this problem. I created a symlink for this file and a told rpm not to check dependies, and it worked. rpm --nodeps -ivh ... Lionel ================================================== Lionel TRESSENS lionel@tressens.net Appt 1897 R4 +33 6 63 76 15 13 4, All des Sciences App. F-31400 TOULOUSE ==================================================
Tressens Lionel wrote: > > Le 07.09.00 a 14:23, "Lamar Owen" m'ecrivait : > > > It is coming back with a dependency for libpq.so.2.0 > > I had this problem. I created a symlink for this file and a told rpm not > to check dependies, and it worked. > rpm --nodeps -ivh ... And, if you know the ramifications of --nodeps, that is a good solution. But, beware the ramifications of --nodeps. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
It actually runs without the symlink and --nodeps Adam Lang Systems Engineer Rutgers Casualty Insurance Company ----- Original Message ----- From: "Tressens Lionel" <tressens@etud.insa-tlse.fr> To: "PGSQL General" <pgsql-general@postgresql.org> Sent: Thursday, September 07, 2000 2:37 PM Subject: Re: [GENERAL] php and pgsql and rpm/compile > Le 07.09.00 a 14:23, "Lamar Owen" m'ecrivait : > > > It is coming back with a dependency for libpq.so.2.0 > > I had this problem. I created a symlink for this file and a told rpm not > to check dependies, and it worked. > rpm --nodeps -ivh ... > > Lionel > > ================================================== > Lionel TRESSENS lionel@tressens.net > Appt 1897 R4 +33 6 63 76 15 13 > 4, All des Sciences App. > F-31400 TOULOUSE > ================================================== >
Yesterday, when our nightly database backup was running, it errored out
with the following error from pg_dumpall:
dumpSequence(contact_seq): different sequence name returned by SELECT:
contact_sequence
Now, there isn't a sequence called "contact_sequence". There's one called
"contact_seq", and the contact table references it like this:
Attribute | Type | Modifier
-----------------+--------------+------------------------------------------
contact_id | integer | not null default
nextval('contact_seq'::text)
What exactly does this error mean, and how I can track down what is
causing it?
steve
Adam Lang wrote: > It actually runs without the symlink and --nodeps The reason it runs but won't install is due to the way the RPM build process follows symlinks versus the way ld.so treats symlinks. The actual linked file is simply libpq.so -- but the RPM findrequires script (which you can look at yourself in /usr/lib/rpm) resolves the symlink and places the dependency on the actual lib -- in this case, libpq.so.2.0. It does this for versioning, as ld.so is version-agnostic. Well, since libpq.so.2.1 is not that different from 2.0, it works fine -- however, if you had an app linked against libpq.so.1.0 (which would be true if you used a binary RPMset from RedHat 5.x contribs that linked against the RH 5 PostgreSQL 6.3.2), then you might run into some mysterious problems as libpq.so.2.1 is dynalinked into an app that is expecting libpq.so.1.0. Or worse yet, you could use an app linked against Postgres95 1.01's libpq.so (which is STILL libpq.so as far as ld.so is concerned) -- and then you are guaranteed to have problems (been there, done that). The ld.so linker, of course, doesn't care -- it just loads libpq.so in the LD_PATH and goes on with its life. That's why RPM enforces dependencies -- and why there is a --nodeps switch for when you need it -- as long as you are prepared to deal with the potential incompatibilities. Of course, in this particular instance it works due to the low mismatch from 2.0 to 2.1 libpq. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
> Yesterday, when our nightly database backup was running, it errored out > with the following error from pg_dumpall: > > dumpSequence(contact_seq): different sequence name returned by SELECT: > contact_sequence Hmm.... I just found the problem. (Maybe I should think more before I send these?) iboats=# select sequence_name from contact_seq; sequence_name ------------------ contact_sequence (1 row) --------------------------------------- So, trying to "update" it won't work, I suppose I'll have to drop the sequence and create it again. (If there are any other suggestions, please let me know). Anybody know how something like that could happen? steve
I understand what you are saying, but for arguments sake, I would assume that the libpq.so files were "backward compatable". That if you had an app requiring libpq.so.1 and you linked it to libpq.so.2, that it would work because it would support calls to previous versions. Am I making a poor assumtion? (That is the reason I tried the symlink... I assumed that it would be ok to "fool" the application). As for installing with --nodeps, I would say I don't know the full implications, but since I only had one dependency out of whack (that I knew I had) I decided to "chance it". Again, another poor assumption? Finally, thanks for explaining how some of the rpm and ld.so works. It helps. It's amazing how much easier computing is (for advanced users at least) when you learn how the actual operating system works... A friend of mine yells at me for not using Xwindows and gui tools more... tell him I have to stick to command line... I'm learning too much this way. :) Adam Lang Systems Engineer Rutgers Casualty Insurance Company ----- Original Message ----- From: "Lamar Owen" <lamar.owen@wgcr.org> To: "Adam Lang" <aalang@rutgersinsurance.com> Cc: "PGSQL General" <pgsql-general@postgresql.org> Sent: Thursday, September 07, 2000 3:24 PM Subject: Re: [GENERAL] php and pgsql and rpm/compile > Adam Lang wrote: > > > It actually runs without the symlink and --nodeps > > The reason it runs but won't install is due to the way the RPM build > process follows symlinks versus the way ld.so treats symlinks. The > actual linked file is simply libpq.so -- but the RPM findrequires script > (which you can look at yourself in /usr/lib/rpm) resolves the symlink > and places the dependency on the actual lib -- in this case, > libpq.so.2.0. It does this for versioning, as ld.so is version-agnostic. > > Well, since libpq.so.2.1 is not that different from 2.0, it works fine > -- however, if you had an app linked against libpq.so.1.0 (which would > be true if you used a binary RPMset from RedHat 5.x contribs that linked > against the RH 5 PostgreSQL 6.3.2), then you might run into some > mysterious problems as libpq.so.2.1 is dynalinked into an app that is > expecting libpq.so.1.0. Or worse yet, you could use an app linked > against Postgres95 1.01's libpq.so (which is STILL libpq.so as far as > ld.so is concerned) -- and then you are guaranteed to have problems > (been there, done that). > > The ld.so linker, of course, doesn't care -- it just loads libpq.so in > the LD_PATH and goes on with its life. That's why RPM enforces > dependencies -- and why there is a --nodeps switch for when you need it > -- as long as you are prepared to deal with the potential > incompatibilities. > > Of course, in this particular instance it works due to the low mismatch > from 2.0 to 2.1 libpq. > > -- > Lamar Owen > WGCR Internet Radio > 1 Peter 4:11
Lamar Owen wrote: > The reason it runs but won't install is due to the way the RPM build > process follows symlinks versus the way ld.so treats symlinks. The > actual linked file is simply libpq.so -- but the RPM findrequires script > (which you can look at yourself in /usr/lib/rpm) resolves the symlink > and places the dependency on the actual lib -- in this case, > libpq.so.2.0. It does this for versioning, as ld.so is version-agnostic. Oh, and the reason just adding the symlink in-place into the filesystem won't work is due to the fact that the RPM dependency checking doesn't check the filesystem's actual state -- it checks the rpm database's idea of what the filesystem looks like -- thus, you actually have to have a package installed that contains 'libpq.so.2.0' in order to get it to pass dependency checking. This is one reason that installing from RPM is the best idea on an RPM-based system (of course, currently SuSE won't install a RedHat RPM primarily due to the dep on chkconfig that is in the RedHat RPM). If you install from a source tarball, then install an RPM that depends on libs in your from-source installation (that the rpm database doesn't know about), it fails due to the unknown deps. -- Lamar Owen
So you're saying that If I install applications from RPMs, for it to really install properly, the dependencies should be installed from RPMs also? It can be done without (as in the example prior), but it makes life more difficult? Adam Lang Systems Engineer Rutgers Casualty Insurance Company ----- Original Message ----- From: "Lamar Owen" <lamar.owen@wgcr.org> To: "Adam Lang" <aalang@rutgersinsurance.com>; "PGSQL General" <pgsql-general@postgresql.org> Sent: Thursday, September 07, 2000 3:40 PM Subject: Re: [GENERAL] php and pgsql and rpm/compile > Lamar Owen wrote: > > The reason it runs but won't install is due to the way the RPM build > > process follows symlinks versus the way ld.so treats symlinks. The > > actual linked file is simply libpq.so -- but the RPM findrequires script > > (which you can look at yourself in /usr/lib/rpm) resolves the symlink > > and places the dependency on the actual lib -- in this case, > > libpq.so.2.0. It does this for versioning, as ld.so is version-agnostic. > > Oh, and the reason just adding the symlink in-place into the filesystem > won't work is due to the fact that the RPM dependency checking doesn't > check the filesystem's actual state -- it checks the rpm database's idea > of what the filesystem looks like -- thus, you actually have to have a > package installed that contains 'libpq.so.2.0' in order to get it to > pass dependency checking. This is one reason that installing from RPM > is the best idea on an RPM-based system (of course, currently SuSE won't > install a RedHat RPM primarily due to the dep on chkconfig that is in > the RedHat RPM). If you install from a source tarball, then install an > RPM that depends on libs in your from-source installation (that the rpm > database doesn't know about), it fails due to the unknown deps. > > -- > Lamar Owen
Adam Lang wrote: > > So you're saying that If I install applications from RPMs, for it to really > install properly, the dependencies should be installed from RPMs also? It > can be done without (as in the example prior), but it makes life more > difficult? Yes, and Yes. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Hi!, Evrybody there!
How can I know how much minutes (or hours, or days) are there in an
interval. I mean:
Field T1 value: 01/05/2000 09:00
Field T2 value: 01/05/2000 10:00
T2-T1 gimme 01:00
the function date_part('minute',T2-T1) says 00
But I'd like to get 60
Is there a standar function wich tells the diff. in seconds/minutes or
whatever in an interval.
Now I'm using date_part('epoch',T2) - date_part('epoch',T1)
I had a function in MS SqlServer: datediff(string,date1,date2) --> Integer.
That's what I'm seeking.
By the way, the MS SqlServer went to the hell and I replaced in one day and
one night by the PostgreSQL server I had for testing purposes (The backup
file gave me an unrecovery drive support in the restore of the MS SqlServer
(????!!!!)).
Think we are more than 100 workstations in a 24H / 7 days factory
enviroment.
Since then evrything goes faster and nicer.
Thanks in advance!
Pablo.
This appears to work for me for two timestamps:
(T2-T1)::reltime::int4 -> # of seconds.
There's no direct conversion to int4, but there's
one to reltime and one from that to int4.
Stephan Szabo
sszabo@bigpanda.com
On Fri, 8 Sep 2000, Pablo Prieto wrote:
> Hi!, Evrybody there!
>
> How can I know how much minutes (or hours, or days) are there in an
> interval. I mean:
>
> Field T1 value: 01/05/2000 09:00
> Field T2 value: 01/05/2000 10:00
>
> T2-T1 gimme 01:00
> the function date_part('minute',T2-T1) says 00
> But I'd like to get 60
> Is there a standar function wich tells the diff. in seconds/minutes or
> whatever in an interval.
>
> Now I'm using date_part('epoch',T2) - date_part('epoch',T1)
>
> I had a function in MS SqlServer: datediff(string,date1,date2) --> Integer.
> That's what I'm seeking.
>
> By the way, the MS SqlServer went to the hell and I replaced in one day and
> one night by the PostgreSQL server I had for testing purposes (The backup
> file gave me an unrecovery drive support in the restore of the MS SqlServer
> (????!!!!)).
>
> Think we are more than 100 workstations in a 24H / 7 days factory
> enviroment.
>
> Since then evrything goes faster and nicer.
>
> Thanks in advance!
>
> Pablo.
>