C extensions, portability, and alternative compilers • Hacker News Board

Re: C extensions, portability, and alternative compilers

#61

Post by avadodin » Tue, May 26, 2026, 8:38 AM UTC

whizzter wrote: post #10

formerly_proven wrote: post #3

Earlier quoted context omitted.

For a bunch of software categories there isn't really much point to support Windows at all these days. We've had "developed for unix, ported to Windows" software for a long time and it often doesn't work that well, because the agreement even for fairly basic stuff is not that large between the two.

1: My point isn't "developer on unix, ported to Windows", it's "developed on linux, maybe works elsewhere". 2: You could easily compile Samba yourself for FreeBSD in the past, last time I tried a new version it broke in what I remember being due to linux-isms (yes there is ports, but being reliant on older versions if ports maintainers can't keep up isn't a good thing). 3: The only "fairly basic" stuff that's hugely…

The decent cross-compatibility in the early 00s was a result of the multipolarity of the era.

In the late 90s-early 00s we had SystemV, Linux, BSD, macOS and the market begged for standards like POSIX and to an extent CDE and many other proposed ones. As the largest player, Linux always had an attitude.

Now, after winning the Server, embracing, extending and extinguishing the Workstation/Desktop(WSL, Valve), and with a foothold in mobile(Android) Linux is the de-facto standard.

The BSDs have declared POSIX dead and gone their own way while supporting Linux(SystemD, Wayland) APIs even if they are more half-baked than POSIX in order to benefit from what is now virtually a Linux ecosystem.

I don't like this any more than you but it is what it is.

Re: C extensions, portability, and alternative compilers

#62

Post by avadodin » Tue, May 26, 2026, 8:49 AM UTC

matheusmoreira wrote: post #53

einpoklum wrote: post #25

Earlier quoted context omitted.

systemd is indeed the bane of Linux, and a pain in the ass for a lot of FOSS. Once the main distributions made it mandatory to install (not just the default, but mandatory) - we've started to see this sort of bifrucation of a lot more FOSS away from being standard-based and multi-platform to being Linux-specific. That said - I think a rule-of-thumb one can follow is that any inclusion of a file with a directory prefi…

Nope. Systemd is pretty great. It's pretty well designed, fully featured, very easy to use and quite nice program against. And it's GPL licensed free software. Systemd bothers people because it's not "the Unix way". In other words, it's not some painful lowest common denominator POSIX nonsense. That's a feature, not a bug. POSIX is garbage and restricting oneself to it is pure masochism. Every unixlike deviates from…

Your binary spaghetti monstrosity, our carefully designed literate API.

Wait.

Re: C extensions, portability, and alternative compilers

#63

Post by anthk » Tue, May 26, 2026, 9:04 AM UTC

jeltz wrote: post #41

einpoklum wrote: post #25

Earlier quoted context omitted.

systemd is indeed the bane of Linux, and a pain in the ass for a lot of FOSS. Once the main distributions made it mandatory to install (not just the default, but mandatory) - we've started to see this sort of bifrucation of a lot more FOSS away from being standard-based and multi-platform to being Linux-specific. That said - I think a rule-of-thumb one can follow is that any inclusion of a file with a directory prefi…

No, systemd is not the bane of Linux. What existed before it was much worse. Upstart was a totally broken mess and almost all sysv init scripts contained several bugs. I don't like systemd but it is a lesser evil.

Upstart? These Ubuntu-centric kids will never learn. OpenRC works fine there.

Meanwhile people still have issues on turning off their machines.

Re: C extensions, portability, and alternative compilers

#64

Post by account42 » Tue, May 26, 2026, 10:03 AM UTC

zephen wrote: post #4

formerly_proven wrote: post #3

Earlier quoted context omitted.

For a bunch of software categories there isn't really much point to support Windows at all these days. We've had "developed for unix, ported to Windows" software for a long time and it often doesn't work that well, because the agreement even for fairly basic stuff is not that large between the two.

There's portability between systems, which as you note, has ever-diminishing returns. Then there's portability between compilers, which, as the article notes, glibc is also completely hostile to (except for anointed compilers) for no good reason whatsoever.

> which, as the article notes, glibc is also completely hostile to

This is neither true nor claimed by the article.

Re: C extensions, portability, and alternative compilers

#65

Post by account42 » Tue, May 26, 2026, 10:04 AM UTC

rurban wrote: post #36

dooglius wrote: post #12

Earlier quoted context omitted.

The preceding comment indicates that the intent is to support other compilers. I think a better approach is to define __glibc_attribute__ based on compiler support and to stick to that within glibc since there's no reason to think that another compiler's attributes have the same semantics as GNU C's.

That ship sailed already. You simply have to mimic gcc. Which is at least better than with MSVC, where they did everything differently, and only half of it.

Well in practice you have to mimic GCC except for Windows where you have to mimic MSVC.

Re: C extensions, portability, and alternative compilers

#66

Post by account42 » Tue, May 26, 2026, 10:08 AM UTC

matheusmoreira wrote: post #53

einpoklum wrote: post #25

Earlier quoted context omitted.

systemd is indeed the bane of Linux, and a pain in the ass for a lot of FOSS. Once the main distributions made it mandatory to install (not just the default, but mandatory) - we've started to see this sort of bifrucation of a lot more FOSS away from being standard-based and multi-platform to being Linux-specific. That said - I think a rule-of-thumb one can follow is that any inclusion of a file with a directory prefi…

