|
Boost-Build : |
Subject: Re: [Boost-build] clang trunk and -mthreads
From: Eric Niebler (eniebler_at_[hidden])
Date: 2013-10-03 11:29:26
On 10/2/2013 11:33 PM, Vladimir Prus wrote:
> On 03.10.2013 00:47, Eric Niebler wrote:
>> I use b2 from trunk with clang from trunk under cygwin. I just rebuilt
>> clang from trunk, and found it no longer works with trunk b2 because of
>> this:
>>
>> clang: error: unknown argument: '-mthreads'
>>
>> "/usr/local/clang-trunk/bin/clang++" -c -x c++ -std=gnu++11 -O0 -g
>> -fno-inline -Wall -g -mthreads -DBOOST_FILESYSTEM_STATIC_L
>> INK=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DBOOST_TEST_NO_AUTO_LINK=1
>> -I"../../.." -I"/cygdrive/c/boost/org/trunk" -o "../../../bin/lib
>> s/quick_check/test/test4.test/clang-linux-trunk/debug/link-static/threading-multi/qcheck/test4.obj"
>>
>> "qcheck/test4.cpp"
>>
>> Looks like clang no longer likes the -mthreads option. This should
>> probably be dealt with in the b2 clang.jam file, but I don't know what
>> to change. Any help?
>
> Eric,
>
> Maybe you can adapt the logic we have for similar thing in darwin.jam,
> which goes like this:
>
>
> # - GCC 4.0 and higher in Darwin does not have -fcoalesce-templates.
> if $(real-version) < "4.0.0"
> {
> flags darwin.compile.c++ OPTIONS $(condition) :
> -fcoalesce-templates ;
> }
>
> There's code above that determines 'real-version' by running compiler
> with the -dumpversion flag. It appears
> that clang-linux.jam already runs the compiler with the --version flag,
> but only if not version is provided
> by the user; that logic should be modified to match darwin - that is, to
> always set real-version so that we
> can use that in such checks.
Two problems with this:
1) AFAICT, the -mthreads switch is actually added in gcc.jam. I feel
like I shouldn't be adding clang-specific logic there.
2) I suspect that the clang team wouldn't just yank a command-line
option that did something meaningful because that would be a breaking
change. In other words, BBv2 is probably wrong to be adding -mthreads in
the first place for any clang version. This is just a guess at this
point, but it should be investigated before just slapping a version
check in there.
Anyway, these changes involve slightly more time and BBv2 insight than I
possess. I am merely bringing this issue to the attention of the BBv2
maintainers so they can take appropriate action before the next clang
release breaks everything.
If you would like, I can file a bug.
-- Eric Niebler Boost.org http://www.boost.org
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk