Change in behavior of lib task in 1.66.0

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Change in behavior of lib task in 1.66.0

Boost - Build mailing list
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
_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Change in behavior of lib task in 1.66.0

Boost - Build mailing list
AMDG

On 01/05/2018 09:46 AM, Ian Emmons via Boost-build wrote:

> 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
>
> <snip>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.
>

Here's the cause of the problem:

$ cat Jamroot
import type ;
ECHO [ type.type libboost_filesystem.so.1.66.0 ] ;
$ b2
MANPAGE

If you remove src/tools/types/man.jam it should work again.

In Christ,
Steven Watanabe
_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Change in behavior of lib task in 1.66.0

Boost - Build mailing list
On Jan 5, 2018, at 9:26 PM, Steven Watanabe via Boost-build <[hidden email]> wrote:

> AMDG
>
> On 01/05/2018 09:46 AM, Ian Emmons via Boost-build wrote:
>> 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
>>
>> <snip>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.
>>
>
> Here's the cause of the problem:
>
> $ cat Jamroot
> import type ;
> ECHO [ type.type libboost_filesystem.so.1.66.0 ] ;
> $ b2
> MANPAGE
>
> If you remove src/tools/types/man.jam it should work again.
>
> In Christ,
> Steven Watanabe


Thanks very much -- it took me a while to return to this problem and try out your work-around, but it does in fact solve the problem.

Thanks,

Ian

_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Change in behavior of lib task in 1.66.0

Boost - Build mailing list
AMDG

On 01/13/2018 09:07 PM, Ian Emmons wrote:

> On Jan 5, 2018, at 9:26 PM, Steven Watanabe via Boost-build <[hidden email]> wrote:
>>
>>> <address-model>64,<link>shared,<variant>debug:<source>$(BoostDir)/stage/lib/libboost_filesystem-gcc48-mt-d-x64-1_66.so.1.66.0
>>>
>>> <snip>
>> If you remove src/tools/types/man.jam it should work again.
>>
>
> Thanks very much -- it took me a while to return to this problem and try out your work-around, but it does in fact solve the problem.
>

  I've applied a slightly less draconian change in
79dd4a729273dcb22a2f1a2340c176863925699b, so
it should be fixed in the next release, as well.

In Christ,
Steven Watanabe
_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build