Post B1rsf2gZ7eM8raA7pw by amonakov@mastodon.gamedev.place
(DIR) More posts by amonakov@mastodon.gamedev.place
(DIR) Post #B1r9RprF0bZTNPU4cy by wolf480pl@mstdn.io
2026-01-01T23:30:42Z
0 likes, 0 repeats
If an x86-64 going Linux system does not have a dynamic linker (not even as a symlink) at /lib64/ld-linux-x86-64.so.2, but has it at a different path, that is:
(DIR) Post #B1r9nTUcqCsENtDxh2 by lanodan@queer.hacktivis.me
2026-01-01T23:34:32.138409Z
0 likes, 0 repeats
@wolf480pl if it's glibc at a different path: Annoying for no reason.Otherwise it's like how musl, uclibc, … are at different paths.
(DIR) Post #B1rMauz0cZnVHamLFg by kc@mastodon.dragoncave.dev
2026-01-02T01:57:58Z
0 likes, 0 repeats
@wolf480pl I voted "perfectly reasonable" and the android mastodon client I use crashedI shall take it as a sign the devs of the client I use disagree
(DIR) Post #B1rsf2gZ7eM8raA7pw by amonakov@mastodon.gamedev.place
2026-01-02T07:47:00Z
0 likes, 0 repeats
@lanodan @wolf480pl I'd raise the stakes to "violates the x86-64 ELF psABI, which spells out the dynamic linker path very clearly" if it's elsewhere on Glibcbut musl ld.so does, in fact, avoid the name clash: https://gcc.gnu.org/cgit/gcc/tree/gcc/config/i386/linux64.hld.so paths for uclibc and bionic are here: https://gcc.gnu.org/cgit/gcc/tree/gcc/config/linux.h
(DIR) Post #B1rsf43e1KPZ7Ry4Rs by wolf480pl@mstdn.io
2026-01-02T07:57:16Z
0 likes, 0 repeats
@amonakov@lanodan > There is one valid program interpreter for programs conforming to the AMD64 ABI:> /lib/ld64.so.1> However, Linux puts this in> /lib64/ld-linux-x86-64.so.2https://refspecs.linuxfoundation.org/elf/x86_64-abi-0.99.pdf:thinking_hard:
(DIR) Post #B1rsr6rlP9lJIv9d8i by amonakov@mastodon.gamedev.place
2026-01-02T07:59:28Z
0 likes, 0 repeats
@wolf480pl @lanodan the current version of the psABI can be found here: https://gitlab.com/x86-psABIs/x86-64-ABI
(DIR) Post #B1rtPoQByQO8Eanzw8 by wolf480pl@mstdn.io
2026-01-02T08:05:46Z
0 likes, 0 repeats
@amonakov @lanodan > valid program interpreter for programs conforming to the AMD64 ABI is listed in Table 5.4, which also contains the program interpreter used by Linuxhttps://gitlab.com/x86-psABIs/x86-64-ABI/-/blob/master/x86-64-ABI/dl.tex?ref_type=heads#L406I think this implies the one used by Linux is not valid
(DIR) Post #B1rwhiMlWdIoWsQlkG by amonakov@mastodon.gamedev.place
2026-01-02T08:42:35Z
0 likes, 0 repeats
@wolf480pl @lanodan haha, fair point! I can tell you that the linker (ld) will set PT_INTERP to the "valid program interpreter path" if invoked directly (otherwise gcc will override the path as shown in links above), but the psABI is phrased weirdly for sure. s/valid/generic/ would fit the situation better, I think
(DIR) Post #B1rwvbF4oDk8UMSHnU by wolf480pl@mstdn.io
2026-01-02T08:45:07Z
0 likes, 0 repeats
@amonakov @lanodan well, if it's "generic" then I'd hope they'd specify in which cases one should use the generic one, and when it's appropriate for an OS to have a different one.Though I haven't checked in gABI, maybe it's spelled out in there...
(DIR) Post #B1rxV3YDY94EQEJbn6 by wolf480pl@mstdn.io
2026-01-02T08:51:30Z
0 likes, 0 repeats
@amonakov@lanodan also, it seems that in the older version, the authors were pissed at Linux using a different path
(DIR) Post #B1rzihWWRYSs4H9kxs by amonakov@mastodon.gamedev.place
2026-01-02T09:16:23Z
0 likes, 0 repeats
@wolf480pl @lanodan which is especially weird, because the authors are the OpenSUSE team responsible for amd64 bringup! the mailing list where such discussions happened was archived at x86-64\.org, but these days you have to browse it through web.archive.org, as it went down in 2016also, git repo has all the history from those times, and you can see at some point it had a more straightforward "Every Operating System will change this": https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/9cc11a502ad523bd62c705f0744cd2bee26d72b0#f8dcf68a60cab0bdde5d78f59bbb573a2f050e58
(DIR) Post #B1s78rTokQKO9hJRho by Suiseiseki@freesoftwareextremist.com
2026-01-02T10:39:34.302519Z
1 likes, 0 repeats
@wolf480pl >Linux systemequery b ld-linux-x86-64.so.2sys-libs/glibc-2.42 (/lib64/ld-linux-x86-64.so.2)
(DIR) Post #B1s7HrKCh4BwHT6eBs by wolf480pl@mstdn.io
2026-01-02T10:41:11Z
0 likes, 0 repeats
@Suiseiseki I meant "x86-64 glibc Linux system" but it autocorrected "glibc" to "going" :blobfacepalm:
(DIR) Post #B1s7M1jdvjq7j4zbf6 by wolf480pl@mstdn.io
2026-01-02T10:41:57Z
0 likes, 0 repeats
ffs "glibc" got autocorrected to "going"... fuck you AnySoftKeyboard
(DIR) Post #B1s7dqS8cHPPwmIjI0 by Suiseiseki@freesoftwareextremist.com
2026-01-02T10:45:10.242267Z
0 likes, 0 repeats
@wolf480pl You could have just written x86-64 GNU system and have been correct and have saved yourself some typing.
(DIR) Post #B1s7m7Uh8pGn7GRVzs by wolf480pl@mstdn.io
2026-01-02T10:46:40Z
0 likes, 1 repeats
@Suiseiseki are you sure glibc puts the dynamic linker at the same path regardless if it's built for Linux, HURD, or kFreeBSD? And on all these systems, the path contains the word "linux"?
(DIR) Post #B1s8CvZnYispyNc3hA by Suiseiseki@freesoftwareextremist.com
2026-01-02T10:51:30.954297Z
0 likes, 1 repeats
@wolf480pl Okay, I guess "x86-64 GNU/Linux system" would have been needed to be specific enough.
(DIR) Post #B1s8RcOd9WFapYOVGa by amonakov@mastodon.gamedev.place
2026-01-02T10:54:03Z
0 likes, 0 repeats
@wolf480pl @lanodan perhaps it for the (theoretical) case of OS implementing the ABI in a fully conformant manner _and_ programs not relying on any extensions — where all dynamic linkers would be perfectly interchangeable(heh, in that light, maybe older versions of musl could have used that path)
(DIR) Post #B1s8cR4dabxEtrCVlI by Suiseiseki@freesoftwareextremist.com
2026-01-02T10:56:07.395073Z
0 likes, 0 repeats
@wolf480pl On GNU/Hurd it's just /lib/ld.so.1
(DIR) Post #B1s8hoQoAqYGn38Q3E by amonakov@mastodon.gamedev.place
2026-01-02T10:57:04Z
0 likes, 0 repeats
@wolf480pl oooh damn. I was going to jokingly ask if "going" was autocorrected from "GNU"I voted "perfectly reasonable" but that was assuming non-GNU Linux is in scope
(DIR) Post #B1s8mrGL4j9l1Ddygi by wolf480pl@mstdn.io
2026-01-02T10:58:00Z
0 likes, 0 repeats
@amonakov I guess I need to make a new poll...
(DIR) Post #B1s9oazIehjh4o4Anw by lanodan@queer.hacktivis.me
2026-01-02T11:09:29.156712Z
0 likes, 0 repeats
@amonakov @wolf480pl Makes me wonder what was the context of that psABI.Like I'd guess something from SVID era, and probably would have ended up with a gcompat equivalent on systems too different from SystemV ABI.
(DIR) Post #B1sRI1F7ogp07m5IHY by sjb@mstdn.io
2026-01-02T14:25:19Z
0 likes, 0 repeats
@wolf480pl Coincidentally, I have an x86-64 going Linux system at home.
(DIR) Post #B1sSPLCa6kaE0Vwx1s by wolf480pl@mstdn.io
2026-01-02T14:37:51Z
0 likes, 0 repeats
@sjbI hate autocorrect
(DIR) Post #B1sVgOh0gM5RcS0VkW by sjb@mstdn.io
2026-01-02T15:14:31Z
0 likes, 0 repeats
@wolf480pl I'd like to interject that the operating system you refer to as "Linux" is actually going/Linux.
(DIR) Post #B1sYpi0WXVeTzXGZoe by wolf480pl@mstdn.io
2026-01-02T15:24:25Z
0 likes, 0 repeats
@sjb (meant "glibc")
(DIR) Post #B1spuJh440f1Fgwnlg by amonakov@mastodon.gamedev.place
2026-01-02T11:22:23Z
1 likes, 0 repeats
@lanodan @wolf480pl there was also https://en.wikipedia.org/wiki/Intel_Binary_Compatibility_Standard but by 2000 I'd expect nobody would seriously expect such cross-OS binary portability to work outside of toy examples (without considering cases where one OS ships a compatibility layer for the other)