Horton

Thread

  1. share library version problems

    Bryan White <bryan@arcamax.com> — 2006-08-22T16:26:53Z

    I am having problems with my libpq programs crashing.  This seems to be 
a version incompatibility and I want to find out how to best proceed.

My main database is running Fedora Core 5 with the supplied PostgreSQL 
8.1.4.

My web server is running Fedora Core 4 with the supplied PostgreSQL 8.0.8.

My dev server was running the same setup as the web server.  The 
difference is that it acts as its own database server.  I was 
uncomfortable running an older version of the server on my test system 
then on the live system.  So yesterday I removed the OS supplied 
PostgreSQL RPMs and installed 8.1.4 from RPMs on the PostgreSQL download 
site.

Today I discovered that programs that I compile on my dev server will 
segfault when run on the live web server.

On my live web server I have:
    /usr/lib/libpq.a
    /usr/lib/libpq.so     -> libpq.so.4.0
    /usr/lib/libpq.so.4   -> libpq.so.4.0
    /usr/lib/libpq.so.4.0

On my dev server I have:
    /usr/lib/libpq.a
    /usr/lib/libpq.so     -> libpq.so.4.1
    /usr/lib/libpq.so.4   -> libpq.so.4.1
    /usr/lib/libpq.so.4.1

My programs are compiled with -lpq

Is there something I can do on my dev server to get it to produce 
programs that will run on my live server?  Note: I would rather change 
the dev server because there are about 12 other live servers that would 
also need to be fixed.

Is there a document somewhere that discusses how to handle these types 
of issues?

Note:  In the recent past I had been running 7.1.x on my dev server and 
had no problems running the produced programs on a live server with 
8.0.x libraries.
-- 
Bryan White, ArcaMax Publishing Inc.

Bryan is used to being beast of burden to other people's needs.
Very sad life. Probably have very sad death. But, at least there
is symmetry.

  2. Re: share library version problems

    Martijn van Oosterhout <kleptog@svana.org> — 2006-08-22T21:00:03Z

    On Tue, Aug 22, 2006 at 12:26:53PM -0400, Bryan White wrote:
> I am having problems with my libpq programs crashing.  This seems to be 
> a version incompatibility and I want to find out how to best proceed.

<snip>

> My dev server was running the same setup as the web server.  The 
> difference is that it acts as its own database server.  I was 
> uncomfortable running an older version of the server on my test system 
> then on the live system.  So yesterday I removed the OS supplied 
> PostgreSQL RPMs and installed 8.1.4 from RPMs on the PostgreSQL download 
> site.
> 
> Today I discovered that programs that I compile on my dev server will 
> segfault when run on the live web server.

Can you provide the output of ldd? The libraries are supposed to be
reasonably compatable.

In any case, you should try to run both servers against the same set of
libs and headers. You can have multiple copies of libpq around and
select it at compile time. The client library doesn't really have to
match the server version...

Hope this helps,
-- 
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

  3. Re: share library version problems

    Tom Lane <tgl@sss.pgh.pa.us> — 2006-08-22T21:09:51Z

    Bryan White <bryan@arcamax.com> writes:
> I am having problems with my libpq programs crashing.  This seems to be 
> a version incompatibility and I want to find out how to best proceed.

> My main database is running Fedora Core 5 with the supplied PostgreSQL 
> 8.1.4.

> My web server is running Fedora Core 4 with the supplied PostgreSQL 8.0.8.

> My dev server was running the same setup as the web server.  The 
> difference is that it acts as its own database server.  I was 
> uncomfortable running an older version of the server on my test system 
> then on the live system.  So yesterday I removed the OS supplied 
> PostgreSQL RPMs and installed 8.1.4 from RPMs on the PostgreSQL download 
> site.

> Today I discovered that programs that I compile on my dev server will 
> segfault when run on the live web server.

Can you get a core dump and provide a gdb backtrace from the segfault?
Right offhand I see no difference in the claimed API of 8.0 and 8.1
libpq except that 8.1 adds lo_create(), which I suppose you're not
using.  So while this isn't good practice in general, I don't see
why it wouldn't work in this particular case.

