Issue 3734 - upgrade to 2.2 on a box with 2.1 installed causes new binaries to be linked against old libs
Summary: upgrade to 2.2 on a box with 2.1 installed causes new binaries to be linked a...
Status: VERIFIED FIXED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: slapd (show other issues)
Version: unspecified
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-05-19 01:36 UTC by robbat2@gentoo.org
Modified: 2014-08-01 21:05 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description robbat2@gentoo.org 2005-05-19 01:36:26 UTC
Full_Name: Robin H. Johnson
Version: 2.2.26
OS: Gentoo Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (209.87.56.55)


If you have 2.1 installed on your machine, and then compile 2.2.26, the new
binaries (ldapsearch et al) are linked to the OLD libaries as well as the new
libraries.

x29 / # ldd /usr/bin/ldapsearch
        linux-gate.so.1 =>  (0xffffe000)
        libldap-2.2.so.7 => /usr/lib/libldap-2.2.so.7 (0xb7f90000)
        liblber-2.2.so.7 => /usr/lib/liblber-2.2.so.7 (0xb7f82000)
        libssl.so.0.9.7 => /usr/lib/libssl.so.0.9.7 (0xb7f51000)
        libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7 (0xb7e4d000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0xb7e1f000)
        libresolv.so.2 => /lib/libresolv.so.2 (0xb7e0a000)
        libc.so.6 => /lib/tls/libc.so.6 (0xb7cdd000)
        liblber.so.2 => not found
        libdl.so.2 => /lib/libdl.so.2 (0xb7cd8000)
        /lib/ld-linux.so.2 (0xb7fea000)

This means the new binaries cannot be run, as they try to load the old liblber
when you run them.
if you then make clean and compile again (after installing 2.2 for the first
time), the binaries are then compiled properly.

Comment 1 robbat2@gentoo.org 2005-05-20 01:28:03 UTC
I won't be able to respond to this bug between May 21 and May 29, as I'll be
away on vacation.

The Gentoo bug tracking the issue is here:
http://bugs.gentoo.org/show_bug.cgi?id=93074

-- 
Robin Hugh Johnson
E-Mail     : robbat2@orbis-terrarum.net
Home Page  : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ#       : 30269588 or 41961639
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
Comment 2 Ryan Chapman 2005-05-20 12:30:53 UTC
The correct gentoo bugzilla link is:

http://bugs.gentoo.org/show_bug.cgi?id=93074

The link Robin submitted is broken/dead.

Comment 3 ando@openldap.org 2005-05-26 11:04:17 UTC
moved from Incoming to Build
Comment 4 Kurt Zeilenga 2005-05-30 03:59:30 UTC
moved from Build to Incoming
Comment 5 Howard Chu 2005-06-15 20:00:19 UTC
I did a fresh build and install of 2.1.30 followed immediately by a 
fresh build and install of 2.2.27 on my system (overlaid on the 2.1 
install), and no such problem occurred. (x86_64 Suse.) I actually have 
all of the 2.1, 2.2, and 2.3 libraries installed at the moment, and 
haven't specified any special compiler or link options. In each build 
step, only the selected release's libraries got linked.

The ordering of your ldd output is suspicious; I believe if you use 
readelf you'll find that your ldapsearch(etc) binaries don't have a 
direct dependency on the old libraries. Most likely some other library 
on your system has that dependency. I don't believe this is an OpenLDAP 
software problem.

robbat2@gentoo.org wrote:
> Full_Name: Robin H. Johnson
> Version: 2.2.26
> OS: Gentoo Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (209.87.56.55)
>
>
> If you have 2.1 installed on your machine, and then compile 2.2.26, the new
> binaries (ldapsearch et al) are linked to the OLD libaries as well as the new
> libraries.
>
> x29 / # ldd /usr/bin/ldapsearch
>         linux-gate.so.1 =>  (0xffffe000)
>         libldap-2.2.so.7 => /usr/lib/libldap-2.2.so.7 (0xb7f90000)
>         liblber-2.2.so.7 => /usr/lib/liblber-2.2.so.7 (0xb7f82000)
>         libssl.so.0.9.7 => /usr/lib/libssl.so.0.9.7 (0xb7f51000)
>         libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7 (0xb7e4d000)
>         libcrypt.so.1 => /lib/libcrypt.so.1 (0xb7e1f000)
>         libresolv.so.2 => /lib/libresolv.so.2 (0xb7e0a000)
>         libc.so.6 => /lib/tls/libc.so.6 (0xb7cdd000)
>         liblber.so.2 => not found
>         libdl.so.2 => /lib/libdl.so.2 (0xb7cd8000)
>         /lib/ld-linux.so.2 (0xb7fea000)
>
> This means the new binaries cannot be run, as they try to load the old liblber
> when you run them.
> if you then make clean and compile again (after installing 2.2 for the first
> time), the binaries are then compiled properly.
>
>
>   


-- 
  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

Comment 6 Howard Chu 2005-06-15 20:03:42 UTC
changed notes
changed state Open to Feedback
Comment 7 Kurt Zeilenga 2005-06-15 20:28:35 UTC
changed notes
Comment 8 Kurt Zeilenga 2005-06-21 22:43:27 UTC
changed state Feedback to Closed
Comment 9 robbat2@gentoo.org 2005-07-03 17:52:26 UTC
Followup for anybody else suffering from this issue.  After digging into it
some more (see gentoo link again http://bugs.gentoo.org/show_bug.cgi?id=93074)
I found that libldap was linking to the OLD liblber during building (see
readelf output).

On a hunch, I updated libtool in the package, using 'libtoolize --copy --force'
before running configure, and then the problem vanished entirely. Might I
suggest that upstream update the libtool (build/ltmain.sh) stuff that is used
in the distribution, as they are a LONG way out of date.

-- 
Robin Hugh Johnson
E-Mail     : robbat2@orbis-terrarum.net
Home Page  : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ#       : 30269588 or 41961639
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

Comment 10 Howard Chu 2009-02-17 05:28:27 UTC
moved from Incoming to Archive.Incoming
Comment 11 OpenLDAP project 2014-08-01 21:05:54 UTC
cannot reproduce on SuSE, likely not ours