Weird library problem

[H***@it.nrw.de]

Hello,

the other day I've run into a weird problem involving the libldap_r-2.4.so.2 library. I've got a working recipe as to how to get things to run, but still it's a little weird, so I'd appreciate any insight into what's going on here.

On a CentOS 6.5 box, I installed PostgreSQL 9.0.17 into a custom directory using the relocatable OpenSCG RPM package, which comes with its own libldap_r-2.4.so.2. There is also another version of libldap_r-2.4.so.2 in the /lib64 directory on the box, which rpm says comes from a package called openldap. (Technically, the libldap_r-2.4.so.2 in /usr64 is a symlink pointing to the regular file libldap_r-2.4.so.2.5.6.) We also want PostGIS, so I was working on building a custom RPM package that would install PostGIS 2.0.3 into the custom directory PostgreSQL is installed in.

It turns out that the RPM package only builds when the original libldap_r-2.4.so.2 is in place that came with the OpenSCG package. Conversely, PostGIS only runs when I copy the library version from /lib64 over the one in the PostgreSQL library path. With the OpenSCG library in place, which PostGIS was compiled against, I get this error message:

postgres=# SELECT postgis_full_version();
ERROR: could not load library "/usr/postgres/system/TESTMIT9017/lib/postgresql/rtpostgis-2.0.so": /lib64/libldap_r-2.4.so.2: undefined symbol: ber_sockbuf_io_udp
CONTEXT: SQL statement "SELECT postgis_gdal_version()"
PL/pgSQL function "postgis_full_version" line 21 at SQL statement

Anyone encountered those symptoms and knows what is going on?

Best regards
Holger Friedrich

[Adrian Klaver]

Post by H***@it.nrw.de
Hello,
the other day I’ve run into a weird problem involving the
libldap_r-2.4.so.2 library. I’ve got a working recipe as to how to get
things to run, but still it’s a little weird, so I’d appreciate any
insight into what’s going on here.
On a CentOS 6.5 box, I installed PostgreSQL 9.0.17 into a custom
directory using the relocatable OpenSCG RPM package, which comes with
its own libldap_r-2.4.so.2. There is also another version of
libldap_r-2.4.so.2 in the /lib64 directory on the box, which rpm says
comes from a package called openldap. (Technically, the
libldap_r-2.4.so.2 in /usr64 is a symlink pointing to the regular file
libldap_r-2.4.so.2.5.6.) We also want PostGIS, so I was working on
building a custom RPM package that would install PostGIS 2.0.3 into the
custom directory PostgreSQL is installed in.
It turns out that the RPM package only builds when the original
libldap_r-2.4.so.2 is in place that came with the OpenSCG package.
Conversely, PostGIS only runs when I copy the library version from
/lib64 over the one in the PostgreSQL library path. With the OpenSCG
library in place, which PostGIS was compiled against, I get this error
postgres=# SELECT postgis_full_version();
ERROR: could not load library
/lib64/libldap_r-2.4.so.2: undefined symbol: ber_sockbuf_io_udp
CONTEXT: SQL statement "SELECT postgis_gdal_version()"
PL/pgSQL function "postgis_full_version" line 21 at SQL statement
Anyone encountered those symptoms and knows what is going on?

Library mismatch. Looks like rtpostgis-2.0.so is looking for something
that /lib64/libldap_r-2.4.so.2 is not providing. So, if I am following
correctly that would be the OpenSCG version. From the looks of it, that
library is not recent enough.

Post by H***@it.nrw.de
Best regards
Holger Friedrich

[H***@it.nrw.de]

Library mismatch. Looks like rtpostgis-2.0.so is looking for something that /lib64/libldap_r-2.4.so.2 is not providing. So, if I am following correctly that would be the OpenSCG version. From the looks of it, that library is not recent enough.

For the record: Apparently there's a third library in the mix, which was not explicitly mentioned by the error messages. Looks like the newer libldap_r-2.4.so.2 sort of knows about the "something" but does not quite provide it itself. Turns out I also needed to copy over a newer liblber-2.4.so.2 to go with the newer libldap_r-2.4.so.2, and now the PostGIS package builds again.

What seemed weird was that the newer liblap_r-2.4.so.2 allowed PostGIS to run but broke the build. The liblber-2.4.so.2 thing could possibly explain that.

[Adrian Klaver]

Post by H***@it.nrw.de

Library mismatch. Looks like rtpostgis-2.0.so is looking for something that /lib64/libldap_r-2.4.so.2 is not providing. So, if I am following correctly that would be the OpenSCG version. From the looks of it, that library is not recent enough.

For the record: Apparently there's a third library in the mix, which was not explicitly mentioned by the error messages. Looks like the newer libldap_r-2.4.so.2 sort of knows about the "something" but does not quite provide it itself. Turns out I also needed to copy over a newer liblber-2.4.so.2 to go with the newer libldap_r-2.4.so.2, and now the PostGIS package builds again.
What seemed weird was that the newer liblap_r-2.4.so.2 allowed PostGIS to run but broke the build. The liblber-2.4.so.2 thing could possibly explain that.

This is where ldd is your friend.

Do:

ldd libldap_r-2.4.so.2

and if you want more information:

ldd -v libldap_r-2.4.so.2

[Adrian Klaver]

Post by H***@it.nrw.de

Library mismatch. Looks like rtpostgis-2.0.so is looking for something that /lib64/libldap_r-2.4.so.2 is not providing. So, if I am following correctly that would be the OpenSCG version. From the looks of it, that library is not recent enough.

For the record: Apparently there's a third library in the mix, which was not explicitly mentioned by the error messages. Looks like the newer libldap_r-2.4.so.2 sort of knows about the "something" but does not quite provide it itself. Turns out I also needed to copy over a newer liblber-2.4.so.2 to go with the newer libldap_r-2.4.so.2, and now the PostGIS package builds again.
What seemed weird was that the newer liblap_r-2.4.so.2 allowed PostGIS to run but broke the build. The liblber-2.4.so.2 thing could possibly explain that.

This is where ldd is your friend.

Do:

ldd libldap_r-2.4.so.2

or for more information

ldd -v libldap_r-2.4.so.2