One thing you should check is whether both libs were built with the same
options (compare pg_config --configure output from the 8.0 and 8.1
installations).

			regards, tom lane

  4. Re: share library version problems

    Bryan White <bryan@arcamax.com> — 2006-08-22T21:50:41Z

    Tom Lane wrote:
> Bryan White <bryan@arcamax.com> writes:
>> I am having problems with my libpq programs crashing.  This seems to be 
>> a version incompatibility and I want to find out how to best proceed.
> 
>> My main database is running Fedora Core 5 with the supplied PostgreSQL 
>> 8.1.4.
> 
>> My web server is running Fedora Core 4 with the supplied PostgreSQL 8.0.8.
> 
>> My dev server was running the same setup as the web server.  The 
>> difference is that it acts as its own database server.  I was 
>> uncomfortable running an older version of the server on my test system 
>> then on the live system.  So yesterday I removed the OS supplied 
>> PostgreSQL RPMs and installed 8.1.4 from RPMs on the PostgreSQL download 
>> site.
> 
>> Today I discovered that programs that I compile on my dev server will 
>> segfault when run on the live web server.
> 
> Can you get a core dump and provide a gdb backtrace from the segfault?
> Right offhand I see no difference in the claimed API of 8.0 and 8.1
> libpq except that 8.1 adds lo_create(), which I suppose you're not
> using.  So while this isn't good practice in general, I don't see
> why it wouldn't work in this particular case.

I have used both gdp and valgrind with full debug builds.  The segfault 
does not seem to occur in Postgres related code.  It occurs before any 
database connection is established.  If it makes a difference, the code 
is all written in C++.

The reason I suspect the Postgres lib is because there have been no 
changes to this code.  After upgrading the dev server yesterday, I 
rolled out a small fix this morning and started seeing the segfault. 
Reverting the change did not fix it.  Compiling a clean subversion 
checkout on both boxes confirmed that code compiled on the dev box will 
not run on the web server but code compiled on the web server runs on 
either box.

> One thing you should check is whether both libs were built with the same
> options (compare pg_config --configure output from the 8.0 and 8.1
> installations).

I think that might be the problem.  These are the differences in 
pg_config --configure output:

dev server:
  '--host=i686-redhat-linux-gnu'
  '--build=i686-redhat-linux-gnu'
  '--target=i686-redhat-linux'
  '--with-includes=/usr/include'
  '--with-libraries=/usr/lib'
  'CFLAGS=-O2 -g -march=i686 -I/usr/include/et'
  'CPPFLAGS= -I/usr/include/et'
  'build_alias=i686-redhat-linux-gnu'
  'host_alias=i686-redhat-linux-gnu'
  'target_alias=i686-redhat-linux'

web server:
  '--build=i386-redhat-linux'
  '--host=i386-redhat-linux'
  '--target=i386-redhat-linux-gnu'
  '--with-tcl'
  '--with-tclconfig=/usr/lib'
  '--enable-thread-safety'
  'CFLAGS=-O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m32 
-march=i386 -mtune=pentium4 -fasynchronous-unwind-tables'
  'build_alias=i386-redhat-linux'
  'host_alias=i386-redhat-linux'
  'target_alias=i386-redhat-linux-gnu'

I note that Postgres is packaged in the following RPMS:
postgresql-devel
postgresql-libs
postgresql-server
postgresql

Does it work to install the postgresql-server RPM from the 8.1 version 
and the others from the Fedora 4 included 8.0 version?

-- 
Bryan White, ArcaMax Publishing Inc.

  5. Re: share library version problems

    Bryan White <bryan@arcamax.com> — 2006-08-22T21:57:25Z

    Martijn van Oosterhout wrote:
> Can you provide the output of ldd? The libraries are supposed to be
> reasonably compatable.

