[Log, Filesystem] Build errors using B2 and Jamfiles distributed with Boost
I'm a lazy guy so I try to use Boost.Build whenever I can. That way I can simply download the Boost tarball, extract it into my project's directory and use the Jamfiles distributed with Boost. Recently I switched to 1.58 and my project setup failed to build, complaining that Filesystem would be built twice with different settings* (actually it would be built one time without any specific settings and one time with a sane set for my platform). I managed to create a "simple" project setup to reproduce this error. I created a library (testlib) with a single extern C function that fills a user provided buffer with the current working directoy. This library uses Boost.Filesystem internally. Therefore the lib's Jamfile also references the Jamfile distributed with Filesystem. I created an executable (test) that calls the lib function and also uses Filesystem to get the parent directory of the current working directory (as reported by the lib function). This setup builds fine as long as I use cout to write the paths in the test exe. When I replace cout with Boost.Log (and therefore also reference the boost_log and boost_log_setup projects) this setup only builds with Boost 1.57. From 1.58 on (also tested with 1.59.b1) the project does not build because Filesystem would be built twice with different settings. Since the error can be triggered by changing the Boost version I reckon this is due to a change in one of the Jamfiles (probably Boost.Log) and not a problem of Boost.Build per se. But for reference I use Boost.Jam Version 2014.03 (the one distributed with 1.58). Since the "simple" setup consists of a few files and directories I've made it available via Github: https://github.com/norbertwenzel/boost-build-problem I've posted this here and not to Boost.Build ML since I suspect this is due to a change in one of the two libraries mentioned and not a bug or misuse in/of Boost.Build. Any help appreciated. thanks, Norbert *) The exact error message I got: error: Name clash for '
libboost_filesystem.so.1.58.0'
error:
error: Tried to build the target twice, with property sets having
error: these incompatible properties:
error:
error: - none
error: - <abi>sysv <binary-format>elf <log-api>generic
<preserve-test-targets>on <python-debugging>off <python>2.7
On 01.08.2015 14:15, Norbert Wenzel wrote:
Since the error can be triggered by changing the Boost version I reckon this is due to a change in one of the Jamfiles (probably Boost.Log) and not a problem of Boost.Build per se. But for reference I use Boost.Jam Version 2014.03 (the one distributed with 1.58).
Between 1.57 and 1.58 there were no changes to Boost.Log build system, except the switch to Boost.Config checks for the target architecture. I believe there was a change in Boost.Build that started causing this. I'm not a Boost.Build expert but as a quickfix you could try building Boost with all features explicitly set as listed in the error message.
*) The exact error message I got: error: Name clash for '
libboost_filesystem.so.1.58.0' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - none error: - <abi>sysv <binary-format>elf <log-api>generic <preserve-test-targets>on <python-debugging>off <python>2.7
on <threadapi>pthread error: error: Please make sure to have consistent requirements for these error: properties everywhere in your project, especially for install error: targets.
On 08/01/2015 02:34 PM, Andrey Semashev wrote:
On 01.08.2015 14:15, Norbert Wenzel wrote:
Since the error can be triggered by changing the Boost version I reckon this is due to a change in one of the Jamfiles (probably Boost.Log) and not a problem of Boost.Build per se. But for reference I use Boost.Jam Version 2014.03 (the one distributed with 1.58).
Between 1.57 and 1.58 there were no changes to Boost.Log build system, except the switch to Boost.Config checks for the target architecture. I believe there was a change in Boost.Build that started causing this.
Thanks for your quick reply. Filesystem also did not change between the two versions. I tried to use the Jamfiles from 1.57 to build 1.58, but that did not work. Even when copying the old context/config from 1.57 there were errors because the same config target had been built twice (error: unknown feature "<abi>"). I have not had time to look for differences between context/config config/checks/architecture but since these were recognized as the same project by bjam is it safe to assume they are very much the same?
I'm not a Boost.Build expert but as a quickfix you could try building Boost with all features explicitly set as listed in the error message.
That does not work, since I can not set <abi> in my local Jamfile, because it is reported as an unknown feature. Is it possible to declare properties like <abi> inside Jamfiles which should be referenced in my local Jamfile explicitely? thanks, Norbert
*) The exact error message I got: error: Name clash for '
libboost_filesystem.so.1.58.0'
error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - none error: - <abi>sysv <binary-format>elf <log-api>generic <preserve-test-targets>on <python-debugging>off <python>2.7
on <threadapi>pthread error: error: Please make sure to have consistent requirements for these error: properties everywhere in your project, especially for install error: targets. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 08/02/2015 11:02 AM, Norbert Wenzel wrote:
I'm not a Boost.Build expert but as a quickfix you could try building Boost with all features explicitly set as listed in the error message.
That does not work, since I can not set <abi> in my local Jamfile, because it is reported as an unknown feature.
I just found a "fix", at least for my testproject. Including the Boost libs *before* my own testlib. So it seems when testlib is loaded the parameters are already set by the configuration that is included with the Boost.Log Jamfile. I'll post an updated version of this thread to the Boost.Build ML since I don't think the project include order should matter (or is always controllable). Thanks for your help again, Norbert
participants (2)
-
Andrey Semashev -
Norbert Wenzel