@jperkin

You've missed two important bits.

Your initial approach didn't test for _LIBCPP_VERSION or __GLIBCXX__. Your initial approach rather compiled all of this out except for one specific compiler.

What I just described, in contrast, compiles everything in for all compilers except when libstdc++ or libc++ are used. It's library-sensitive, not compiler-sensitive.

Because there's a stage at least in the GCC bootstrap where it is building itself with the pre-supplied compiler and library. In this mode, one does *not* want the #Illumos headers to have their C++ parts conditionally compiled out. One rather wants them to be fully natively functional the same as they are now.

I also said *only* the extern "C++" {} block. Your initial approach went far beyond that and compiled out the declarations of a whole bunch of "C" linkage stuff.

#CPlusPlus #gcc #clang

@jperkin

All that said, the big question to answer is whether there is still in use an #Illumos C++ compiler that does not use either GNU libstdc++ or LLVM libc++. (Likely yes if a compiler bootstrap uses C++ before it has its own library built.)

Because the inlined "C++" linkage stuff declared by the Illumos library has a fallback to other inline functions if using libstdc++ or libc++, the very easiest patch of all would seem to be just conditionally compile out (only) the extern "C++" {} block of head/iso/math_iso.h when either _LIBCPP_VERSION or __GLIBCXX__ is defined.

That way, anything building with libstdc++ or libc++ doesn't get the Illumos "C++" linkage overloads as overloads in the global namespace, and only gets the 1 "C" linkage overload.

#CPlusPlus #gcc #clang

@jperkin

Retaining that uniform, clean, system involves adding the stuff that's needed for more modern C++ anyway into the right iso/math_iso.h header.

If I were doing that, head/iso/math_iso.h would gain something like

template<typename _T> inline typename __illumos::__enable_if<__illumos::__is_integral<_T>::__value, double>::__type log(_T __v) { return log(static_cast<double>(__v)); }

inside namespace std, and

#include <iso/type_traits.h>

at the top. There'd be an head/iso/type_traits.h with the well-known implementation of enable_if<> as __illumos::__enable_if<> and a suitable implementation of __illumos::__is_integral<> instantiated as appropriate.

#CPlusPlus #gcc #clang #Illumos

@jperkin

If I had an #Illumos system to do such work on, I probably could.

Your patch is breaking the uniform way that the library is designed, over a whole load of headers.

In this design, all of the overloads are declared inside namespace std in some iso/*_iso.h header, which headers like <math.h> and <stdio.h> and so forth then pull into the global namespace with using declarations. Ironically, it's a far more full-on C++ way of doing things because it's even declaring the C library functions in namespace std, but with "C" linkage.

namespace std gets 1 "C" linkage overload and 2 "C++" linkage overloads for the various <cmath> functions.

#CPlusPlus #gcc #clang

@jperkin

I'm not sure that this is the best fix.

Since C++2011, there's been a template for std::log in <cmath> that takes an integral type argument and so is the best match without ambiguity.

https://cplusplus.com/reference/cmath/log/

vide libstdc++

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/c_global/cmath;hb=HEAD#l322

and libc++

https://github.com/llvm/llvm-project/blob/main/libcxx/include/__math/logarithms.h#L35

Illumos's C++ support in <math.h> isn't up to date with respect to C++ 2011 (unsurprisingly) and a fix that would actually improve and modernize the C++ support seems to be to add these templates for log and whatnot, in some fashion, with appropriate C++ version and type guards, to head/iso/math_iso.h where all of the other C++1998 overloads already are.

That would remove ambiguity for both log(1) and std::log(1).

#CPlusPlus #Illumos #gcc #clang

This is super #cursed. How is this even possible.

I'm legitimately asking, I have no idea how this could result in a program that links but doesn't run.

#programming #clang #retrocomputing

Alt...

A screenshot of an X terminal. The terminal has the following contents: hp@lilly:~/Projects/motif/cursed$ gcc hello.c -o hello -lXt -lXm -g3 hp@lilly:~/Projects/motif/cursed$ ./hello XtToolkitInitialize() XtCreateApplicationContext XtOpenDisplay() XtVaAppCreateShell() X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 19 (X_DeleteProperty) Resource id in failed request: 0x0 Serial number of failed request: 119 Current serial number in output stream: 123 hp@lilly:~/Projects/motif/cursed$ gcc hello.c -o hello -lXm -lXt -g3 hp@lilly:~/Projects/motif/cursed$ ./hello XtToolkitInitialize() XtCreateApplicationContext XtOpenDisplay() XtVaAppCreateShell() XtVaCreateManagedWidget() Success! entering main loop hp@lilly:~/Projects/motif/cursed$

A new #blog post appears!

I built a native GCC 14.2.0 for Mac OS X 10.4 Tiger PowerPC.

https://briancallahan.net/blog/20250329.html

#macos #macosx #tiger #powerpc #power #unix #bsd #freebsd #openbsd #netbsd #dragonflybsd #linux #solaris #illumos #gcc #llvm #clang #compiler #compilers #assembler #linker #toolchain #freesoftware #opensource #gnu