web server:
         linux-gate.so.1 =>  (0x00ab0000)
         libexpat.so.0 => /usr/lib/libexpat.so.0 (0x00411000)
         libpq.so.4 => /usr/lib/libpq.so.4 (0x00324000)
         libssl.so.5 => /lib/libssl.so.5 (0x005c2000)
         libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x0069c000)
         libm.so.6 => /lib/libm.so.6 (0x0049e000)
         libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00bd7000)
         libc.so.6 => /lib/libc.so.6 (0x00d82000)
         libpthread.so.0 => /lib/libpthread.so.0 (0x00ece000)
         libcrypto.so.5 => /lib/libcrypto.so.5 (0x00c00000)
         libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00afc000)
         libcrypt.so.1 => /lib/libcrypt.so.1 (0x00111000)
         libresolv.so.2 => /lib/libresolv.so.2 (0x00f0c000)
         libnsl.so.1 => /lib/libnsl.so.1 (0x00f88000)
         libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x00b70000)
         libcom_err.so.2 => /lib/libcom_err.so.2 (0x00a9f000)
         libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x00ad6000)
         libdl.so.2 => /lib/libdl.so.2 (0x0013f000)
         libz.so.1 => /usr/lib/libz.so.1 (0x003fc000)
         /lib/ld-linux.so.2 (0x00267000)
         libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x00ac3000)

dev server:
         linux-gate.so.1 =>  (0x00497000)
         libexpat.so.0 => /usr/lib/libexpat.so.0 (0x0065b000)
         libpq.so.4 => /usr/lib/libpq.so.4 (0x00524000)
         libssl.so.5 => /lib/libssl.so.5 (0x00210000)
         libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00775000)
         libm.so.6 => /lib/libm.so.6 (0x002b7000)
         libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x006de000)
         libc.so.6 => /lib/libc.so.6 (0x00bff000)
         libcrypto.so.5 => /lib/libcrypto.so.5 (0x00101000)
         libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00d74000)
         libcrypt.so.1 => /lib/libcrypt.so.1 (0x009b6000)
         libresolv.so.2 => /lib/libresolv.so.2 (0x00395000)
         libnsl.so.1 => /lib/libnsl.so.1 (0x00248000)
         libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x0025d000)
         libcom_err.so.2 => /lib/libcom_err.so.2 (0x00d44000)
         libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x00d49000)
         libdl.so.2 => /lib/libdl.so.2 (0x00275000)
         libz.so.1 => /usr/lib/libz.so.1 (0x004e1000)
         /lib/ld-linux.so.2 (0x00a8b000)
         libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x00d6f000)


> In any case, you should try to run both servers against the same set of
> libs and headers. You can have multiple copies of libpq around and
> select it at compile time. The client library doesn't really have to
> match the server version...

As I asked in another thread:  Does it work to install the 
postgresql-server RPM from the 8.1 version and the others from the 
Fedora 4 included 8.0 version?


-- 
Bryan White, ArcaMax Publishing Inc.

  6. Re: share library version problems

    Tom Lane <tgl@sss.pgh.pa.us> — 2006-08-22T22:13:11Z

    Bryan White <bryan@arcamax.com> writes:
> Tom Lane wrote:
>> One thing you should check is whether both libs were built with the same
>> options (compare pg_config --configure output from the 8.0 and 8.1
>> installations).

> I think that might be the problem.  These are the differences in 
> pg_config --configure output:

> dev server:
>   '--host=i686-redhat-linux-gnu'
>   '--build=i686-redhat-linux-gnu'
>   '--target=i686-redhat-linux'
>   '--with-includes=/usr/include'
>   '--with-libraries=/usr/lib'
>   'CFLAGS=-O2 -g -march=i686 -I/usr/include/et'
>   'CPPFLAGS= -I/usr/include/et'
>   'build_alias=i686-redhat-linux-gnu'
>   'host_alias=i686-redhat-linux-gnu'
>   'target_alias=i686-redhat-linux'

> web server:
>   '--build=i386-redhat-linux'
>   '--host=i386-redhat-linux'
>   '--target=i386-redhat-linux-gnu'
>   '--with-tcl'
>   '--with-tclconfig=/usr/lib'
>   '--enable-thread-safety'
>   'CFLAGS=-O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m32 
> -march=i386 -mtune=pentium4 -fasynchronous-unwind-tables'
>   'build_alias=i386-redhat-linux'
>   'host_alias=i386-redhat-linux'
>   'target_alias=i386-redhat-linux-gnu'

I'd bet on --enable-thread-safety, or perhaps -fexceptions or
-fasynchronous-unwind-tables as being the problem.


> Does it work to install the postgresql-server RPM from the 8.1 version 
> and the others from the Fedora 4 included 8.0 version?

