Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Secure-Shell
[Top] [All Lists]

Re: Problem Fixed

Subject: Re: Problem Fixed
Date: Wed, 5 Jul 2006 08:05:45 -0400
On Sun, Jul 02, 2006 at 04:55:23PM -0400, Joshua Kordani wrote:
Sorry about that.  Apparantly insead of renaming the libs from  
libcrypto.0.9.7 to 0.9.8, it seems like the scheme has changed to  
just simply be libcrypto.a,  I was expecting to find *.0.9.7 and  
0.9.8 libs in the same directory and just delete the old ones, but  
the name change had me fooled.

I think you're a bit confused about how the linker works.  I'm not
familiar with your platform specifically, so I'll address the generic
case.

When the linker (ld) is told to link with a certain library by using
the -l_library_ flag, it searches a set of paths for a set of files.
The first file that it finds is the one it will use.

The set of paths includes a static set that's built into the linker
(usually just /usr/lib, but possibly /usr/local/lib as well -- see the
documentation!) as well as any additional paths that are specified with
-L_path_ flags when the linker is invoked.  So, if the linker is invoked
with

  ld ... -L/usr/local/lib -L/opt/openssl/lib -lssl

then it will search the following directories:

  /usr/local/lib
  /opt/openssl/lib
  /usr/lib

probably in that order.  (Again, see the documentation for details.)

The file(s) it will look for are somewhat platform specific, because
the naming conventions for shared libraries differ from one platform to
another.  But you've provided a handy list of filenames below:

dir.  So to summarize:
I Deleted the following from /usr/lib:
libcryto.0.9.7.dylib
libcrypto.0.9.dylib
libcrypto.dylib
libcrypto.a

Aha!  It looks like your platform uses "libfoo.dylib" for shared libraries.
So chances are, your linker will be searching for files of the form

  libfoo.dylib
  libfoo.a

when it's given the -lfoo flag.

Did I get it right here? or what.

Without seeing what arguments you gave to ./configure and what the output
of the linker was (hint: check config.log), it's hard to say whether you
got it "right".  But if it worked, I guess that's a good sign.

If your platform is anything like the ones I'm familiar with, then
the libfoo.dylib "file" is actually a symlink to a versioned shared
library.  (And libcrypto.0.9.dylib was probably also a symlink to
libcryto.0.9.7.dylib -- too bad you didn't include "ls -l" output.)

With that in mind, you probably should have *kept* the libcrypto.0.9.7
library in place, so that any programs linked against it could still use
it.  Then, simply remove the libcrypto.a (static library) and the
libcrypto.dylib (symlink to the most recent dynamic library), and make
/usr/lib/libcrypto.dylib a symlink to wherever your more recent version
of libcrypto.0.x.y.dylib was.

If you have /usr/lib/libcrypto.a but not /usr/lib/libcrypto.dylib -- and
if your link command doesn't pass any -L flags to find libcrypto.dylib
anywhere else on the system -- then you're going to be building a copy
of OpenSSH with libcrypto statically linked instead of dynamically linked.
This may or may not be what you want....

<Prev in Thread] Current Thread [Next in Thread>
  • Problem Fixed, Joshua Kordani
    • Re: Problem Fixed, Greg Wooledge <=