Обсуждение: starting out

This is my first posting here.  I just subscribed.  Normally I go
read mailing list archives to see what specific topics are discussed,
particularly when there is more than one list and I can pin down
which my question should go to.

Problem is, the archive HTML generator is slightly broken, and just
enough so that Netscape won't render the pages.  I went in and looked
at the HTML and found what I suspected was the cause:  an unterminated
table.  Could whoever takes care of that stuff get it fixed, or if I
need to contact someone, can you tell me who to contact?  It is the
threaded view that is broken.  The date view seems OK.  It just needs
a </table> tag at the right place as far as I can tell.

Oh, another thing.  It would be helpful if the welcome message would
give the email address to mail submissions to.

Now to the real problem (and I hope I picked the right mailing list).

I compiled 7.3.2 and built a binary tarball to distribute to other
machines.  But the building, in particular the linking, has a problem
in the way it links to libssl.  Instead of making the linking reference
to the generic version level of the library, it makes it to the specific
patch level version.  The end result is that the compiled binary won't
run unless that EXACT version of libssl is present.  This means I have
to end up making binaries for every possible library version.  OK, so
I have only a couple versions of openssl deployed (because openssl
happens to be a major pain to reinstall via remote due to the fact that
it kills my ssh daemon when I do, and I get locked out).  So I have to
make a couple of different binary versions.

But this also means when I do upgrade openssl, it will also kill postgres
and I have to upgrade postgres, too, every time I upgrade openssl (which
I should be doing more of since I have a few machine still on the older
version, but now this will slow it down even more).

So, you who know how the source build/configure/makefile setup is put
together, do you know what modification to make so that it will link to
a generic version of openssl instead of the specific patch level?

Out of curiosity, I downloaded the Redhat RPM to see how that binary was
built.  It did appear to be built do a generic version of ssl, but it
was not built to the current version.  It references libssl.so.2 not
libssl.so.0.  Maybe Redhat hacked things around and this is what is there
so this is what will be linked.  But at least it is apparently that there
is a way to make postgres build for generic linking.  Who knows how?  Is
there a patch for the source tree to make it Redhat ready from which I
might pick out part to make it work for my needs?

--
-----------------------------------------------------------------
| Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |
| phil-nospam@ipal.net | Texas, USA | http://ka9wgn.ham.org/    |
-----------------------------------------------------------------

Phil Howard <phil-pgsql-general@ipal.net> writes:
> I compiled 7.3.2 and built a binary tarball to distribute to other
> machines.  But the building, in particular the linking, has a problem
> in the way it links to libssl.  Instead of making the linking reference
> to the generic version level of the library, it makes it to the specific
> patch level version.  The end result is that the compiled binary won't
> run unless that EXACT version of libssl is present.

Hmm.  When I build from source on a Linux box, I get generic references.
For example, in a recent build on a RHL 8.0 box, I see:
[tgl@rh1 bin]$ ldd psql
        libpq.so.3 => /home/tgl/testversion/lib/libpq.so.3 (0x40013000)
        libssl.so.2 => /lib/libssl.so.2 (0x4003e000)
        libcrypto.so.2 => /lib/libcrypto.so.2 (0x4006e000)
        libz.so.1 => /usr/lib/libz.so.1 (0x40142000)
        libreadline.so.4 => /usr/lib/libreadline.so.4 (0x40150000)
        libtermcap.so.2 => /lib/libtermcap.so.2 (0x4017c000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x40180000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x401ae000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x401c0000)
        libdl.so.2 => /lib/libdl.so.2 (0x401d5000)
        libm.so.6 => /lib/i686/libm.so.6 (0x401d8000)
        libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
[tgl@rh1 bin]$ ldd postgres
        libssl.so.2 => /lib/libssl.so.2 (0x4002c000)
        libcrypto.so.2 => /lib/libcrypto.so.2 (0x4005d000)
        libz.so.1 => /usr/lib/libz.so.1 (0x40131000)
        libreadline.so.4 => /usr/lib/libreadline.so.4 (0x4013f000)
        libtermcap.so.2 => /lib/libtermcap.so.2 (0x4016b000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x4016f000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x4019c000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x401af000)
        libdl.so.2 => /lib/libdl.so.2 (0x401c4000)
        libm.so.6 => /lib/i686/libm.so.6 (0x401c7000)
        libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
[tgl@rh1 bin]$

This seems correct to me.  What does ldd show for you?

            regards, tom lane

On Tue, Feb 11, 2003 at 10:35:54AM -0500, Tom Lane wrote:

