Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What the hell is a target triple?

mcyoung.xyz

Post reply on HN
Print view View original

131–139 of 139 posts

Re: What the hell is a target triple?

#131

Post by SAI_Peregrinus »

forrestthewoods wrote: post #20

What a great article. Everytime I deal with target triples I get confused and have to refresh my memory. This article makes me feel better in knowing that target triples are an unmitigated cluster fuck of cruft and bad design. > Go does the correct thing and distributes a cross compiler. Yes but also no. AFAIK Zig is the only toolchain to provide native cross compiling out of the box without bullshit. Missing from th…

I'd say it's less bad design, & more a near-total lack of design. Someone needed a "good enough" way to specify target properties for a few targets they had to support, and picked a string format they could easily parse. Worked fine. Then more systems had to be added, and special cases happened, and nobody wanted to break backwards-compatibility so the system just grew. And nobody can agree on names, so people added alias support, and the system grew. And people started releasing OSes instead of just organizations so the "vendor" concept grew fuzzy, and the system grew. Now it is a hyphen-separated variable-length monster of confusion.

Ideally each component in the target "triple" would be a separate argument.

Re: What the hell is a target triple?

#132

Post by matheusmoreira »

o11c wrote: post #128
fc417fc802 wrote: post #123

Earlier quoted context omitted.

Just connect to the service running on localhost ... I'm curious. Why isn't getaddrinfo implemented in a similar manner to the loaders that graphics APIs use? Shouldn't that functionality be the responsibility of whatever resolver has been installed?

That is how `getaddrinfo` works under GLIBC; it's called NSS. The problem (well, one of them) is the non-GLIBC implementations that say "we don't need no stinkin' loader!"

The problem is people delete glibc and are surprised when glibc features are missing.

The only point I'm making is: Linux does not require glibc.

Users and their programs usually do require glibc but that's their choice. It's not mandated. People could theoretically rewrite the entire Linux user space in pure freestanding Rust if they wanted to.

Name Service Switch is just a solution to a problem. There's no law that says Linux systems must have that system. Programs that depend on it will break if it's not there but that's not the fault of Linux.

Re: What the hell is a target triple?

#133

Post by matheusmoreira »

lonjil wrote: post #102
matheusmoreira wrote: post #34

> Go originally wanted to not have to link any system libraries, something that does not actually work It does work on Linux, the only kernel that promises a stable binary interface to user space. https://www.matheusmoreira.com/articles/linux-system-calls

FreeBSD does as well, but old ABI versions aren't kept forever.

People have told me that before but I was unable to find official documentation of this fact. Can you point me to it? Closest I found is forum posts claiming the ABI compatibility is good.

Re: What the hell is a target triple?

#134

Post by matheusmoreira »

damagednoob wrote: post #117
matheusmoreira wrote: post #34

> Go originally wanted to not have to link any system libraries, something that does not actually work It does work on Linux, the only kernel that promises a stable binary interface to user space. https://www.matheusmoreira.com/articles/linux-system-calls

When developing a small program for my Synology NAS in Go, I'm sure I had to target a specific version of glibc.

Probably because the networking libraries use it for name resolution. That's a choice the developers of the Go implementation made. It's not required.

Re: What the hell is a target triple?

#135

Post by forrestthewoods »

f_devd wrote: post #127
forrestthewoods wrote: post #21

Earlier quoted context omitted.

BE isn’t technically dead buts it’s practically dead for almost all projects. You can static_assert byte order and then never think about BE ever again. All of my custom network serialization formats use LE because there’s literally no reason to use BE for network byte order. It’s pure legacy cruft.

...Until you find yourself having to workaround legacy code to support some weird target that does still use BE. Speaking from experience (tbf usually lower level than anything actually networked, more like RS485 and friends).

18 years in my career and I’m still waiting for that BE target to rear its ugly head.

I’m more than happy to static_assert little endian. If any platform needs BE support then I’ll add support to the minimum amount of libraries necessary to do so. Super easy.

Here’s the thing. If you wrote BE compatible code today you probably dont even have a way to test it. So you’re adding a bunch of complexity and doing a bunch of work that you can’t even verify is correct! Complete and total waste of time.

Re: What the hell is a target triple?

#136

Post by kowabungalow »

