Thread: Building extensions against OpenSCG RPM packages
Hello list,
What are your experiences with OpenSCG’s RPM packages? It is my impression that those packages allow vanilla PostgreSQL to run, but trying to build extensions such as PostGIS against them fails in most (two out of three) cases due to problems with the included shared libraries.
The “two out of three cases” means that I tried three of their packages, then basically gave up on those OpenSCG packages as one “builds out of the box” success out of three seemed a bit on the low side. Is that “success rate” about correct, or could I have picked the only two packages with such problems?
Of course, OpenSCG’s “selling points” (packages have been relocatable since around 2011, and are largely independent of the Linux distribution due to extra libraries supplied) did sound good, so you might still consider OpenSCG’s packages if you just want to run “vanilla” PostgreSQL.
As I mentioned, in one case building PostGIS against the installed PostgreSQL worked out of the box; in one case building a PostGIS extension didn’t work against the libraries supplied by OpenSCG, but after copying around some system libraries things both built and ran fine; one case was even weirder in that an initial build succeeded but produced a shared library that would error out at run time, and copying over some system libraries resulted in a state in which the build succeeded AND produced a working shared library (see the earlier discussion about that weird case: http://www.postgresql.org/message-id/C5DBACC6DCC7604C9E4875FD9C7968B1129DF47A16@ITXS01EVS.service.it.nrw.de; it was compounded by the problem that just copying over just one system library didn’t work at all, and as it turned out, I also needed to copy over a dependency).
Figuring out which system libraries to copy over can be sort of fun if you have a little development background, but database administrators may shy away from copying bunches of shared libraries around. What could be going wrong here? How can a shared library allow things to run fine but prevent things from building against it?
Holger Friedrich
On 01/29/2015 04:36 AM, Holger.Friedrich-Fa-Trivadis@it.nrw.de wrote: > Hello list, > What are your experiences with OpenSCG’s RPM packages? It is my > impression that those packages allow vanilla PostgreSQL to run, but > trying to build extensions such as PostGIS against them fails in most > (two out of three) cases due to problems with the included shared libraries. > The “two out of three cases” means that I tried three of their packages, > then basically gave up on those OpenSCG packages as one “builds out of > the box” success out of three seemed a bit on the low side. Is that > “success rate” about correct, or could I have picked the only two > packages with such problems? > Of course, OpenSCG’s “selling points” (packages have been relocatable > since around 2011, and are largely independent of the Linux distribution > due to extra libraries supplied) did sound good, so you might still > consider OpenSCG’s packages if you just want to run “vanilla” PostgreSQL. > As I mentioned, in one case building PostGIS against the installed > PostgreSQL worked out of the box; in one case building a PostGIS > extension didn’t work against the libraries supplied by OpenSCG, but > after copying around some system libraries things both built and ran > fine; one case was even weirder in that an initial build succeeded but > produced a shared library that would error out at run time, and copying > over some system libraries resulted in a state in which the build > succeeded AND produced a working shared library (see the earlier > discussion about that weird case: > _http://www.postgresql.org/message-id/C5DBACC6DCC7604C9E4875FD9C7968B1129DF47A16@ITXS01EVS.service.it.nrw.de_; > it was compounded by the problem that just copying over just one system > library didn’t work at all, and as it turned out, I also needed to copy > over a dependency). > Figuring out which system libraries to copy over can be sort of fun if > you have a little development background, but database administrators > may shy away from copying bunches of shared libraries around. What > could be going wrong here? How can a shared library allow things to run > fine but prevent things from building against it? From what I gather it is static binary package built against libraries at a point in time in a distribution that may or may not be in exact sync with the distribution you are running. Which is fine when you run it by itself. Then you try to 'merge' it with a package that comes from another source. Most of the time the close enough rule will apply and things will work. When it does not you get the above. If you want less drama I would say stick with your distributions repo or use the Postgres RPM repo: http://www.postgresql.org/download/linux/redhat/ Or, build from source. > Holger Friedrich -- Adrian Klaver adrian.klaver@aklaver.com
On Thursday, January 29, 2015 10:14 PM, Adrian Klaver wrote: > On 01/29/2015 04:36 AM, Holger.Friedrich-Fa-Trivadis@it.nrw.de wrote: >> Hello list, >> What are your experiences with OpenSCG's RPM packages? [deletia] > From what I gather it is static binary package built against libraries at a point in time in a distribution that may ormay not be in exact sync with the > distribution you are running. Which is fine when you run it by itself. Then you try to 'merge' it with a package that comesfrom another source. > Most of the time the close enough rule will apply and things will work. When it does not you get the above. If you wantless drama I would say > stick with your distributions repo or use the Postgres RPM repo: > > http://www.postgresql.org/download/linux/redhat/ > > Or, build from source. Thanks for your reply, Adrian. We certainly opted for less drama and gave up on the OpenSCG packages. I just wanted to know whether my "statistical sample" of OpenSCG packages may have been skewed, and other people maybe hadbetter experiences with building stuff against the OpenSCG packages. Holger Friedrich