clang fails to compile with boost::rational

The following code

#include <boost/rational.hpp>
#include <iostream>

int main() {
    auto r = boost::rational<int>{3,2};
    std::cout << r << "\n";
}

Compiles fine with the following g++ -std=gnu++2b -o try try.cpp and outputs 3/2 as expected. However with clang I get this

In file included from try.cpp:1:
In file included from /usr/include/boost/rational.hpp:69:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.1.1/../../../../include/c++/13.1.1/iomanip:42:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.1.1/../../../../include/c++/13.1.1/bits/ios_base.h:41:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.1.1/../../../../include/c++/13.1.1/bits/locale_classes.h:40:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.1.1/../../../../include/c++/13.1.1/string:48:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.1.1/../../../../include/c++/13.1.1/bits/stl_iterator.h:2618:35: error: missing 'typename' prior to dependent type name 'iterator_traits<_It>::iterator_category'
      { using iterator_category = iterator_traits<_It>::iterator_category; };
                                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated

This is with clang version 15.0.7 and gcc version 13.1.1. I see from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100900 that similar issues were reported a couple of years ago but are fixed now. What am I doing wrong?

Edit: Boost libraries are 1.81.0-6 installed in Arch linux.

Update to Clang 16. Cppreference says that "Make typename more optional" from C++20 was implemented in Clang 16, and libstdc++ 13 seems to rely on it.

That bug fix you link to was fixed by changing libstdc++ so that it works with the clang compiler, because clang seemed to require the optional typename in the using declaration.

It did not fix clang itself so, if another library (or any piece of valid code) also leaves off the typename, clang will still complain.

A bug raised on clang is what's needed here (unless there's already a later release that fixes it, of course⁽¹⁾). This will solve all possible occurrences of this issue rather than having to patch multiple (perfectly valid) bits of code to work around a clang deficiency.

⁽¹⁾ Before raising a bug, you should try clang 16 to see if it's still an issue. Although the release notes seem to indicate fixes for only using enum, there may have been unannounced work done there as well.