| Phil Howard <phil-pgsql-general@ipal.net> writes:
| > I compiled 7.3.2 and built a binary tarball to distribute to other
| > machines.  But the building, in particular the linking, has a problem
| > in the way it links to libssl.  Instead of making the linking reference
| > to the generic version level of the library, it makes it to the specific
| > patch level version.  The end result is that the compiled binary won't
| > run unless that EXACT version of libssl is present.
|
| Hmm.  When I build from source on a Linux box, I get generic references.
| For example, in a recent build on a RHL 8.0 box, I see:
| [tgl@rh1 bin]$ ldd psql
|         libpq.so.3 => /home/tgl/testversion/lib/libpq.so.3 (0x40013000)
|         libssl.so.2 => /lib/libssl.so.2 (0x4003e000)
|         libcrypto.so.2 => /lib/libcrypto.so.2 (0x4006e000)

I found out the problem.  It is in the OpenSSL default Makefile.

For the above 2 I was getting:

    libssl.so.0.9.7 => not found
    libcrypto.so.0.9.7 => not found

They were not found because the files available are:

    /lib/libcrypto.so -> libcrypto.so.0
    /lib/libcrypto.so.0 -> libcrypto.so.0.9.6
    /lib/libcrypto.so.0.9.6
    /lib/libssl.so -> libssl.so.0
    /lib/libssl.so.0 -> libssl.so.0.9.6
    /lib/libssl.so.0.9.6

The reason it picked 0.9.7 is because postgresql was compiled and linked
on a machine which had:

    /lib/libcrypto.so -> libcrypto.so.0
    /lib/libcrypto.so.0 -> libcrypto.so.0.9
    /lib/libcrypto.so.0.9 -> libcrypto.so.0.9.7
    /lib/libcrypto.so.0.9.7
    /lib/libssl.so -> libssl.so.0
    /lib/libssl.so.0 -> libssl.so.0.9
    /lib/libssl.so.0.9 -> libssl.so.0.9.7
    /lib/libssl.so.0.9.7

I had seen the behaviour before when dealing with OpenSSH, but wrote it
off as some "weird paranoia" of the OpenSSH developers.  But it was not
of their doing.  It was postgresql having the same thing that pointed me
to OpenSSL itself being the culprit.

What it did was:

    gcc -shared -o libcrypto.so.0.9.7 -Wl,-soname=libcrypto.so.0.9.7 ...

and when I changed it to do:

    gcc -shared -o libcrypto.so.0.9.7 -Wl,-soname=libcrypto.so.0 ...

instead and re-installed OpenSSL on the compile machine (safer to do it
there since it is physically local to me and I don't have to worry about
it bringing down my SSH daemon), then recompiled postgresql (recompiled
OpenSSH as well), I then got the references to:

root@hamal:/root 215> ldd /usr/opt/postgresql-7.3.2/bin/postgres
        libssl.so => /lib/libssl.so (0x4001b000)
        libcrypto.so => /lib/libcrypto.so (0x40049000)
        libz.so.1 => /lib/libz.so.1 (0x40106000)
        libreadline.so.4 => /usr/lib/libreadline.so.4 (0x40114000)
        libtermcap.so.2 => /lib/libtermcap.so.2 (0x40138000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x4013c000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x4016b000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x4017c000)
        libdl.so.2 => /lib/libdl.so.2 (0x40191000)
        libm.so.6 => /lib/libm.so.6 (0x40195000)
        libc.so.6 => /lib/libc.so.6 (0x401b7000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
root@hamal:/root 216>

Well, this isn't exactly what I wanted, but it gets me rolling and
confirms I pinpointed the problem in OpenSSL.  I really want it to
reference the major version number.  But that is version 0, not 2
as Redhat seems to have.  I'll tweak the build scripts later and
redo it all again.

--
-----------------------------------------------------------------
| Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |
| phil-nospam@ipal.net | Texas, USA | http://ka9wgn.ham.org/    |
-----------------------------------------------------------------

Phil Howard <phil-pgsql-general@ipal.net> writes:
> Well, this isn't exactly what I wanted, but it gets me rolling and
> confirms I pinpointed the problem in OpenSSL.  I really want it to
> reference the major version number.  But that is version 0, not 2
> as Redhat seems to have.

[looks at rpm specfile...]  No, the reason Red Hat is using 2 is that
the openssl boys have repeatedly broken binary compatibility without
incrementing their major version number as they ought.  At the moment
I find in the Rawhide version

# For the curious:
# 0.9.5a soversion = 0
# 0.9.6  soversion = 1
# 0.9.6a soversion = 2
# 0.9.6c soversion = 3
# 0.9.7  soversion = 4
%define soversion 4

If you are concerned about making the .so version number actually
useful, I recommend you follow Red Hat's lead.

            regards, tom lane