I think the RPMs have interdependencies that would prevent that,
although you could try it.

My advice is to get your 8.1.* RPMs from Fedora 5 rather than PGDG.
Your "web server" options look like Red Hat's standard build
environment, so the Fedora RPMs should have those same build options or
close enough.  And there's no difference worth noticing other than the
Red Hat-ish build options, unless Devrim or I screwed up ;-)

If the Fedora 5 RPMs won't install on your FC4 machine, grab the FC5
SRPM and do a quick rpmbuild --rebuild to make custom RPMs for your
environment.

			regards, tom lane

  7. Re: share library version problems

    Bryan White <bryan@arcamax.com> — 2006-08-23T13:38:28Z

    Tom Lane wrote:
> If the Fedora 5 RPMs won't install on your FC4 machine, grab the FC5
> SRPM and do a quick rpmbuild --rebuild to make custom RPMs for your
> environment.
After about 5 minutes of compiling I get this:
======
pg_regress: initdb failed
Examine ./log/initdb.log for the reason.

make: *** [check] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.67109 (%build)


RPM build errors:
     Bad exit status from /var/tmp/rpm-tmp.67109 (%build)
====== /usr/src/redhat/BUILD/postgresql-8.1.4/
                         src/test/regress/log/initdb.log
Running in noclean mode.  Mistakes will not be cleaned up.
initdb: cannot be run as root
Please log in (using, e.g., "su") as the (unprivileged) user that will
own the server process.

-- 
Bryan White, ArcaMax Publishing Inc.

  8. Re: share library version problems

    Tom Lane <tgl@sss.pgh.pa.us> — 2006-08-23T13:59:25Z

    Bryan White <bryan@arcamax.com> writes:
> Tom Lane wrote:
>> If the Fedora 5 RPMs won't install on your FC4 machine, grab the FC5
>> SRPM and do a quick rpmbuild --rebuild to make custom RPMs for your
>> environment.

> After about 5 minutes of compiling I get this:

> initdb: cannot be run as root

Don't do the rpmbuild as root.  Alternatively, I believe there's a
%define you can set to skip the regression test ... but that's
probably not a good idea.

			regards, tom lane

  9. Re: share library version problems

    Bryan White <bryan@arcamax.com> — 2006-08-23T15:22:10Z

    Tom Lane wrote:
> Don't do the rpmbuild as root.  Alternatively, I believe there's a
> %define you can set to skip the regression test ... but that's
> probably not a good idea.

I think I have it solved now.  I am not to familiar with the process of 
building from source RPMs.  You said to not do it as root but that meant 
I did not have write access to /usr/src/redhat.  I tried to options to 
build from a different location without much luck.  In the end I moved 
/usr/src/redhat to /usr/src/redhat.old and created a new one (including 
sub-directories) and made myself the owner.  It then builds fine.  Seems 
like there has to be an easier way.

Anyway, after installing the new RPMs on my FC4 dev server and 
rebuilding my programs, the programs do now run on my web server (stock 
FC4 PostgreSQL).

Thanks for your help

-- 
Bryan White, ArcaMax Publishing Inc.

  10. Re: share library version problems

    Tom Lane <tgl@sss.pgh.pa.us> — 2006-08-23T15:38:24Z

    Bryan White <bryan@arcamax.com> writes:
> Tom Lane wrote:
>> Don't do the rpmbuild as root.

> I think I have it solved now.  I am not to familiar with the process of 
> building from source RPMs.  You said to not do it as root but that meant 
> I did not have write access to /usr/src/redhat.

Well, nobody at Red Hat builds RPMs in /usr/src/redhat anymore ;-).
The setup I use involves creating a directory ~/rpmwork, making
these subdirectories in it:
	BUILD/    RPMS/     SOURCES/  SPECS/    SRPMS/
and making a file ~/.rpmmacros containing just
	%_topdir /home/tgl/rpmwork
(adjust to suit where your work dir actually is of course).  To build,
copy the SRPM into the SRPMS subdirectory, cd there, and go
	rpmbuild --rebuild srpmfilename
The only part you need root for is actually installing the built RPMs
(which end up under the RPMS directory of course).

			regards, tom lane