January 2025 - Boost-users - lists.stage.boost.cppalliance.org

"error: Unable to find file or target named" when using BCP to change Boost namespace
by Nicholas Williams 17 Jan '25

17 Jan '25

Background: My organization uses Boost internally for one of its software products, which is itself a C++ library. Users of our library also often use Boost. As such, we must compile our Boost in a different namespace so that the Boost symbols loaded when our library loads do not interfere with whatever different-version Boost symbols our users might load. Historically, another member of the team has been responsible for building new versions of Boost, but now it's me. I am doing this the same way our code/documentation has previously done it, but it is no longer working, and the errors I'm receiving are not familiar to the team member who was previously responsible for this. The last time we built a new Boost version was 1.80.0. I am now doing it with 1.87.0. The example: Further below, I include a lot of information and build commands, but that might not be useful to you. To help, I have created a minimal reproduction program for reproducing the error. You can clone and use it here: https://github.com/beamerblvd/unable-find-target-with-boost-bcp The good: With minimal effort and using our existing tools and configurations, I was easily able to bootstrap `b2` and then run `b2` to build stock Boost with the normal `boost` namespace. All of that worked perfectly and without error. The bad: When I went to do the same thing but with our custom namespace (via bcp), things fell apart. Our existing tooling copies the untouched 1.87.0 source tree into {dir}/_src. {dir}/user-config.jam is configured as follows: ``` constant BOOST_VERSION : mybranchname-1.87.0.a ; constant MY_PLATFORM : macos15-clang16-arm-d ; constant MY_LABEL : MYextralLabel ; constant BOOST_USER_CONFIG : <my_boost/config/user.hpp> ; using clang : 16 : clang++ : <cxxflags>-fvisibility=hidden <cxxflags>-fvisibility-inlines-hidden ; ``` Within {dir}/_src, I call `bootstrap.sh` and then build `bcp` with: bc -sBOOST_ROOT={dir}/_src \ --boost-build=tools/build/src \ cxxstd=20 \ -d \ 2 \ -j \ 2 \ -q \ --prefix={dir}/bcp \ --build-dir={dir}/bcp \ --stagedir={dir}/bcp/stage \ --user-config={dir}/user-config.jam \ --layout=system \ toolset=clang-darwin \ threading=multi \ link=shared \ architecture=arm \ instruction-set=nocona \ address-model=64 \ --without-python \ --disable-icu \ variant=release tools/bcp That takes a few minutes to complete and does so without error. Once `bcp` is built, I run it with: mkdir {dir}/_dst && \ {dir}/bcp/bin/bcp --boost={dir}/_src --namespace=boost_MYextralLabel --namespace-alias Jamroot boost boost-build.jam boostcpp.jam bootstrap.bat bootstrap.sh build status tools [insert_name_of_every_dir_in_libs] {dir}/_dst That takes a few minutes to complete and does so without error. The contents of {dir}/_dst look as I would expect them to look, with diffs against {dir}/_src reflecting the change in namespace. Once complete, I cd into {dir}/_dst, re-bootstrap, and run `b2` to compile the modified Boost: b2 -sBOOST_ROOT={dir}/_dst \ --boost-build=tools/build/src \ cxxstd=20 \ -d \ 2 \ -j \ 2 \ -q \ --prefix={dir} \ --build-dir={dir}/shobj \ --stagedir={dir}/stage \ --user-config={dir}/user-config.jam \ --layout=system \ toolset=clang-darwin \ threading=multi \ link=shared \ architecture=arm \ instruction-set=nocona \ address-model=64 \ --without-python \ --disable-icu \ variant=debug This fails quickly, here: ... - native syslog supported : yes [2] - pthread supports robust mutexes : no [2] - Boost.Regex is header-only : yes [2] error: Unable to find file or target named error: '/boost/align//boost_align' error: referred to from project at error: '{dir}/_dst/libs/atomic/build' make: *** [build] Error 1 I have tried dozens of different things over the past two days and can't remember most of them, but they didn't change the outcome, so I don't supposed they're relevant. The one thing that *did* change the outcome is that, after running `bcp` and before re-bootstrapping in {dir}/_dst, I tried deleting the {dir}/_dst/boost directory. This still failed, but it got slightly further and failed with a different (albeit extremely similar) error: ... - std_wstreambuf : no [2] - std_wstreambuf : no [3] - BOOST_COMP_GNUC >= 4.3.0 : no [2] - BOOST_COMP_GNUC >= 4.3.0 : no [4] error: Unable to find file or target named error: 'libs/thread/build//boost_MYextralLabel_thread' error: referred to from project at error: '.' make: *** [build] Error 1 I feel like I've exhausted my ability to discern what the problem is. Other than updating a handful of compiler flags (like changing cxxstd=17 to cxxstd=20), I'm doing this the same way we have (allegedly) always done it, but it's not working anymore and I don't know why. I would appreciate any guidance you can offer. Thank you, Nick

