Boost logo

Boost-Build :

Subject: Re: [Boost-build] Should link=static disable all shared library tests?
From: Kuhl, Brian (brian.kuhl_at_[hidden])
Date: 2016-01-25 00:51:54

In my case it's inconvenient.
Boost is an amazingly democratic project in breath and contributors, so I expect some inconsistencies in implementation across libraries.

But, I'm making a concerted effort to 'support' boost on an OS that currently supports IA, ARM and PowerPC families in both 32 and 64bit modes and may utilizes any one of 3 separate compilers depending on the board being targeted.

I'd hoped to avoid shared libraries initially just to reduce the effort.

There are some holes in shared library support in the current version across the matrix of compilers and processors as well; so this brings up a somewhat philosophical question.

What constitutes boost support?

Or put another way, what percentage of successful test coverage would you expect from a supported platform?

Or is that a question for the testing list?


On 1/23/2016 10:11 PM, Steven Watanabe wrote:
> On 01/23/2016 07:47 PM, Kuhl, Brian wrote:
>> I'm invoking the boost test suite with command similar to the one below:
>> source ./$(VXWORKS_ENV_SH) && cd status && \
>> ../b2 -j$(JOBS) --prefix=$(ROOT_DIR) --libdir=$(LIBDIR)/$(TOOL_COMMON_DIR) --includedir=$(VSB_DIR)/usr/h/public \
>> link=static toolset=gcc-vxworks target-os=vxworks testing.launcher=./vxworks_boost_test_run.exp \
>> "--limit-tests=atomic|date_time|accumulators|algorithm|align|array|assert"
>> Several library tests are failing because of the lack of shared libraries, despite the designation of link=static.
>> So far I've encountered tests in system, random and filesystem that insist on trying to link against shared libraries..
>> Is this expected behavior for some reason, or a defect that should be corrected?
>> Looking at the regression targets I don't see any that would typically use static linking.
> This behavior is expected. Boost.Random
> explicitly runs the same test with both
> static and shared libraries. I assume
> it's the same for the others. In any case,
> the target properties override anything specified
> on the command line.

I find it very mysterious that the command line does not override
everything else in Boost Build. I have also found it nearly impossible
to determine what overrides what when it comes to Boost Build
properties. It does not appear to be documented anywhere and my past
attempts at finding out what is the hierarchy which determines how a
property is set, when it is specified in different places in jamfiles
and on the command line, have never been answered. Can an attempt please
be made in the documentation to explain this ?

Unsubscribe & other changes:

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at