| |
| ▲ | int_19h 5 hours ago | parent | next [-] | | The consequences of this genius decision were stuff like this: https://github.com/golang/go/issues/16570 Which is why they have already backpedalled on this decision on most platforms. Linux is pretty much the only OS where the syscall ABI can be considered stable. | |
| ▲ | badsectoracula 10 hours ago | parent | prev | next [-] | | > Glibc is the main reason Linux software is binary non-portable between distros Linux software is binary portable between distros as long as the binary was compiled using a Glibc version that is either the same or older than the distros you are trying to target. The lack of "portability" is because of symbol versioning so that the library can expose different versions of the same symbol, exactly so that it can preserve backwards compatibility without breaking working programs. And this is not unique to Glibc, other libraries do the same thing too. The solution is to build your software in the minimum version of libraries you are supposed to support. Nowadays with docker you can set it up in a matter of minutes (and automate it with a dockerfile) - e.g. you can use -say- Ubuntu 22 to build your program and it'll work in most modern Linux OSes (or at least glibc wont be the problem if it doesn't). | |
| ▲ | steveklabnik 13 hours ago | parent | prev [-] | | You can only skip libc on Linux. Other unices and Windows don’t let you. | | |
| ▲ | immibis 11 hours ago | parent [-] | | You can skip libc on Windows - you can't skip the system DLLs like kernel32. (In fact, Microsoft provided several mutually incompatible libcs in the past.) Well, you can non-portably skip kernel32, and use ntdll, but then your program won't work in the next Windows version (same as on any platform really - you can include the topmost API layers in your code, but they won't match the layers underneath of the next version). But system DLLs are DLLs, so also don't cause your .exe to get bloated. | | |
| ▲ | steveklabnik 10 hours ago | parent [-] | | Yes, it's not literally libc on windows, but the point is that directly calling syscalls is not supported, you have to call through the platform's library for doing so. On some systems, this is just not a supported configuration (like what you're talking about with Windows) and on some, they go further, and actually try and prevent you from doing so, even in assembly.) | | |
| ▲ | immibis 10 hours ago | parent [-] | | There's still something on the platform that you can call without extra indirection in the way on your side of the handoff. That is true on all platforms; whether it's an INT or SYSCALL instruction or a CALL or JMP instruction is irrelevant. | | |
| ▲ | int_19h 5 hours ago | parent [-] | | If it's a CALL instruction into a user-space DLL, that's still an extra indirection. |
|
|
|
|
|
