[Boost-build] Change in behavior of lib task in 1.66.0

Subject: [Boost-build] Change in behavior of lib task in 1.66.0
From: Ian Emmons (ian_at_[hidden])
Date: 2018-01-05 16:46:58

I am using Boost.Build as the build infrastructure for my own project.  
I have the following setup:

* I use --layout=versioned when I build the Boost libraries.

* In site-config.jam, I have defined aliases for the precompiled Boost 
libraries that I use, like so:

alias BoostFileSystem
   : # no sources
   : 
<address-model>64,<link>shared,<variant>debug:<source>$(BoostDir)/stage/lib/libboost_filesystem-gcc48-mt-d-x64-1_66.so.1.66.0
     # the other seven variations of 64/32, shared/static, and 
debug/release here
   : # no default build
   : <include>$(BoostDir) <threading>multi
   ;

* In my project's jam file I build a shared library and install it, like 
so:

lib Parliament
   : [ glob *.cpp ] /site-config//BoostFileSystem
   : <include>. <threading>multi
   : # default build
   : <include>. <threading>multi
   ;

install distribution
   : Parliament
   : <location>$(InstallLocation) <install-dependencies>on 
<install-type>SHARED_LIB
   : # default build
   : # usage requirements
   ;

In Boost 1.65.1, this all worked very nicely.  However, in 1.66.0, the 
lib task fails to put the filesystem shared library on the link line.  
If I remove the version number at the very end of the filesystem file 
name in the alias (so that I am relying on the symbolic links created 
when Boost is built), then the link works properly.  I am guessing that 
starting in 1.66.0, Boost.Build no longer recognizes file names ending 
in a version as shared libraries, so it doesn't know what to do with 
them.

Leaving off the version numbers in the alias seems like a nice 
work-around, except that it causes the install task to do the wrong 
thing.  The install task "copies" the symbolic links, meaning that it 
creates copies of the files themselves, but under the file name of the 
symbolic link.  This causes my shared library to fail to load, because 
the dependency name embedded in it by the linker includes the version 
number at the end.  (Apparently, the linker is smarter about how it 
follows the symbolic links.)

How can I make this work again as it did under version 1.65.1?

BTW, thank you for including the address model in the library names -- 
that is a big improvement!

Thanks,

Ian