I could use a little help figuring out the best way to get around this problem.

Suppose I have something like this in my Jamroot:

   lib BOOST_THREAD 

     : : <file>$(BOOST_LOCATION)/lib/libboost_thread-mt.so

       <cxxflags>-pthread

     : : <include>$(BOOST_LOCATION)/include/boost-1_39 ;

   use-project /APPROOT : . ;

   use-project /MY_PROJ : MyProj ;

   build-project MY_PROJ ;

   install install-bin : MY_PROJ 

     :

       <install-type>EXE

       <variant>release:<location>$(INSTALL)/release/bin

       <variant>debug:<location>$(INSTALL)/debug/bin

       <install-dependencies>on

       <hardcode-dll-paths>false

   ;

   install install-lib : MY_PROJ :

       <install-type>LIB

       <variant>release:<location>$(INSTALL)/release/lib

       <variant>debug:<location>$(INSTALL)/debug/lib

       <install-dependencies>on

       <hardcode-dll-paths>false

   ;

And in the Jamfile for MyProj:

   exe MyProj 

     : /APPROOT//BOOST_THREAD

       [ glob src/*.cpp ]

     : <include>include

   ;

And suppose that in $(BOOST_LOCATION)/lib, libboost_thread-mt.so is actually a symlink to libboost_thread-gcc43-mt-1_39.so.1.39.0.

The problem I'm having is that when I build the thing from the Jamroot directory, and it installs and brings in dependencies, it copies a file named "libboost_thread-mt.so", but if I do a ldd on MyProj, it says it's looking for "libboost_thread-gcc43-mt-1_39.so.1.39.0".  I'm completely baffled as to why.  Shouldn't the executable depend on the library with the name I gave it in Jamroot?  Or if not, shouldn't it copy the library with the longer name that the executable is really dependent on?  (I mean, the option is called "install-dependencies," not "install-irrelevant-stuff," right?)

I'm a relative newbie on this sort of stuff, so any efforts to help me actually *understand* what's going on here would be greatly appreciated.

Thanks,

Alex Wagner