<<< Date Index >>>     <<< Thread Index >>>

Re: Failing to reopen mailbox after SSH tunnel closure



On Fri, Jan 12, 2007 at 01:08:01AM -0500, Kyle Wheeler wrote:
> >That sounds very plausible. To confirm that that's the difference, Is
> >there any way I can find out precisely which version of these
> >libraries my various installations of mutt are using?

[snip]

> On MacOSX, you use 'otool -L' instead of 'ldd'.

Thanks. On a system where mutt is able to reestablish its connection to
the server, I get:

otis:mike$ otool -L ~/usr/bin/mutt
/Users/mike/usr/bin/mutt:
        /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current 
version 5.4.0)
        /usr/lib/libssl.0.9.7.dylib (compatibility version 0.9.7, current 
version 0.9.7)
        /usr/lib/libcrypto.0.9.7.dylib (compatibility version 0.9.7, current 
version 0.9.7)
        /usr/lib/libiconv.2.dylib (compatibility version 5.0.0, current version 
5.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 88.1.6)

On a system where it can't, I get:

minion:mike$ otool -L /sw/bin/mutt
/sw/bin/mutt:
        /sw/lib/libncursesw.5.dylib (compatibility version 5.0.0, current 
version 5.0.0)
        /usr/lib/libssl.0.9.7.dylib (compatibility version 0.9.7, current 
version 0.9.7)
        /usr/lib/libcrypto.0.9.7.dylib (compatibility version 0.9.7, current 
version 0.9.7)
        /sw/lib/libsasl2.2.dylib (compatibility version 3.0.0, current version 
3.22.0)
        /sw/lib/libintl.3.dylib (compatibility version 8.0.0, current version 
8.3.0)
        /sw/lib/libiconv.2.dylib (compatibility version 6.0.0, current version 
6.0.0)
        /sw/lib/libidn.11.dylib (compatibility version 17.0.0, current version 
17.20.0)
        /sw/lib/libqdbm.14.dylib (compatibility version 14.0.0, current version 
14.9.0)
        /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 
1.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 88.3.4)

It looks to me like libssl and libcrypto are the same on both systems,
but libsasl is absent from the "working" installation. Could this be the
source of the "problem"? (I assume the other differences are red
herrings.)

-- Mike