[libcxx] Re-include <osreldate.h> in __config for FreeBSD

[DimitryAndric]

In 0a97720 some changes were made to __config for assuming that __BYTE_ORDER__ is always present.

However, this deleted a <osreldate.h> include for FreeBSD, which is required to get the value of __FreeBSD_version, and that is used later in the file to determine whether _LIBCPP_C_HAS_NO_GETS needs to be enabled.

Include <osreldate.h> just after the other includes used for feature detection, to fix this.

Note that when FreeBSD 13 is EOLed, this can be removed, as then all supported FreeBSD versions will no longer have gets().

[llvmbot]

@llvm/pr-subscribers-libcxx

Author: Dimitry Andric (DimitryAndric)

Changes

In 0a97720 some changes were made to __config for assuming that __BYTE_ORDER__ is always present.

However, this deleted a <osreldate.h> include for FreeBSD, which is required to get the value of __FreeBSD_version, and that is used later in the file to determine whether _LIBCPP_C_HAS_NO_GETS needs to be enabled.

Include <osreldate.h> just after the other includes used for feature detection, to fix this.

Note that when FreeBSD 13 is EOLed, this can be removed, as then all supported FreeBSD versions will no longer have gets().

---

Full diff: https://github.com/llvm/llvm-project/pull/77242.diff

1 Files Affected:

• (modified) libcxx/include/__config (+4)

diff --git a/libcxx/include/__config b/libcxx/include/__config
index 082c73e672c749..359f4141146d62 100644
--- a/libcxx/include/__config
+++ b/libcxx/include/__config
@@ -484,6 +484,10 @@ _LIBCPP_HARDENING_MODE_DEBUG
 #    include <features.h> // for __NATIVE_ASCII_F
 #  endif
 
+#  ifdef __FreeBSD__
+#    include <osreldate.h> // for __FreeBSD_version
+#  endif
+
 #  ifndef __BYTE_ORDER__
 #    error                                                                                                             \
         "Your compiler doesn't seem to define __BYTE_ORDER__, which is required by libc++ to know the endianness of your target platform"

[mordante]

Thanks! LGTM!

[philnik777]

How long is it until FreeBSD 13 is EOL? If it's still a while, I'd really like to see a test for this.

[emaste]

How long is it until FreeBSD 13 is EOL? If it's still a while, I'd really like to see a test for this.

FreeBSD 13 is supported until at least Jan 31 2026 so it is a while, yes.

[ldionne]

Actually, _LIBCPP_C_HAS_NO_GETS shouldn't be necessary anymore, since its only usage is in:

#if _LIBCPP_STD_VER <= 11 && !defined(_LIBCPP_C_HAS_NO_GETS)
using ::gets _LIBCPP_USING_IF_EXISTS;
#endif

Since ::gets is marked as _LIBCPP_USING_IF_EXISTS, it should be possible to replace this by

#if _LIBCPP_STD_VER <= 11
using ::gets _LIBCPP_USING_IF_EXISTS;
#endif

What issue were you seeing on FreeBSD that prompted this change?

[DimitryAndric]

What issue were you seeing on FreeBSD that prompted this change?

I was building a bunch of FreeBSD ports against llvm-18 (including libcxx-18), and for example openjdk11 failed with:

In file included from /wrkdirs/usr/ports/java/openjdk11/work/jdk11u-jdk-11.0.21-9-1/src/hotspot/share/adlc/adlparse.cpp:27:
In file included from /wrkdirs/usr/ports/java/openjdk11/work/jdk11u-jdk-11.0.21-9-1/src/hotspot/share/adlc/adlc.hpp:33:
In file included from /usr/include/c++/v1/iostream:43:
In file included from /usr/include/c++/v1/ios:223:
In file included from /usr/include/c++/v1/__locale:23:
In file included from /usr/include/c++/v1/string:600:
In file included from /usr/include/c++/v1/__string/char_traits.h:26:
/usr/include/c++/v1/cstdio:163:9: error: no member named 'gets' in the global namespace
using ::gets _LIBCPP_USING_IF_EXISTS;
      ~~^
1 error generated.
gmake[4]: *** [gensrc/GensrcAdlc.gmk:73: /wrkdirs/usr/ports/java/openjdk11/work/jdk11u-jdk-11.0.21-9-1/build/bsd-x86_64-normal-server-release/hotspot/variant-server/tools/adlc/objs/adlparse.o] Error 1

While investigating I found that _LIBCPP_C_HAS_NO_GETS wasn't being defined anymore, so it still encountered this declaration, and failed on it.

Now that you have remarked this, I think I will look into it a bit more, since I never fully understood the "using_if_exists" stuff. As far as I remember, it never worked for us, in that the header will still produce an error if the _LIBCPP_C_HAS_NO_GETS check is removed.

[DimitryAndric]

Ah I think I know what happened there, for various reasons the openjdk11 port gets compiled with llvm12, which doesn't support the __using_if_exists__ attribute yet. I am aware that it is an unsupported configuration, but still I would like to at least put back the osreldate.h include, as it was there in the past, and was accidentally deleted.

An alternative would be to remove the whole _LIBCPP_C_HAS_NO_GETS stuff, and then we would have to carry a local patch to work around this problem. But I would prefer not to have to do so, at least until it is no longer necessary.

[ldionne]

Is it not an option to instead compile openjdk11 with a supported version of Clang? Or, alternatively, you could compile openjdk11 with Clang 12, but also with libc++ 12 which would be a supported configuration. The current situation of using Clang 12 with libc++ 17 is actually prone to a lot more issues than this [[using_if_exists]] attribute lacking, I would expect a bunch more stuff to start failing in the future and I am a bit surprised you haven't run into other issues yet.

Because this is generally a non-supported configuration and this issue is likely just the tip of the iceberg, I would rather not move forward with this patch and instead remove _LIBCPP_C_HAS_NO_GETS.

[DimitryAndric]

Is it not an option to instead compile openjdk11 with a supported version of Clang?

For various reasons, it is not. (There is a long history there, but suffice to say that openjdk11 code is also pretty old by now, and contains constructs that don't fare well with more recent versions of clang.)

Or, alternatively, you could compile openjdk11 with Clang 12, but also with libc++ 12 which would be a supported configuration.

Unfortunately that is something we haven't yet implemented. At least, nobody stepped up to make that work with the FreeBSD ports system, although various attempts have been made. They always end up failing due to the many tricky details that have to be worked out.

A similar situation exists with the various gcc ports available in the ports system, where if I recall correctly, gcc 4.8 only very recently got dropped (as some older software or architecture still required it). All these gcc ports come with their own copy of libstdc++, and there is no end to trouble when applications mix different versions of libstdc++.so, and even sometimes attempt to mix libc++ and libstdc++...

The current situation of using Clang 12 with libc++ 17 is actually prone to a lot more issues than this [[using_if_exists]] attribute lacking, I would expect a bunch more stuff to start failing in the future and I am a bit surprised you haven't run into other issues yet.

I have applied a few local workarounds, and most things seem to work fine. Though I recognize that this will become a bigger problem in the future. For now I will kick the can down the road.

Because this is generally a non-supported configuration and this issue is likely just the tip of the iceberg, I would rather not move forward with this patch and instead remove _LIBCPP_C_HAS_NO_GETS.

That's also fine, and we'll probably carry a local patch to work around this.