3 3

"error: No best alternative for {dir}/libs/mpi/build/boost_mpi", but the build succeeds
by Nicholas Williams 17 Jan '25

17 Jan '25

I'm building the full stock, unmodified Boost 1.87.0. I have previously built Boost 1.80.0 without issue. After bootstrapping, when running `b2` to actually build Boost, I get the following "errors": ... - has stat::st_birthtimespec : yes [5] - has fdopendir(O_NOFOLLOW) : yes [5] - has dirent::d_type : yes [5] - has POSIX *at APIs : no [5] - has fallocate : no [5] - cxx11_static_assert : yes [5] error: No best alternative for {dir}/libs/mpi/build/boost_mpi with <abi>aapcs <address-model>64 <architecture>arm <asynch-exceptions>off <binary-format>mach-o <boost.beast.allow-deprecated>on <boost.beast.separate-compilation>on <boost.cobalt.executor>any_io_executor <boost.cobalt.pmr>std <context-impl>fcontext <coverage>off <cxxstd-dialect>iso <cxxstd>20 <debug-symbols>off <exception-handling>on <extern-c-nothrow>off <inlining>full <instruction-set>nocona <known-warnings>hide <link>shared <optimization>speed <os>MACOSX <pch>on <preserve-test-targets>on <profiling>off <python-debugging>off <python>3.9 <rtti>on <runtime-debugging>off <runtime-link>shared <stdlib>native <strip>off <target-os>darwin <testing.execute>on <threadapi>pthread <threading>multi <toolset-clang:platform>darwin <toolset-clang:version>14 <toolset>clang <variant>release <vectorize>off <visibility>hidden <warnings-as-errors>off <warnings>on <x-deduced-platform>arm_64 matched: (empty) matched: (empty) error: No best alternative for {dir}/libs/mpi/build/boost_mpi with <abi>aapcs <address-model>64 <architecture>arm <asynch-exceptions>off <binary-format>mach-o <boost.beast.allow-deprecated>on <boost.beast.separate-compilation>on <boost.cobalt.executor>any_io_executor <boost.cobalt.pmr>std <coverage>off <cxxstd-dialect>iso <cxxstd>20 <debug-symbols>off <exception-handling>on <extern-c-nothrow>off <inlining>full <instruction-set>nocona <known-warnings>hide <link>shared <optimization>speed <os>MACOSX <pch>on <preserve-test-targets>on <profiling>off <python-debugging>off <python>3.9 <rtti>on <runtime-debugging>off <runtime-link>shared <stdlib>native <strip>off <target-os>darwin <testing.execute>on <threadapi>pthread <threading>multi <toolset-clang:platform>darwin <toolset-clang:version>14 <toolset>clang <variant>release <vectorize>off <visibility>hidden <warnings-as-errors>off <warnings>on <x-deduced-platform>arm_64 matched: (empty) matched: (empty) - gcc visibility : yes [2] - cxx14_decltype_auto : yes [2] - cxx14_generic_lambdas : yes [2] ... I used scare quotes around "errors," because these errors do not appear to actually break anything. The build completes fully and successfully, and all the libraries are built as expected. It appears to be more of a warning than an error, but I don't love warnings either, so I'd like to solve it. The only relevant result I could find Googling about this was [this other mailing list message]( https://lists.boost.org/Archives/boost/2024/11/258275.php) which was a reply to "[release] Boost 1.87.0 Beta 2 Release Candidate is available," and to which nobody ever replied. Doesn't really clear anything up for me. FWIW, I get these "errors" on RHEL 8 GCC 8, 9 GCC 11, and 9 GCC 14; Ubuntu 20.04 GCC 9, 22.04 GCC 11, and 24.04 GCC 13; macOS 12 Clang 14 (Intel and ARM), 14 Clang 16 (Intel and ARM), and 15 Clang 16 (Intel and ARM); Windows 10 MSVC 2022 and 11 MSVR 2022; and Windows Server 2022 MSVC 2022 and 2025 MSVC 2022. Any insights or guidance would be appreciated. Thanks, Nick

