Re: php and pgsql and rpm/compile
От | Lamar Owen |
---|---|
Тема | Re: php and pgsql and rpm/compile |
Дата | |
Msg-id | 39B7EB81.3BF083B4@wgcr.org обсуждение исходный текст |
Ответ на | Re: php and pgsql and rpm/compile (Tressens Lionel <tressens@etud.insa-tlse.fr>) |
Список | pgsql-general |
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
В списке pgsql-general по дате отправления: