Amanda-Users

Re: Amanda 2.6.1 on Solaris x86 - library dependency

2009-08-14 15:05:46
Subject: Re: Amanda 2.6.1 on Solaris x86 - library dependency
From: Brian Cuttler <brian AT wadsworth DOT org>
To: Chris Hoogendyk <hoogendyk AT bio.umass DOT edu>
Date: Fri, 14 Aug 2009 14:29:01 -0400
Chris,

We will remove the old libraries, that should take care of it.

for completeness though, I just don't understand why
we get two different results in the same binary ?

Actually, for the binary on Curie we only search for 
   object=libamandad-2.6.1p1.so, where on Cascade we
   seem to be searching for both.

>From my # ldd -s output ?

   find object=libamandad-2.6.1p1.so; required by /usr/local/libexec/amanda/aman
dad
    search path=/usr/sfw/lib:/opt/sfw/lib  (LD_LIBRARY_PATH)
    trying path=/usr/sfw/lib/libamandad-2.6.1p1.so
    trying path=/opt/sfw/lib/libamandad-2.6.1p1.so
    search path=/usr/local/lib/amanda:/opt/sfw/lib:/usr/sfw/lib  (RPATH from fil
e /usr/local/libexec/amanda/amandad)
    trying path=/usr/local/lib/amanda/libamandad-2.6.1p1.so
        libamandad-2.6.1p1.so =>         /usr/local/lib/amanda/libamandad-2.6.1p
1.so

   find object=libamanda-2.4.5.so; required by /usr/local/lib/amanda/libamandad-
2.6.1p1.so
    search path=/usr/sfw/lib:/opt/sfw/lib  (LD_LIBRARY_PATH)
    trying path=/usr/sfw/lib/libamanda-2.4.5.so
    trying path=/opt/sfw/lib/libamanda-2.4.5.so
        libamanda-2.4.5.so =>    /opt/sfw/lib/libamanda-2.4.5.so



On Fri, Aug 14, 2009 at 02:12:25PM -0400, Chris Hoogendyk wrote:
> 
> 
> Dustin J. Mitchell wrote:
> >On Fri, Aug 14, 2009 at 1:22 PM, Brian Cuttler<brian AT wadsworth DOT org> 
> >wrote:
> >  
> >>They look like the same binary but don't act like the same binary.
> >>    
> >
> >This is really best handled by those who are skilled in the ways of
> >Solaris -- the operating system has lots of weird behaviors with
> >regard to linking.  What's happening is that amandad is recording a
> >link to 'libamanda', which ldd is then resolving to the first
> >libamanda it finds, which happens to be the really old one on cascade.
> >
> >Two possible solutions:
> > - delete the old libraries
> > - make sure the linker does not look in the directory containing the
> >old libraries (/opt/sfw/lib) by removing it from various LD_foo_PATH
> >variables (some of which are specified at compile time, IIRC).
> 
> If you use `ldd -s` it will display the search path it uses to find the 
> libraries (I believe the examples you showed just used ldd). That will 
> tell you how it is getting there. Then you can modify it from that 
> point. One option is to remove the older 2.4.5 library if you don't need 
> it anymore.
> 
> It's the combination of how you built the binary, what your 
> LD_LIBRARY_PATH is in the particular environment it is running in, and 
> how crle is set up. Depending on where your newer library is compared to 
> your older library, you can adjust those so that it finds the newer 
> library first.
> 
> -- 
> ---------------
> 
> Chris Hoogendyk
> 
> -
>   O__  ---- Systems Administrator
>  c/ /'_ --- Biology & Geology Departments
> (*) \(*) -- 140 Morrill Science Center
> ~~~~~~~~~~ - University of Massachusetts, Amherst 
> 
> <hoogendyk AT bio.umass DOT edu>
> 
> --------------- 
> 
> Erd?s 4
> 
> 
---
   Brian R Cuttler                 brian.cuttler AT wadsworth DOT org
   Computer Systems Support        (v) 518 486-1697
   Wadsworth Center                (f) 518 473-6384
   NYS Department of Health        Help Desk 518 473-0773



IMPORTANT NOTICE: This e-mail and any attachments may contain
confidential or sensitive information which is, or may be, legally
privileged or otherwise protected by law from further disclosure.  It
is intended only for the addressee.  If you received this in error or
from someone who was not authorized to send it to you, please do not
distribute, copy or use it or any attachments.  Please notify the
sender immediately by reply e-mail and delete this from your
system. Thank you for your cooperation.



<Prev in Thread] Current Thread [Next in Thread>