[boost] [Test] can't build boost.test dll's on MacOSX

From: Kim Barrett (kab_at_[hidden])
Date: 2005-12-14 23:36:16

When building Boost_1_33_1 on MacOSX 10.4 with Darwin tools (gcc
4.0.1), if I try to build with dynamic linking enabled (i.e.
"<runtime-link>dynamic" in the bjam command), there are link-time
failures for the three libraries that are part of Boost.Test. I think
this is likely the same as a known problem with NT mentioned in
recent email from Gennadiy: the prg_exec_monitor and
test_exec_monitor libraries fail because __Z9test_mainiPPc is
undefined, while the unit_test_framework library fails due to
__Z20init_unit_test_suiteiPPc being undefined.

It looks like the Jamfile for Boost.Test has a workaround for NT
here, which presumably needs to be extended to MacOSX as well. There
is a block of code in libs/test/build/Jamfile that looks like this:

    local TEST_DLLs ;
    if ! $(NT) && ( ! $(UNIX) || $(OS) != CYGWIN )
    {
      TEST_DLLs = TRUE ;
    }

It looks like the conditional there needs to also be false for
MacOSX. After grovelling around in the jam configuration, it looked
like the necessary change was to replace

    $(OS) != CYGWIN

with

    ( $(OS) != CYGWIN && $(OS) != MACOSX )

i.e. the test should be

    if ! $(NT) && ( ! $(UNIX) || ( $(OS) != CYGWIN && $(OS) != MACOSX ))

Unfortunately, that change doesn't seem to be sufficient to disable
the attempt to build dll's for Boost.Test. I have no idea why, and no
idea how to figure that out, being largely unfamiliar with jam and
Jamfiles.

Alternatively, is there a way from the bjam command to indicate that
I want <runtime-link>dynamic except for some specific set of
libraries? (I know how to exclude libraries completely, which would
probably solve my problem for prg_exec_monitor and test_exec_monitor,
since we aren't using them, but doesn't deal with the
unit_test_framework library, which I do need.)

It would seem from Gennadiy's recent burst of messages that this may
no longer a problem or about to no longer be a problem on CVS HEAD,
but we're not prepared to go there and would prefer a patch to the
1.33.1 release. Sorry I didn't notice this when checking out the
release candidate, but this platform has only just been bumped up in
my priorities enough for me to start trying it.