Created attachment 271391 [details] from_chars.cpp The attached from_chars.cpp program fails to compile: > $ c++ -std=c++23 from_chars.cpp > from_chars.cpp:13:20: error: call to deleted function 'from_chars' > 13 | auto [ptr, ec] = std::from_chars(str.data(), str.data() + str.size(), value); > | ^~~~~~~~~~~~~~~ > /usr/include/c++/v1/__charconv/from_chars_integral.h:38:19: note: candidate function has been explicitly deleted > 38 | from_chars_result from_chars(const char*, const char*, bool, int = 10) = delete; > | ^ > /usr/include/c++/v1/__charconv/from_chars_integral.h:224:1: note: candidate template ignored: requirement 'is_integral<float>::value' was not satisfied [with _Tp = float] > 224 | from_chars(const char* __first, const char* __last, _Tp& __value) { > | ^ > /usr/include/c++/v1/__charconv/from_chars_integral.h:230:1: note: candidate function template not viable: requires 4 arguments, but 3 were provided > 230 | from_chars(const char* __first, const char* __last, _Tp& __value, int __base) { > | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 1 error generated. despite the C++ standard saying that it should exist from c++17: https://en.cppreference.com/cpp/utility/from_chars
Why do you keep reporting upstream llvm issues as FreeBSD issues? The from_chars support is documented by llvm to be incomplete in all releases of llvm libc++ so far. (See later below.) As in multiple past reports by you for such contexts, if the partial implementation is sufficient for the context that you want it for, use: -fexperimental-library to enable the partial support. I do this in some software that I have that uses to_chars. You could have checked the below yourself instead of requiring others to do such for you. https://libcxx.llvm.org/Status/Cxx17.html reports: QUOTE P0067R5 Elementary string conversions, revision 5 2016-11 (Issaquah) Partial #99940 For integer types, std::(to|from)_chars has been available since v7; for float and double, std::to_chars since v14 and std::from_chars since v20. Support is complete except for long double. END QUOTE Also, because of the incomplete status, the feature test macro __cpp_lib_to_chars is still not defined by libc++ . (There is none that mentions from_chars separately: this one covers both.)
This has now been resolved since libc++ 21 landed in CURRENT, STABLE-15 and STABLE-14 (see bug 292067): $ uname -Kr 16.0-CURRENT 1600018 $ c++ from_chars.cpp -o from_chars $ ./from_chars 42.1234 Parsed value: 42.1234
Mark, I am not defending where or how yuri@ is reporting the issue there, but a practical problem we face with FreeBSD as it is now is: * we don't have libc++ as a separate package in ports, so people either need to hop onto the flying saucer that is -STABLE or -CURRENT, or wait for months or longer until that updates appear in a release - until then, we've got a C++ toolchain that's always behind what other projects seem to offer -- esp. in a ports context. We've been here before, where libc++ updates that would make our base libc++ compatible with GCC15 would never appear, which kept, say, rawtherapee on old compilers (it has to use libc++ as that's the default standard C++ library for ports) because our base libc++ is always behind. Our C++ toolchain is only useful for ports that support older C++ standards and/or that do not rely on other third-party C++ ports so they can hop onto GNU libstdc++, possibly using the GCC. Is this where we want FreeBSD to be?
(In reply to Matthias Andree from comment #3) It goes the other direction as well: updates to the system llvm* (including its libc++ version) are disallowed by the ports team until approved by the ports folks based on exp runs being sufficient. The system libc++ version and the overall ports tree status are not independent. Trying to satisfy whatever fraction of 36000+ port packages that involve use of C++ and its standard (hosted) library cannot enable all such port-packages. The major criteria is not about the subset of port-packages that use the most modern parts of C++ and its standard (hosted) library. I use main because of its earlier libc++ schedule. I'm familiar with various timing issues. That includes issues where the llvm upstream simply does not yet have parts of the implementation in place, going back to c++17 relative to the standard library. I've got code that uses to_chars for long double. I used -fexperimental-library for libc++ use. For libc++ it actually outputs for a conversion to just double in contexts where the two types are significantly distinct. (I can get by with such but it is not conformant behavior.) libstdc++ handles long double for such contexts.
There is no "ports" team, if you mean "portmgr", the current team also has a track record of leaving committers of major subsystems out in the rain without support and giving cover for obstructive behavior, so let's please separate the technical matter from the acting people, and here goes: I agree that there needs to be sufficient coordination between the ports system and the base system, so that a new FreeBSD base system release does not just break hundreds of ports, but I observe that the practical outcome is that we are currently tying FreeBSD's entire C++ support to the oldest base system libc++ across all supported FreeBSD releases, which is 14.3 for now, and will then be 14.4 or 15.0 next month - and *THAT* is the basis for ports. Requiring the base system to be the tip of -STABLE, or -CURRENT, doesn't work for ports. Might be this shouldn't be fixed solely by freebsd-toolchain@ but instead by portmgr@ or core@, and the fix COULD be that we: 1 - TBD: make the libc++ parts in the base system private, so it's only used by the C++-based components of the base system, but not ports 2 - add a libc++ port that is up to date and can be updated independently of the base system 3 - add a FLAVOR to all C++ library ports that expose C++ linkage interfaces (as opposed to C linkage) that relies on the "ports libc++", These items are probably only for the ports@ matter: 4 - add a FLAVOR similar to #2 but that instead exposes the current "default ports GCC version" 5 - maybe add other FLAVOR variants (Tier 2 as in "no promises" or "no obligation for contributors") for other C++ ABIs. Note that the C++ approach is very different to the one seen by Go or Rust - the latter ones aren't tied to base system versions, and can move much quicker.
I should have added that libstdc++ and libc++ are incompatible, ABI-wise. This is obvious to only some of us discussing here. You can't link, directly or indirectly, libstdc++ and libc++ into the same executable or shared object ("shared library"). If some typical library port (from ports) exposes C++ ABI, say, SomeRequisiteXX or SomeRequisite++, is compiled and linked against libc++'s ABI, as I think all such libraries are (they would use the system's base compiler), you can't use that library in a project that wants to use libstdc++. While you *can* tell GCC-based ports to also use libc++, things fall asunder if they revolve around GCC's builtins that are sometimes incompatible with our base system's libc++. Hence my suggestions #1, #3, #4 in the previous comment to isolate matters from one another.
(In reply to Matthias Andree from comment #3) For reference (I was curious): The system llvm21 exp-run for main was requested on: 2025-12-31 The exp-run for main was declared closed FIXED on: 2026-04-25 (So main was updated.) So: About 4 months. Updates to the likes of stable/15 and stable/14 do not happen immediately: live operation of main is part of the testing before any stable/* are updated. The updates to stable/1[54] to use llvm21 were made on: 2026-05-29 So exp-run request to stable/* : About 5 months. (As an example.) Then there are the times to each "next releng/*.*" release. Note: I've no clue what lead to skipping llvm20 and, so, the longer time for llvm19 to be in place before the first system llvm upgrade exp-run that would be applied. So I've nothing to report about that.
(In reply to Matthias Andree from comment #5) https://www.freebsd.org/portmgr/ is titled "Ports Management Team" so I dropped a word. Sorry. Making "libc++ parts in the base system private" first would break all llvm based c++ ports. It would appear that the ports tree would first have to support an alternative, then the system libc++ could be made private and the alternative be made the default. So such a process looks to start with the ports tree and only later progress to the system. Are you expecting the port-package builders would make all those flavors you are referencing? Or would all but one flavor be just for more local port-package building? It would seem to me that multiplying the port-package build counts for the official builders would be a non-starter given the build times and such. I'll note that the system libgcc_s and the like are not equivalent to any version of the lang/gcc* ones. In various contexts, -WL,--rpath=... (or analogous) must be used to reference the gcc*'s libraries when a lang/gcc* is used. This is not necessarily limited to when C++ or its standard (hosted) library is involved. Overall: looks to me like a major project with insufficient volunteer support for it to happen.