[release] Boost 1.84.0 Beta 1 Release Candidate 1 is available
Available at: <https://boostorg.jfrog.io/artifactory/main/beta/1.84.0.beta1/source/> The SHA256 checksums are as follows: f8a9f21580961536a95fb7fcf9deebde45d7e0e94ddd81402f1e37ae2c590410 boost_1_84_0_b1_rc1.tar.bz2 224d595cc666c19b91214c5e9cced3988d08063146dfad9f616c481d52626f27 boost_1_84_0_b1_rc1.zip 3e4765c41974c763b7d4a67a432569bf75d3367d7a6b72c4ac9458e5004c59dc boost_1_84_0_b1_rc1.7z de9b35e232e4b1769f4d800ec01255a9c2546639be43e45b16ce6d109c088e99 boost_1_84_0_b1_rc1.tar.gz As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Release Managers
On Nov 9, 2023, at 11:53 AM, Marshall Clow <mclow.lists@gmail.com> wrote:
Available at: <https://boostorg.jfrog.io/artifactory/main/beta/1.84.0.beta1/source/>
The SHA256 checksums are as follows:
f8a9f21580961536a95fb7fcf9deebde45d7e0e94ddd81402f1e37ae2c590410 boost_1_84_0_b1_rc1.tar.bz2 224d595cc666c19b91214c5e9cced3988d08063146dfad9f616c481d52626f27 boost_1_84_0_b1_rc1.zip 3e4765c41974c763b7d4a67a432569bf75d3367d7a6b72c4ac9458e5004c59dc boost_1_84_0_b1_rc1.7z de9b35e232e4b1769f4d800ec01255a9c2546639be43e45b16ce6d109c088e99 boost_1_84_0_b1_rc1.tar.gz
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
I have built the boost libraries on a x86_64 machine running Mac OS X 13.6.1 using "Apple clang version 15.0.0 (clang-1500.0.40.1)” The libraries were built successfully using C++11/14/17/20/2B. However, when building for C++03, the following libraries failed to build * Any * lexical_cast * thread * type_index Full log attached — Marshall
On Nov 9, 2023, at 3:28 PM, Peter Dimov via Boost <boost@lists.boost.org> wrote:
Marshall Clow wrote:
The libraries were built successfully using C++11/14/17/20/2B.
However, when building for C++03, the following libraries failed to build
* Any * lexical_cast * thread * type_index
These libraries don't support C++03 anymore.
Apparently not everyone has gotten the message. lexical_cast.h is included from boost/graph/graphml.hpp any.h is included from contract. Here are the files that failed to compile: ...failed clang-darwin.compile.c++ bin.v2/libs/contract/build/clang-darwin-15/release/cxxstd-03-iso/link-static/threading-multi/visibility-hidden/contract.o... ...failed clang-darwin.compile.c++ bin.v2/libs/contract/build/clang-darwin-15/release/cxxstd-03-iso/threading-multi/visibility-hidden/contract.o... ...failed clang-darwin.compile.c++ bin.v2/libs/graph/build/clang-darwin-15/release/cxxstd-03-iso/link-static/threading-multi/visibility-hidden/graphml.o... ...failed clang-darwin.compile.c++ bin.v2/libs/graph/build/clang-darwin-15/release/cxxstd-03-iso/link-static/threading-multi/visibility-hidden/read_graphviz_new.o... ...failed clang-darwin.compile.c++ bin.v2/libs/graph/build/clang-darwin-15/release/cxxstd-03-iso/threading-multi/visibility-hidden/graphml.o... ...failed clang-darwin.compile.c++ bin.v2/libs/graph/build/clang-darwin-15/release/cxxstd-03-iso/threading-multi/visibility-hidden/read_graphviz_new.o... ...failed clang-darwin.compile.c++ bin.v2/libs/program_options/build/clang-darwin-15/release/cxxstd-03-iso/link-static/threading-multi/visibility-hidden/cmdline.o... ...failed clang-darwin.compile.c++ bin.v2/libs/program_options/build/clang-darwin-15/release/cxxstd-03-iso/link-static/threading-multi/visibility-hidden/options_description.o... ...failed clang-darwin.compile.c++ bin.v2/libs/program_options/build/clang-darwin-15/release/cxxstd-03-iso/link-static/threading-multi/visibility-hidden/parsers.o... ...failed clang-darwin.compile.c++ bin.v2/libs/program_options/build/clang-darwin-15/release/cxxstd-03-iso/link-static/threading-multi/visibility-hidden/split.o... ...failed clang-darwin.compile.c++ bin.v2/libs/program_options/build/clang-darwin-15/release/cxxstd-03-iso/link-static/threading-multi/visibility-hidden/value_semantic.o... ...failed clang-darwin.compile.c++ bin.v2/libs/program_options/build/clang-darwin-15/release/cxxstd-03-iso/link-static/threading-multi/visibility-hidden/variables_map.o... ...failed clang-darwin.compile.c++ bin.v2/libs/program_options/build/clang-darwin-15/release/cxxstd-03-iso/link-static/threading-multi/visibility-hidden/winmain.o... ...failed clang-darwin.compile.c++ bin.v2/libs/program_options/build/clang-darwin-15/release/cxxstd-03-iso/threading-multi/visibility-hidden/cmdline.o... ...failed clang-darwin.compile.c++ bin.v2/libs/program_options/build/clang-darwin-15/release/cxxstd-03-iso/threading-multi/visibility-hidden/options_description.o... ...failed clang-darwin.compile.c++ bin.v2/libs/program_options/build/clang-darwin-15/release/cxxstd-03-iso/threading-multi/visibility-hidden/parsers.o... ...failed clang-darwin.compile.c++ bin.v2/libs/program_options/build/clang-darwin-15/release/cxxstd-03-iso/threading-multi/visibility-hidden/split.o... ...failed clang-darwin.compile.c++ bin.v2/libs/program_options/build/clang-darwin-15/release/cxxstd-03-iso/threading-multi/visibility-hidden/value_semantic.o... ...failed clang-darwin.compile.c++ bin.v2/libs/program_options/build/clang-darwin-15/release/cxxstd-03-iso/threading-multi/visibility-hidden/variables_map.o... ...failed clang-darwin.compile.c++ bin.v2/libs/program_options/build/clang-darwin-15/release/cxxstd-03-iso/threading-multi/visibility-hidden/winmain.o... ...failed clang-darwin.compile.c++ bin.v2/libs/thread/build/clang-darwin-15/release/cxxstd-03-iso/link-static/threading-multi/visibility-hidden/pthread/thread.o... ...failed clang-darwin.compile.c++ bin.v2/libs/thread/build/clang-darwin-15/release/cxxstd-03-iso/threading-multi/visibility-hidden/pthread/thread.o... Looking at the meta/libraries.json files. Boost.Contract has no language requirement Boost.Graph requires C++03. Boost.ProgramOptions requires C++11 — so why is it getting built? Boost.Thread requires C++11 — so why is it getting built? — Marshall
Marshall Clow wrote:
On Nov 9, 2023, at 3:28 PM, Peter Dimov via Boost <boost@lists.boost.org> wrote:
Marshall Clow wrote:
The libraries were built successfully using C++11/14/17/20/2B.
However, when building for C++03, the following libraries failed to build
* Any * lexical_cast * thread * type_index
These libraries don't support C++03 anymore.
Apparently not everyone has gotten the message. lexical_cast.h is included from boost/graph/graphml.hpp any.h is included from contract.
Here are the files that failed to compile: [...]
I think I remember that libc++ supported some C++11 library features even under C++03, so under a different stdlib there might be even more failures.
Looking at the meta/libraries.json files. Boost.Contract has no language requirement Boost.Graph requires C++03. Boost.ProgramOptions requires C++11 — so why is it getting built? Boost.Thread requires C++11 — so why is it getting built?
meta/libraries.json doesn't affect what is and what isn't getting built. But the first question we need to answer before proceeding is, are we going to even support building under C++03? Not much is going to get built (if anything at all.) Investing effort into making sure everything is good and proper under C++03 doesn't seem to have much return.
Looks good on the trimmed down (only supporting msvc-14.0 and up now) set of Windows/Visual Studio builds toolset arch compile Link Execute msvc-14.0 32 X X X msvc-14.0 64 X X X msvc-14.1 32 X X X msvc-14.1 64 X X X msvc-14.2 32 X X X msvc-14.2 64 X X X msvc-14.3 32 X X X msvc-14.3 64 X X X Compile means that the b2 command completed without errors Link means that visual studio was able to link a sample executable to a library (libboost_thread-vcXXX-mt[-gd]-1_XX.lib) generated Execute means that the linked program executed without errors. Full build logs can be found here: https://gist.github.com/teeks99/fe079fc1a0c6403f1e2354964be5a34f Tom On Thu, Nov 9, 2023 at 1:53 PM Marshall Clow via Boost < boost@lists.boost.org> wrote:
Available at: < https://boostorg.jfrog.io/artifactory/main/beta/1.84.0.beta1/source/>
The SHA256 checksums are as follows:
f8a9f21580961536a95fb7fcf9deebde45d7e0e94ddd81402f1e37ae2c590410 boost_1_84_0_b1_rc1.tar.bz2 224d595cc666c19b91214c5e9cced3988d08063146dfad9f616c481d52626f27 boost_1_84_0_b1_rc1.zip 3e4765c41974c763b7d4a67a432569bf75d3367d7a6b72c4ac9458e5004c59dc boost_1_84_0_b1_rc1.7z de9b35e232e4b1769f4d800ec01255a9c2546639be43e45b16ce6d109c088e99 boost_1_84_0_b1_rc1.tar.gz
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
-- The Release Managers
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Am 09.11.2023 um 20:53 schrieb Marshall Clow via Boost:
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
works! first version since 1.80 on Linux solving an long open Phoenix bug, thanks all
From: Boost <boost-bounces@lists.boost.org> On Behalf Of Marshall Clow via Boost Sent: Thursday, 9 November 2023 20:54 Subject: [boost] [release] Boost 1.84.0 Beta 1 Release Candidate 1 is available
Please report both success and failure, and anything else that is noteworthy.
Could the fixes in Boost.Test be merged to master, please? I'm especially waiting for https://github.com/boostorg/test/commit/cada8c11df0ee360c2a05b0f44daeae68934..., which fixes a regression from https://github.com/boostorg/test/commit/884646245fe5e4efb0d23a0f5e405110faed.... Thanks, Marcel
On Fri, Nov 10, 2023 at 11:18, Marcel Raad via Boost <[boost@lists.boost.org](mailto:On Fri, Nov 10, 2023 at 11:18, Marcel Raad via Boost <<a href=)> wrote:
From: Boost <boost-bounces@lists.boost.org> On Behalf Of Marshall Clow via Boost Sent: Thursday, 9 November 2023 20:54 Subject: [boost] [release] Boost 1.84.0 Beta 1 Release Candidate 1 is available
Please report both success and failure, and anything else that is noteworthy.
Could the fixes in Boost.Test be merged to master, please? I'm especially waiting for https://github.com/boostorg/test/commit/cada8c11df0ee360c2a05b0f44daeae68934..., which fixes a regression from https://github.com/boostorg/test/commit/884646245fe5e4efb0d23a0f5e405110faed....
Thanks, Marcel
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Marcel, Once master is back open for bug fixes I will. I thought I had already, but clearly not. Sorry about that. Matt
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
I have successfully built the beta under Ubuntu 22.04, gcc 12. I have successfully built https://github.com/anarthal/servertech-chat and run its tests with the beta, which exercises System, Json, MultiIndex, Url, Beast, Redis, MySQL, Asio, Variant2, Regex, Test and Describe. Python, Container, Archive, MPI and Url emitted warnings when building. While I suppose they're mostly spurious, you can check the build log here: https://drive.google.com/file/d/1-Yt3pdLxz9uqfPCd71SKI57C7hSAMCmL/view?usp=s... Regards, Ruben.
On Tue, Nov 14, 2023 at 3:33 AM Ruben Perez via Boost <boost@lists.boost.org> wrote:
I have successfully built https://github.com/anarthal/servertech-chat and run its tests with the beta, which exercises System, Json, MultiIndex, Url, Beast, Redis, MySQL, Asio, Variant2, Regex, Test and Describe.
Thank you for testing the release and spearheading the Boost Server Tech project. Has the Server Tech project been announced to the list? Thanks
Thank you for testing the release and spearheading the Boost Server Tech project. Has the Server Tech project been announced to the list?
Yep, it has. We even had some constructive discussions that led to interesting stuff. I'll do a quick recap here in case anyone hasn't heard of it yet. ServerTech is a collection of projects intended to show how Boost can be used to write high-performance web servers. It's something I started as a relatively realistic test ground for Boost.MySQL features, that could also be shown as an example to users. https://github.com/anarthal/servertech-chat Should you have any questions or suggestions about it, let me know. Ruben.
On 09/11/2023 20:53, Marshall Clow via Boost wrote:
Available at: <https://boostorg.jfrog.io/artifactory/main/beta/1.84.0.beta1/source/>
The SHA256 checksums are as follows:
f8a9f21580961536a95fb7fcf9deebde45d7e0e94ddd81402f1e37ae2c590410 boost_1_84_0_b1_rc1.tar.bz2 224d595cc666c19b91214c5e9cced3988d08063146dfad9f616c481d52626f27 boost_1_84_0_b1_rc1.zip 3e4765c41974c763b7d4a67a432569bf75d3367d7a6b72c4ac9458e5004c59dc boost_1_84_0_b1_rc1.7z de9b35e232e4b1769f4d800ec01255a9c2546639be43e45b16ce6d109c088e99 boost_1_84_0_b1_rc1.tar.gz
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
-- The Release Managers
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi, I tried to build with clang (16.0.6) and it causes a build failure. Here is the gist with the output: https://gist.github.com/matthijs/f60a54d6f5ce86b3ec35c83d751c9631 Here is the partial output of the compile error (its the first one where it happens): /usr/bin/ld: bin.v2/libs/filesystem/build/clang-linux-16/release/threading-multi/visibility-hidden/operations.o: in function `boost::filesystem::detail::absolute(boost::filesystem::path const&, boost::filesystem::path const&, boost::system::error_code*)': operations.cpp:(.text+0xd8): undefined reference to `operator new(unsigned long)' /usr/bin/ld: operations.cpp:(.text+0x11c): undefined reference to `operator new(unsigned long)' /usr/bin/ld: operations.cpp:(.text+0x20c): undefined reference to `operator delete(void*)' /usr/bin/ld: operations.cpp:(.text+0x21d): undefined reference to `operator delete(void*)' /usr/bin/ld: operations.cpp:(.text+0x2ca): undefined reference to `operator new(unsigned long)' /usr/bin/ld: operations.cpp:(.text+0x3f5): undefined reference to `operator delete(void*)' /usr/bin/ld: operations.cpp:(.text+0x425): undefined reference to `operator delete(void*)' /usr/bin/ld: operations.cpp:(.text+0x4a9): undefined reference to `operator new(unsigned long)' /usr/bin/ld: operations.cpp:(.text+0x5b0): undefined reference to `operator delete(void*)' /usr/bin/ld: operations.cpp:(.text+0x68a): undefined reference to `operator new(unsigned long)' /usr/bin/ld: operations.cpp:(.text+0x70a): undefined reference to `std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::append(char const*, unsigned long)' /usr/bin/ld: operations.cpp:(.text+0x721): undefined reference to `operator new(unsigned long)' /usr/bin/ld: operations.cpp:(.text+0x79d): undefined reference to `std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::append(char const*, unsigned long)' /usr/bin/ld: operations.cpp:(.text+0x7ae): undefined reference to `operator delete(void*)' /usr/bin/ld: operations.cpp:(.text+0x815): undefined reference to `operator new(unsigned long)' /usr/bin/ld: operations.cpp:(.text+0x8a9): undefined reference to `operator delete(void*)' /usr/bin/ld: operations.cpp:(.text+0x907): undefined reference to `operator new(unsigned long)' /usr/bin/ld: operations.cpp:(.text+0x9b7): undefined reference to `operator delete(void*)' /usr/bin/ld: operations.cpp:(.text+0x9c8): undefined reference to `operator delete(void*)' /usr/bin/ld: operations.cpp:(.text+0xba7): undefined reference to `operator delete(void*)' /usr/bin/ld: operations.cpp:(.text+0xbcb): undefined reference to `operator delete(void*)' /usr/bin/ld: operations.cpp:(.text+0xbdc): undefined reference to `operator delete(void*)' Regards, Matthijs
Matthijs Möhlmann wrote:
Hi,
I tried to build with clang (16.0.6) and it causes a build failure.
Here is the gist with the output: https://gist.github.com/matthijs/f60a54d6f5ce86b3ec35c83d751c9631
Here is the partial output of the compile error (its the first one where it happens): /usr/bin/ld: bin.v2/libs/filesystem/build/clang-linux-16/release/threading-multi/visibility- hidden/operations.o: in function `boost::filesystem::detail::absolute(boost::filesystem::path const&, boost::filesystem::path const&, boost::system::error_code*)': operations.cpp:(.text+0xd8): undefined reference to `operator new(unsigned long)' ...
This might be caused by Filesystem adding <linkflags>"-Wl,--no-undefined" to its build, which might (for some unfathomable reason) interfere with your linkflags="-stdlib=libc++". As a general rule, you should prefer using the built-in b2 features for stdlib selection and C++ standard level; instead of cxxflags="-I/usr/include/libcxxabi -std=c++20 -stdlib=libc++" linkflags="-stdlib=libc++" try stdlib=libc++ cxxstd=20 and, if needed, include=/usr/include/libcxxabi .
On 16/11/2023 15:01, Peter Dimov via Boost wrote:
Matthijs Möhlmann wrote:
Hi,
I tried to build with clang (16.0.6) and it causes a build failure.
Here is the gist with the output: https://gist.github.com/matthijs/f60a54d6f5ce86b3ec35c83d751c9631
Here is the partial output of the compile error (its the first one where it happens): /usr/bin/ld: bin.v2/libs/filesystem/build/clang-linux-16/release/threading-multi/visibility- hidden/operations.o: in function `boost::filesystem::detail::absolute(boost::filesystem::path const&, boost::filesystem::path const&, boost::system::error_code*)': operations.cpp:(.text+0xd8): undefined reference to `operator new(unsigned long)' ...
This might be caused by Filesystem adding <linkflags>"-Wl,--no-undefined" to its build, which might (for some unfathomable reason) interfere with your linkflags="-stdlib=libc++".
As a general rule, you should prefer using the built-in b2 features for stdlib selection and C++ standard level; instead of
cxxflags="-I/usr/include/libcxxabi -std=c++20 -stdlib=libc++" linkflags="-stdlib=libc++"
try
stdlib=libc++ cxxstd=20
and, if needed,
include=/usr/include/libcxxabi
.
I tried your suggestion but still the same errors. If I say --with-toolset=clang is the linker from llvm also selected or do I have to add the flag linker=... to that list? Regards, Matthijs
Matthijs Möhlmann wrote:
As a general rule, you should prefer using the built-in b2 features for stdlib selection and C++ standard level; instead of
cxxflags="-I/usr/include/libcxxabi -std=c++20 -stdlib=libc++" linkflags="- stdlib=libc++"
try
stdlib=libc++ cxxstd=20
and, if needed,
include=/usr/include/libcxxabi
.
I tried your suggestion but still the same errors.
If I say --with-toolset=clang is the linker from llvm also selected or do I have to add the flag linker=... to that list?
There's no linker= feature, but I suppose you can try linkflags=-fuse-ld=lld-16 since I see that in LDFLAGS in your log.
On 16/11/2023 15:43, Peter Dimov via Boost wrote:
Matthijs Möhlmann wrote:
As a general rule, you should prefer using the built-in b2 features for stdlib selection and C++ standard level; instead of
cxxflags="-I/usr/include/libcxxabi -std=c++20 -stdlib=libc++" linkflags="- stdlib=libc++" try
stdlib=libc++ cxxstd=20
and, if needed,
include=/usr/include/libcxxabi
.
I tried your suggestion but still the same errors.
If I say --with-toolset=clang is the linker from llvm also selected or do I have to add the flag linker=... to that list? There's no linker= feature, but I suppose you can try
linkflags=-fuse-ld=lld-16
since I see that in LDFLAGS in your log.
Ok, tried that. Same error although somewhat different output. I go with your suggestion and keep 'stdlib=libc++ cxxstd=20'. Is the correct location to report this bug: https://github.com/boostorg/filesystem/issues ? Regards, Matthijs
Matthijs Möhlmann wrote:
There's no linker= feature, but I suppose you can try
linkflags=-fuse-ld=lld-16
since I see that in LDFLAGS in your log.
Ok, tried that. Same error although somewhat different output. I go with your suggestion and keep 'stdlib=libc++ cxxstd=20'.
Is the correct location to report this bug: https://github.com/boostorg/filesystem/issues ?
Looks like it is, as the problem seems confined to Filesystem.
On 11/16/23 18:14, Peter Dimov via Boost wrote:
Matthijs Möhlmann wrote:
There's no linker= feature, but I suppose you can try
linkflags=-fuse-ld=lld-16
since I see that in LDFLAGS in your log.
Ok, tried that. Same error although somewhat different output. I go with your suggestion and keep 'stdlib=libc++ cxxstd=20'.
Is the correct location to report this bug: https://github.com/boostorg/filesystem/issues ?
Looks like it is, as the problem seems confined to Filesystem.
So far I don't see this as a Boost.Filesystem bug. The missing symbols (at least, those which were posted here earlier) are standard C++ symbols, which by default should be linked automatically by the compiler. If the compiler doesn't do that, this is a compiler bug as far as I'm concerned. So the right place to report it is: https://github.com/llvm/llvm-project/issues/ Incidentally, I have reported a similar problem before here: https://github.com/llvm/llvm-project/issues/60578 and it looks like it hasn't been fixed yet. As for a workaround, I suspect the problem can be worked around by manually adding linking with the standard library that defines those missing symbols. For example, `operator delete` is defined in libc++abi, so you may fix the problem by adding `linkflags=c++abi` to `b2` command line.
On 11/16/23 18:28, Andrey Semashev wrote:
On 11/16/23 18:14, Peter Dimov via Boost wrote:
Matthijs Möhlmann wrote:
There's no linker= feature, but I suppose you can try
linkflags=-fuse-ld=lld-16
since I see that in LDFLAGS in your log.
Ok, tried that. Same error although somewhat different output. I go with your suggestion and keep 'stdlib=libc++ cxxstd=20'.
Is the correct location to report this bug: https://github.com/boostorg/filesystem/issues ?
Looks like it is, as the problem seems confined to Filesystem.
So far I don't see this as a Boost.Filesystem bug. The missing symbols (at least, those which were posted here earlier) are standard C++ symbols, which by default should be linked automatically by the compiler. If the compiler doesn't do that, this is a compiler bug as far as I'm concerned. So the right place to report it is:
https://github.com/llvm/llvm-project/issues/
Incidentally, I have reported a similar problem before here:
https://github.com/llvm/llvm-project/issues/60578
and it looks like it hasn't been fixed yet.
As for a workaround, I suspect the problem can be worked around by manually adding linking with the standard library that defines those missing symbols. For example, `operator delete` is defined in libc++abi, so you may fix the problem by adding `linkflags=c++abi` to `b2` command line.
Sorry, the command line option should be `linkflags=-lc++abi`.
On 16/11/2023 16:32, Andrey Semashev via Boost wrote:
On 11/16/23 18:28, Andrey Semashev wrote:
On 11/16/23 18:14, Peter Dimov via Boost wrote:
Matthijs Möhlmann wrote:
There's no linker= feature, but I suppose you can try
linkflags=-fuse-ld=lld-16
since I see that in LDFLAGS in your log.
Ok, tried that. Same error although somewhat different output. I go with your suggestion and keep 'stdlib=libc++ cxxstd=20'.
Is the correct location to report this bug: https://github.com/boostorg/filesystem/issues ? Looks like it is, as the problem seems confined to Filesystem. So far I don't see this as a Boost.Filesystem bug. The missing symbols (at least, those which were posted here earlier) are standard C++ symbols, which by default should be linked automatically by the compiler. If the compiler doesn't do that, this is a compiler bug as far as I'm concerned. So the right place to report it is:
https://github.com/llvm/llvm-project/issues/
Incidentally, I have reported a similar problem before here:
https://github.com/llvm/llvm-project/issues/60578
and it looks like it hasn't been fixed yet.
As for a workaround, I suspect the problem can be worked around by manually adding linking with the standard library that defines those missing symbols. For example, `operator delete` is defined in libc++abi, so you may fix the problem by adding `linkflags=c++abi` to `b2` command line. Sorry, the command line option should be `linkflags=-lc++abi`.
That didn't work either. Same error. Regards, Matthijs
On 11/16/23 18:43, Matthijs Möhlmann via Boost wrote:
On 16/11/2023 16:32, Andrey Semashev via Boost wrote:
On 11/16/23 18:28, Andrey Semashev wrote:
As for a workaround, I suspect the problem can be worked around by manually adding linking with the standard library that defines those missing symbols. For example, `operator delete` is defined in libc++abi, so you may fix the problem by adding `linkflags=c++abi` to `b2` command line.
Sorry, the command line option should be `linkflags=-lc++abi`.
That didn't work either. Same error.
Do you mean the error still lists `operator delete` and similar core language symbols as unresolved? If so then either the compiler is terminally broken, or there must be some issue with your installation. Perhaps, inconsistent libc++abi version? BTW, we do test clang-16 in CI, and it passes: https://github.com/boostorg/filesystem/actions/runs/6449121898 so I'm leaning towards some installation or configuration issue.
On 16/11/2023 16:50, Andrey Semashev via Boost wrote:
On 11/16/23 18:43, Matthijs Möhlmann via Boost wrote:
On 16/11/2023 16:32, Andrey Semashev via Boost wrote:
On 11/16/23 18:28, Andrey Semashev wrote:
As for a workaround, I suspect the problem can be worked around by manually adding linking with the standard library that defines those missing symbols. For example, `operator delete` is defined in libc++abi, so you may fix the problem by adding `linkflags=c++abi` to `b2` command line. Sorry, the command line option should be `linkflags=-lc++abi`.
That didn't work either. Same error. Do you mean the error still lists `operator delete` and similar core language symbols as unresolved?
If so then either the compiler is terminally broken, or there must be some issue with your installation. Perhaps, inconsistent libc++abi version?
BTW, we do test clang-16 in CI, and it passes:
https://github.com/boostorg/filesystem/actions/runs/6449121898
so I'm leaning towards some installation or configuration issue.
_______________________________________________ Unsubscribe & other changes:http://lists.boost.org/mailman/listinfo.cgi/boost
Gotcha, when adding the flags as follows: linkflags="-lc++ -ldc++abi" it works correctly and I have every library build on my system. Then I guess it has to do with my library path. I have clang installed from the debian repository here:https://apt.llvm.org/ I have an user-config.jam in the root of my home directory and it is as follows: import toolset : using ; using clang : 16 : clang-16 ; option jobs : 8 ; Maybe that interferes somehow with the ability to link to the correct library? I am not sure where to look further to have this resolved. Regards, Matthijs
On 11/16/23 19:02, Matthijs Möhlmann via Boost wrote:
On 16/11/2023 16:50, Andrey Semashev via Boost wrote:
On 11/16/23 18:43, Matthijs Möhlmann via Boost wrote:
On 16/11/2023 16:32, Andrey Semashev via Boost wrote:
On 11/16/23 18:28, Andrey Semashev wrote:
As for a workaround, I suspect the problem can be worked around by manually adding linking with the standard library that defines those missing symbols. For example, `operator delete` is defined in libc++abi, so you may fix the problem by adding `linkflags=c++abi` to `b2` command line. Sorry, the command line option should be `linkflags=-lc++abi`.
That didn't work either. Same error. Do you mean the error still lists `operator delete` and similar core language symbols as unresolved?
If so then either the compiler is terminally broken, or there must be some issue with your installation. Perhaps, inconsistent libc++abi version?
BTW, we do test clang-16 in CI, and it passes:
https://github.com/boostorg/filesystem/actions/runs/6449121898
so I'm leaning towards some installation or configuration issue.
Gotcha, when adding the flags as follows: linkflags="-lc++ -ldc++abi" it works correctly and I have every library build on my system.
I'm assuming, you meant "-lc++abi" (note the missing "d").
Then I guess it has to do with my library path. I have clang installed from the debian repository here:https://apt.llvm.org/
Yes, but note that there are different repositories for different Debian and Ubuntu versions, and also for different clang major releases. When you use those repositories, make sure you specify the correct versions in the repository line, and also specify the version in the package names. For example, for clang-16 you need to install clang-16, libc++-16-dev and libc++abi-16-dev - all come from apt.llvm.org.
I have an user-config.jam in the root of my home directory and it is as follows: import toolset : using ; using clang : 16 : clang-16 ;
option jobs : 8 ;
Our user-config.jam should look like this: using clang : : clang++-16 ; See here for how it's composed: https://github.com/boostorg/filesystem/blob/53eabaeabbf85fda2915a03612323df7... Note that the compiler executable is clang++-16, not clang-16. The former is a C++ compiler, the latter is C. Presumably, the C compiler doesn't add C++ standard libraries to the linker. But I would also expect it to fail to compile C++ code, or at least display some warning, but maybe it doesn't. Try changing to clang++-16 and compile without explicit `-lc++ -lc++abi` flags.
Maybe that interferes somehow with the ability to link to the correct library?
I am not sure where to look further to have this resolved.
One last thing I'd like to note is that those `-lc++ -lc++abi` flags, if you specify those, should come last in the linker command line, and in that order. If you have multiple linker flags specified in the command line, make sure these two come after any other libraries or object files.
On 16/11/2023 17:25, Andrey Semashev via Boost wrote:
On 11/16/23 19:02, Matthijs Möhlmann via Boost wrote:
On 16/11/2023 16:50, Andrey Semashev via Boost wrote:
On 11/16/23 18:43, Matthijs Möhlmann via Boost wrote:
On 16/11/2023 16:32, Andrey Semashev via Boost wrote:
On 11/16/23 18:28, Andrey Semashev wrote:
As for a workaround, I suspect the problem can be worked around by manually adding linking with the standard library that defines those missing symbols. For example, `operator delete` is defined in libc++abi, so you may fix the problem by adding `linkflags=c++abi` to `b2` command line. Sorry, the command line option should be `linkflags=-lc++abi`.
That didn't work either. Same error. Do you mean the error still lists `operator delete` and similar core language symbols as unresolved?
If so then either the compiler is terminally broken, or there must be some issue with your installation. Perhaps, inconsistent libc++abi version?
BTW, we do test clang-16 in CI, and it passes:
https://github.com/boostorg/filesystem/actions/runs/6449121898
so I'm leaning towards some installation or configuration issue. Gotcha, when adding the flags as follows: linkflags="-lc++ -ldc++abi" it works correctly and I have every library build on my system. I'm assuming, you meant "-lc++abi" (note the missing "d").
Yes, I did it with "-lc++abi"
Then I guess it has to do with my library path. I have clang installed from the debian repository here:https://apt.llvm.org/ Yes, but note that there are different repositories for different Debian and Ubuntu versions, and also for different clang major releases. When you use those repositories, make sure you specify the correct versions in the repository line, and also specify the version in the package names. For example, for clang-16 you need to install clang-16, libc++-16-dev and libc++abi-16-dev - all come from apt.llvm.org.
I have an user-config.jam in the root of my home directory and it is as follows: import toolset : using ; using clang : 16 : clang-16 ;
option jobs : 8 ; Our user-config.jam should look like this:
using clang : : clang++-16 ;
Damn, this fixed the issue. Definitely user error then (me) :-(
See here for how it's composed:
https://github.com/boostorg/filesystem/blob/53eabaeabbf85fda2915a03612323df7...
Note that the compiler executable is clang++-16, not clang-16. The former is a C++ compiler, the latter is C. Presumably, the C compiler doesn't add C++ standard libraries to the linker. But I would also expect it to fail to compile C++ code, or at least display some warning, but maybe it doesn't.
Try changing to clang++-16 and compile without explicit `-lc++ -lc++abi` flags.
Maybe that interferes somehow with the ability to link to the correct library?
I am not sure where to look further to have this resolved. One last thing I'd like to note is that those `-lc++ -lc++abi` flags, if you specify those, should come last in the linker command line, and in that order. If you have multiple linker flags specified in the command line, make sure these two come after any other libraries or object files.
Thanks for the help! Regards, Matthijs
Matthijs Möhlmann via Boost <boost@lists.boost.org> writes:
On 16/11/2023 17:25, Andrey Semashev via Boost wrote:
Note that the compiler executable is clang++-16, not clang-16. The former is a C++ compiler, the latter is C. Presumably, the C compiler doesn't add C++ standard libraries to the linker. But I would also expect it to fail to compile C++ code, or at least display some warning, but maybe it doesn't.
Damn, this fixed the issue. Definitely user error then (me) :-(
This is a fairly common mistake that usually wastes a surprising amount of time (this thread of 16 emails is good illustration). On the other hand, it's not that hard for the build system to detect the mismatch. We do it in build2: $ b config.cxx=clang-16 warning: clang-16 looks like a C compiler info: should it be 'clang++' instead of 'clang'?
Andrey Semashev wrote:
Looks like it is, as the problem seems confined to Filesystem.
So far I don't see this as a Boost.Filesystem bug. The missing symbols (at least, those which were posted here earlier) are standard C++ symbols, which by default should be linked automatically by the compiler. If the compiler doesn't do that, this is a compiler bug as far as I'm concerned. So the right place to report it is:
https://github.com/llvm/llvm-project/issues/
Incidentally, I have reported a similar problem before here:
https://github.com/llvm/llvm-project/issues/60578
and it looks like it hasn't been fixed yet.
As for a workaround, I suspect the problem can be worked around by manually adding linking with the standard library that defines those missing symbols. For example, `operator delete` is defined in libc++abi, so you may fix the problem by adding `linkflags=c++abi` to `b2` command line.
But the problem only appears to affect Filesystem; the other libraries seem to link fine. There must be some difference that triggers it.
On 11/16/23 18:32, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
Looks like it is, as the problem seems confined to Filesystem.
So far I don't see this as a Boost.Filesystem bug. The missing symbols (at least, those which were posted here earlier) are standard C++ symbols, which by default should be linked automatically by the compiler. If the compiler doesn't do that, this is a compiler bug as far as I'm concerned. So the right place to report it is:
https://github.com/llvm/llvm-project/issues/
Incidentally, I have reported a similar problem before here:
https://github.com/llvm/llvm-project/issues/60578
and it looks like it hasn't been fixed yet.
As for a workaround, I suspect the problem can be worked around by manually adding linking with the standard library that defines those missing symbols. For example, `operator delete` is defined in libc++abi, so you may fix the problem by adding `linkflags=c++abi` to `b2` command line.
But the problem only appears to affect Filesystem; the other libraries seem to link fine. There must be some difference that triggers it.
I suspect, this is related to `-Wl,--no-undefined` that Boost.Filesystem adds.
Andrey Semashev wrote:
Incidentally, I have reported a similar problem before here:
https://github.com/llvm/llvm-project/issues/60578
and it looks like it hasn't been fixed yet.
As for a workaround, I suspect the problem can be worked around by manually adding linking with the standard library that defines those missing symbols. For example, `operator delete` is defined in libc++abi, so you may fix the problem by adding `linkflags=c++abi` to `b2` command line.
Maybe we need to change b2 to automatically add -lc++abi in addition to -stdlib=libc++ when stdlib=libc++ is used? (Assuming that this is the issue we're hitting.)
participants (11)
-
Andrey Semashev -
Boris Kolpackov -
Dennis Luehring -
Marcel Raad -
Marshall Clow -
Matt Borland -
Matthijs Möhlmann -
Peter Dimov -
Ruben Perez -
Tom Kent -
Vinnie Falco