2 3

ICU not found while building Boost
by Cory Riddell 13 Jan '25

13 Jan '25

I'm having trouble building Boost 1.87 on Windows using the latest VS2022. I'm starting from the "x64 Native Tools Command Prompt for VS 2022". I've downloaded the latest ICU binaries and updated my PATH, LIB, and INCLUDE environment variables: set PATH=%PATH%;D:\icu\bin64 set LIB=%LIB%;D:\icu\lib64 set INCLUDE=%INCLUDE%;D:\icu\include I go into my boost directory and run bootstrap.bat. It seems to complete, creating b2.exe. I then run "b2 address-model=64" and it's not finding icu: E:\boost_1_87_0>b2 address-model=64 Performing configuration checks - default address-model : 64-bit [1] - default architecture : x86 [1] Building the Boost C++ Libraries. warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam. note: to suppress this message, pass "--without-graph_parallel" to bjam. - icu : no [2] - iconv (libc) : no [2] - iconv (separate) : no [2] - cxx11_auto_declarations : yes [2] - cxx11_decltype : yes [2] I ctrl-c to quit at this point and looked at my config.log and it doesn't seem to find icu when building has_icu_test.obj: compile-c-c++ bin.v2\libs\locale\build\msvc-14.3\debug\x86_64\link-static\threading-multi\has_icu_test.obj has_icu_test.cpp E:\boost_1_87_0\libs\locale\build\has_icu_test.cpp(6): fatal error C1083: Cannot open include file: 'unicode/coll.h': No such file or directory The file D:\icu\include\unicode\coll.h does exist though. Is there some reason my environment variables don't make it to the processes kicked off by b2? Or am I overlooking something obvious? Any help is greatly appreciated. Cory

2 3

Generating a fully namespaced boost installation
by Janosch Machowinski 07 Jan '25

07 Jan '25

Hi, we ran into an issue, were the system installation of boost is exposed by a third party lib we rely on (ROS), but it contains a bug. The bug in boost is fixed in a way more recent version of boost, therefore we are looking into using two versions of boost at the same time. To archive this, we want to run the newer boost version in a custom namespace, and already found the bcp tool, that helps with generating a namespace version of boost for us. The issue we are now hitting is, that the includes in our custom boost version are not altered by bcp, and therefore pick up the system headers. E.g. geometry.hpp contains '#include <boost/geometry/geometry.hpp>' but in order to work for us, it would need to be '#include <our_boost/geometry/geometry.hpp>'. Are we missing some magical bcp option, or is this just not supported ? Thx Janosch -- Janosch Machowinski cellumation GmbH | Linzer Str.5 | 28359 Bremen | Germany P: +49 421 331135 35 F: +49 421 331135 99 J.Machowinski(a)cellumation.com Website | YouTube Registernummer: HRB32569 | Registergericht: Amtsgericht Bremen | Ust-Id.Nr.: DE313140406 Geschäftsführer: Dr.-Ing. Hendrik Thamer, Claudio Uriarte Diese E-Mail und alle damit übermittelten Dateien sind vertraulich und ausschließlich für die Verwendung durch die Person oder Gesellschaft, an die sie adressiert sind, bestimmt. Die Weitergabe sowie Vervielfältigung, Verwertung und Mitteilung des Inhalts der E-Mail sind nur mit unserer ausdrücklichen Genehmigung gestattet. Alle Rechte vorbehalten, insbesondere für den Fall der Schutzrechtsanmeldung This e-mail and all files transmitted with it are confidential and intended exclusively for use by the person or company to whom they are addressed. The transmission, reproduction, exploitation and communication of the contents of the e-mail are only permitted with our express permission. All rights reserved, in particular in the event of an application for industrial property rights.

2 3