arp242 wrote: post #78

> There are also many ficticious names for 64-bit x86, which you should avoid unless you want the younger generation to make fun of you. amd64 refers to AMD’s original implementation of long mode in their K8 microarchitecture, first shipped in their Athlon 64 product. Calling it amd64 is silly and also looks a lot like arm64, and I am honestly kinda annoyed at how much Go code I’ve seen with files named fast_arm64.s…

There's genuine AMD_64 and the knock off by their slower competitor who coined the genuine emphasis for the first to market. I don't see what is confusing about that.

Re: What the hell is a target triple?

#137

Post by ComputerGuru »

Zamiel_Snawley wrote: post #87
ComputerGuru wrote: post #72

Great article but I was really put off by this bit, which aside from being very condescending, simply isn't true and reveals a lack of appreciation for the innovation that I would have thought someone posting about target triples and compilers would have appreciated: > Why the Windows people invented a whole other ABI instead of making things clean and simple like Apple did with Rosetta on ARM MacBooks? I have no ide…

Do those criticisms of Rosetta hold for Rosetta 2? I assumed the author was talking about the x86 emulator released for the arm migration a few years ago, not the powerpc one.

They do indeed. Rosetta 2 is lightyears beyond Rosetta when it comes to performance and emulation overhead strategies and benefits from hardware support (and having to do less work just because of fewer differences between the host/target architectures) but still fundamentally relies on the emulation the entirety of the stack. There is almost zero information about its internals disclosed, but from what I understand it still revolves around fat binaries - and necessitates that Apple compiles their frameworks against both x86_64 and arm64. Unlike the MS solution, with Rosetta 2 you cannot call a native ARM64 library from an x86_64 binary, you can't port your code over piece-by-piece, and once Apple decides to no longer ship the next version of xxx framework as a fat binary because they don't want to maintain support for two different architectures in their codebase (wholly understandable), you'll (at best) be left with an older version of said framework that hasn't been patched to address the latest bugs, doesn't behave the same way that newer apps linking against the newer version of the framework do, etc.

Re: What the hell is a target triple?

#138

Post by ComputerGuru »

plorkyeran wrote: post #111
ComputerGuru wrote: post #72

Great article but I was really put off by this bit, which aside from being very condescending, simply isn't true and reveals a lack of appreciation for the innovation that I would have thought someone posting about target triples and compilers would have appreciated: > Why the Windows people invented a whole other ABI instead of making things clean and simple like Apple did with Rosetta on ARM MacBooks? I have no ide…

The thing named Rosetta (actually Rosetta 2) for the x86_64 -> ARM transition is technologically completely unrelated to the PPC -> x86 Rosetta, and has none of the problems you mention. There's no user-observable difference between a program using Rosetta and a native program in modern macOS, and porting programs which didn't have any assembly or other CPU-arch-specific code was generally just a matter of wrangling…

I addressed that in my response here: https://news.ycombinator.com/item?id=43720758

Re: What the hell is a target triple?

#139

Post by amszmidt »

steveklabnik wrote: post #76
AceJohnny2 wrote: post #67

Earlier quoted context omitted.

I'd love to learn what accident you're referring to, Steve! I vaguely recall the FSF (or maybe only Stallman) arguing against the modular nature of LLVM because a monolothic structure (like GCC's) makes it harder for anti-GPL actors (Apple!) to undermine it. Was this related?

That is true history, in my understanding, but it's not related. Chris Lattner offered to donate the copyright of LLVM to the FSF at one point: https://gcc.gnu.org/legacy-ml/gcc/2005-11/msg00888.html He even wrote some patches: https://gcc.gnu.org/legacy-ml/gcc/2005-11/msg01112.html However, due to Stallman's... idiosyncratic email setup, he missed this: https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00...…

The only truth to the story is the missed email.

There is nothing "unmodular" about GCC -- considering that it supports plenty of architectures, operating systems, and languages.

The big difference, which people seem to miss in the context of the GNU project and GNU system, is that modularity is for free software projects. GCC is planty modular, and very easy to extend in any way shape or form .. if you abide by the license!

If you want to be a parasite on a project licensed under the GNU GPL, you will have a rough ride .. that is after all the whole idea of copyleft.

Post reply on HN