Elektrine
Log in Register

#illumos

9 posts · Last used 3d

Back to Timeline
@jperkin@federate.me.uk · 4d ago
If you've ever built a non-trivial amount of software on Solaris / illumos you've almost certainly hit math function errors like this: error: call of overloaded 'log(int)' is ambiguous I got fed up of adding patches to pkgsrc, and I believe I have a patch that fixes this once and for all. https://www.illumos.org/issues/15209#note-4 I'd appreciate wider testing. I've already tested it in a full ~28,000 package bulk build, but changes like this terrify me, and you can't be too careful. #solaris #illumos #pkgsrc
6
0
3
In reply to
@JdeBP@mastodonapp.uk · 4d ago
@jperkin@federate.me.uk I'm not sure that this is the best fix. Since C++2011, there's been a template for std::log in 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 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
0
0
0
In reply to
@JdeBP@mastodonapp.uk · 3d ago
@jperkin@federate.me.uk 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 and 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 functions. #CPlusPlus #gcc #clang
0
0
0
In reply to
@JdeBP@mastodonapp.uk · 3d ago
@jperkin@federate.me.uk 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 inline typename __illumos::__enable_if<__illumos::__is_integral<_T>::__value, double>::__type log(_T __v) { return log(static_cast(__v)); } inside namespace std, and #include 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
0
0
0
In reply to
@JdeBP@mastodonapp.uk · 3d ago
@jperkin@federate.me.uk 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
0
0
0
In reply to
@JdeBP@mastodonapp.uk · 3d ago
@jperkin@federate.me.uk 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
0
0
0
In reply to
@JdeBP__dup_33984@mastodonapp.uk · Feb 11, 2026
On #Illumos, Jov vi is in /usr/src/cmd/vi: https://github.com/illumos/illumos-gate/tree/master/usr/src/cmd/vi On #OpenBSD, Bostic #nvi is in /usr/src/usr.bin/vi/vi; #NetBSD having it in /usr/src/external/bsd/nvi; and #FreeBSD in /usr/src/contrib/nvi: https://github.com/freebsd/freebsd-src/tree/main/contrib/nvi FreeBSD has an nvi2 in ports: https://freshports.org/editors/nvi2/ OpenBSD has elvis in ports: https://github.com/openbsd/ports/blob/master/editors/elvis/pkg/DESCR Ritter's Heirloom vi is on SourceForge: https://ex-vi.sourceforge.net STEVIE was posted to comp.sources.unix in 1988: https://sources.vsta.org/comp.sources.unix/volume15/stevie/ Unfortunately, Sven Guckes's vi Clones WWW site was never completed with some of this, notably lacking Heirloom vi, for example. https://guckes.net/vi/clones.html But it does mention oft-overlooked commercial clones such as Watcom's vi, a from-scratch implementation started in 1983 that is also now source-available: https://github.com/open-watcom/owp4v1copy/tree/master/bld/vi #vi #retrocomputing #ComputerHistory #STEVIE #elvis #VIM #NeoVIM #Watcom #OpenWatcom
4
0
2
@JdeBP__dup_33984@mastodonapp.uk · Feb 11, 2026
People waxing lyrical about using 'original vi', both nowadays in 2026 and back in 2006, haven't a clue what that is. There's only one family of operating systems where 'vi' will actually run the original vi program by Joy, Horton, et al.: #Illumos and its derivatives #Tribblix, #OmniOS, and #SmartOS. *Everyone else* uses one of the ground-up clones. On #FreeBSD, #OpenBSD, and #NetBSD, it's Bostic's early 1990s #nvi, which was derived from Kirkendall's elvis, a clone written some time around 1990. On Linux-based operating systems, vi either is Bostic nvi, or is one of the derivatives of STEVIE (the middle-1980s vi clone for the Atari ST that inspired Kirkendall to write elvis in the first place): Moolenaar's VIM or NeoVIM. On none of those will you get original Joy+Horton vi in base, or indeed packaged/in ports. Yes, Heirloom vi exists, which is Ritter's 2002 fork of 1985 Joy+Horton vi. But it's not even available in Arch Linux nowadays. #vi #retrocomputing #ComputerHistory
11
6
5
Boosted by CM Harrington @octothorpe@mastodon.online
@stefano@mastodon.bsd.cafe · Jan 03, 2026
AI models don’t really 'get' the BSDs. As a result, they often provide incomplete, imprecise, or flat-out wrong answers by defaulting to Linux paradigms. When it comes to illumos-based systems, they just completely lose the plot. This is becoming a serious issue for the BSDs and illumos ecosystems. We are seeing entire websites flooded with AI-generated tutorials and guides that are totally incorrect. Most people don't realize this; they follow the instructions, fail, and then assume that the BSDs doesn't work well or are 'unstable' because they have supposedly changed since the guide was written. Luckily, some people eventually find my blog, reach out, and finally understand what's actually going on. Others, unfortunately, end up on major social sites or comments, claiming that these systems are broken. In 2026, one of our greatest challenges will be teaching people how to vet their sources and filter information. And I see this as a very, very uphill battle. #IT #SysAdmin #FreeBSD #NetBSD #OpenBSD #illumos #News #UnderstandingText #Disinformation
257
30
161

You've seen all posts