Ah, they joys of C! #ibus (the input method I use) may have a working, or completely broken, emoji picker, depeding on what order the compiler decides to initialise things, and what things it optimises away.
(also, maybe GLib's type registration system is too complicated to use correctly?)
(issue with details, patch)
OTOH, I love that I could fix it on my machine by just dropping the patch under /etc/portage/patches/app-i18n/ibus-1.5.27/ and rebuilding the package :genchu: #gentoo#linux
It turns out that #urllib3 added a totally bonkers OpenSSL version check, and they broke a lot of systems as a result. Ofc the immediate result is dozens of packages pinning urllib3 < 2, and if they continue their negligence it's going to go into hundreds.
Ofc, it is a mess that distro maintainers will have to clean up eventually. I mean, removing the pins when they do not apply to us.
Xenia Linux is a new Linux distribution based on Gentoo, that provides an immutable rootFS and a dynamic filesystem with LVM, also shipping with Distrobox to allow users to use the CLI of the distro they are most comfortable with.
We are currently on v0.2, with new improvements and features on the way!
If #Gentoo development were a game, it would be that kind of game that never ends, always demands you go and finish the next level for some symbolic reward, and expects you to spend a significant time playing every day or otherwise everything starts falling apart and you're going to need to spend three times more time getting back on track.
There are many games like that. The people who own them make a lot of money. If developers are playing, who's making the money?
Historically, when building a modern C++ program using clang, the flag "stdlib=libc++" must be supplied to clang, otherwise the ancient libstdc++ on the system would be used. On the other hand, for (an manually updated) GCC, no flag is needed, so GCC's libstdc++ is used by default, In fact, "stdlib=libc++" cannot be recognized by GCC and should never be used with GCC.
As a result, many build scripts and build systems on macOS check if the flag "stdlib=libc++" is supported. If it's the case, the flag is used. If it's not, no flag is added. Practically, it means If the program is built with clang, it's linked to clang's libc++. If the program is built with GCC, it's linked to GCC's native libstdc++, a reasonable behavior, as expected by most users.
But now it was realized that using GCC and clang on the same system may create tricky conflicts, it's useful to be able to link against clang's libc++ even if GCC is used (this is useful beyond Darwin, e.g. for FreeBSD). So GCC now supports "stdlib=libc++ as well.
If "stdlib" support is enabled on GCC, if program is built by GCC, whether it will be linked to libstdc++ or libc++ by default becomes unpredictable, depending on which check is used in its build system. :woozy_baa:
I started to review the blog post requests, drafts, and ideas accumulated over time. Most topics revolve around #rex, #perl, #opensource, #gentoo, #cicd, #git, #testing, and #CLI — with some overlap.
Help me decide: which topic shall I focus on first?
More #Gentoo porting to Apple Silicon... Running ar(1) from binutils-apple on new macOS without arguments will immediately crash it with Segmentation Fault. The culprit: strcmp() is used to check argv[1], even when it's clear that they can definitely be OOB reads - "comparing a string with garbage is harmless, who cares..." On the new system, argv[1] is NULL and generates EXC_BAD_ACCESS.
It is YEARS since I used noweb, but maybe I could use it again, say for ports to other languages than C of program06 (my program that VIOLATES BELL INEQUALITIES despite having nothing resembling the non-existent ‘entanglement’).
#Vale describes itself as a “syntax-aware #linter for prose built with speed and extensibility in mind”. My overlay has the latest v2.24.4 release available for fellow #Gentoo users.
Unfortunately mixing clang and GCC on macOS creates some weird linking issues that I can't solve, but GCC must be used. The only workaround I'm seeing now is starting from a clean GNU userland. So now I'm now bootstrapping Gentoo prefix on Apple M1... :woozy_baa: Wish me luck. It's a rented server, this Gentoo install is burning the CPU and my wallet at the same time... :woozy_baa:
Two months later, I'm finally able to run openEMS with GCC and Python on Apple Silicon now - the original motivation of porting #Gentoo. I'm glad to see that my decision eventually worked as expected, instead of becoming just yet another useless project and distraction. :blobcat_hug_genchu:
Using the notoriously memory-bound FDTD electromagnetic code, time to run it on a M1 Ultra machine and see whether its massive memory bandwidth really works as advertised...