Nope. Systemd is pretty great. It's pretty well designed, fully featured, very easy to use and quite nice program against. And it's GPL licensed free software. Systemd bothers people because it's not "the Unix way". In other words, it's not some painful lowest common denominator POSIX nonsense. That's a feature, not a bug. POSIX is garbage and restricting oneself to it is pure masochism. Every unixlike deviates from…

The definition of a strawman.

Re: C extensions, portability, and alternative compilers

#67

Post by whizzter » Tue, May 26, 2026, 10:09 AM UTC

matheusmoreira wrote: post #29

whizzter wrote: post #2

One of my pet-peeves with C projects is that it's so often more or less "works on my machine" when written by Linux users (as a Windows and FreeBSD user it often hits you on both those platforms). The article highlights a typical piece: #if !(defined __GNUC__ || defined __clang__ || defined __TINYC__) # define __attribute__(xyz) /* Ignore */ #endif There is no reason that !defined check to not include a check for __a…

> One of my pet-peeves with C projects is that it's so often more or less "works on my machine" when written by Linux users (as a Windows and FreeBSD user it often hits you on both those platforms). Windows users singling out Linux users for not catering to their platform. How the times change... > you often run into systemd dependencies or other non-posix behaviors Not a problem. POSIX is irrelevant, systemd is grea…

> Windows users singling out Linux users for not catering to their platform. How the times change...

This goes back to the days I was browsing freshmeat and saw some interesting command line tool or otherwise non-UI tool from some hopeful developer for something useful. Node had significant traction but didn't really blow up until it became really cross-platform.

And perhaps is less of an issue these days since so many people use Mac's as their primary, so less Linux-isms survive once in context with osX.

> Not a problem. POSIX is irrelevant, systemd is great and we should all be using Linux to its fullest extent. Linux has great features and there is absolutely no reason not to use them all. Nobody complains about the fact BSDs have cool things like kqueue and unveil.

From following it over the year it was not entirely welcomed even in the linux community (and some of the security issues made one shudder). Mostly it's the monolithic nature that's makes it a questionable, is it Gnu/Linux these days or Systemd/Linux ?

kqueue is just an api, just like epoll, io_uring or even iocp on windows. And yes, it's a special case for high-perf servers where posix becomes less relevant (and while I can appreciate some lower-perf fallback to be able to develop/port to another platform like a console I do see that some programs are inherently platform bound).

I think one thing lost in my original comment was that I was often encountering things like this with "simple" CLI tools or lower level format libraries, and honestly projects like that also had a tendency to break over time without updates as they often relied on specific versions of libraries the maintainers had installed via Linux package managers, in the same fashion as npm has caused churn in the JS community. (npm at least has version pinning so old cli tools can often be run as long as node hasn't deprecated api's).

Re: C extensions, portability, and alternative compilers

#68

Post by defrost » Tue, May 26, 2026, 10:12 AM UTC

account42 wrote: post #66

matheusmoreira wrote: post #53

Earlier quoted context omitted.

Nope. Systemd is pretty great. It's pretty well designed, fully featured, very easy to use and quite nice program against. And it's GPL licensed free software. Systemd bothers people because it's not "the Unix way". In other words, it's not some painful lowest common denominator POSIX nonsense. That's a feature, not a bug. POSIX is garbage and restricting oneself to it is pure masochism. Every unixlike deviates from…

The definition of a strawman.

It's like flogging a straw herring in the foot.

Re: C extensions, portability, and alternative compilers

#69

Post by whizzter » Tue, May 26, 2026, 10:16 AM UTC

BadBadJellyBean wrote: post #9

whizzter wrote: post #2

One of my pet-peeves with C projects is that it's so often more or less "works on my machine" when written by Linux users (as a Windows and FreeBSD user it often hits you on both those platforms). The article highlights a typical piece: #if !(defined __GNUC__ || defined __clang__ || defined __TINYC__) # define __attribute__(xyz) /* Ignore */ #endif There is no reason that !defined check to not include a check for __a…

If it is an open source project then that is quite alright with me. An open source author doesn't need to support all platforms. Only those they care about. If someone else wants support for another platform they have the source.

Yeah, I think I did miss mentioning that my comment was more weighted on simpler cli tools or library projects (file format readers,etc).

I don't expect anyone writing GUI tools or more high-perf servers to spend their time porting to other platforms (trying to compile GTK on Windows wasn't for the faint of heart).

Re: C extensions, portability, and alternative compilers

#70

Post by account42 » Tue, May 26, 2026, 10:16 AM UTC

fc417fc802 wrote: post #43

ventana wrote: post #24

Earlier quoted context omitted.

I have no knowledge of this specific "why", but my general experience shows that feature flags, while almost universally better than checks for the specific software version in hope that it has proper support for a feature, appear only as a replacement to platform / software detection, after a few years of struggle. It's probably just natural for software developers (myself included), whenever only FooZoid v5 support…

The ideal isn't feature flags (ie FOO_SUPPORTED) but rather feature tests (ie COMPILES( foo( int ) ) ). Yet another reason why languages with proper metaprogramming capabilities are better.

The problem is that COMPILES( foo( int ) ) is not the same as DOES_WHAT_I_WANT_IT_TO( foo( int ) ).