Boost build failure on master
I normally just compile and test Spirit/Fusion tests using the super
project layout. That works fine; however, I'm setting up Bamboo build
artifacts for all of Boost to enable slicker testing.
As a result, I'm just trying to build all of Boost after a checkout. I
admit that I've never found this to work properly. I'm following what I
think are the standard instructions [1]:
(lets keep it simple with linux for now)
git clone --recursive git@github.com:boostorg/boost.git
cd boost
./bootstrap.sh
./b2 headers
./b2
The result:
error: Name clash for '
On 01/24/2015 10:03 PM, Michael Caisse wrote:
I normally just compile and test Spirit/Fusion tests using the super project layout. That works fine; however, I'm setting up Bamboo build artifacts for all of Boost to enable slicker testing.
As a result, I'm just trying to build all of Boost after a checkout. I admit that I've never found this to work properly. I'm following what I think are the standard instructions [1]:
(lets keep it simple with linux for now)
git clone --recursive git@github.com:boostorg/boost.git cd boost ./bootstrap.sh ./b2 headers ./b2
The result:
error: Name clash for '
libboost_system.so.1.58.0' error: error: Tried to build the target twice, with property sets having error: these incompabile properties: error: error: - none error: - <address-model>64 <architecture>x86
Michael, It looks like something is explicitly requesting <address-model>64. I can't quite reproduce this on Linux, though. Could you run with --debug-building and grep the log to see where <address-model>64 first appears in build properties? -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com
Hi Volodya, Am Sonntag, 25. Januar 2015, 18:09:39 schrieb Vladimir Prus:
It looks like something is explicitly requesting <address-model>64. I can't quite reproduce this on Linux, though. Could you run with --debug-building and grep the log to see where <address-model>64 first appears in build properties?
Those are the same symptoms as discussed last year. Your last comment on these issues can be found in: http://lists.boost.org/boost-build/2014/12/27778.php The final solution thus seems to always determine both <address-model> and <architecture> The workaround for now is to either use b2 --without-context --without-coroutine in order to skip both libraries if not needed or explicitly run b2 address-model=64 architecture=x86 and thus specify the defaults manually for all libraries. Note that this blows up build paths and leads to a doubled install size. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold@gmx.eu ! Germany
On 01/25/2015 08:45 AM, Jürgen Hunold wrote:
Hi Volodya,
Am Sonntag, 25. Januar 2015, 18:09:39 schrieb Vladimir Prus:
It looks like something is explicitly requesting <address-model>64. I can't quite reproduce this on Linux, though. Could you run with --debug-building and grep the log to see where <address-model>64 first appears in build properties?
Those are the same symptoms as discussed last year. Your last comment on these issues can be found in:
http://lists.boost.org/boost-build/2014/12/27778.php
The final solution thus seems to always determine both <address-model> and <architecture>
The workaround for now is to either use
b2 --without-context --without-coroutine
in order to skip both libraries if not needed or explicitly run
b2 address-model=64 architecture=x86
and thus specify the defaults manually for all libraries. Note that this blows up build paths and leads to a doubled install size.
Yours,
Jürgen
Thank you Jürgen, your suggestion (--without-*) works. Volodya, please let me know if there is something more I can provide. I have the --debug-building log if that is still helpful. michael -- Michael Caisse ciere consulting ciere.com
On 01/25/2015 08:26 PM, Michael Caisse wrote:
On 01/25/2015 08:45 AM, Jürgen Hunold wrote:
Hi Volodya,
Am Sonntag, 25. Januar 2015, 18:09:39 schrieb Vladimir Prus:
It looks like something is explicitly requesting <address-model>64. I can't quite reproduce this on Linux, though. Could you run with --debug-building and grep the log to see where <address-model>64 first appears in build properties?
Those are the same symptoms as discussed last year. Your last comment on these issues can be found in:
http://lists.boost.org/boost-build/2014/12/27778.php
The final solution thus seems to always determine both <address-model> and <architecture>
The workaround for now is to either use
b2 --without-context --without-coroutine
in order to skip both libraries if not needed or explicitly run
b2 address-model=64 architecture=x86
and thus specify the defaults manually for all libraries. Note that this blows up build paths and leads to a doubled install size.
Yours,
Jürgen
Thank you Jürgen, your suggestion (--without-*) works.
Volodya, please let me know if there is something more I can provide. I have the --debug-building log if that is still helpful.
Michael, I think Jürgen's explanation is sufficient for me - I was tripped by the similarity with the endian problem that is now fixed. -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com
participants (3)
-
Jürgen Hunold -
Michael Caisse -
Vladimir Prus