bug#59855: Guix Shell with FHS Feedback: lib/tls/x86_64/x86_64?

[Marek Paśnikowski]

I recently started attempting to execute an AppImage with
guix shell --container --emulate-fhs .
I found a workflow, where I set LD_LIBRARY_PATH=$LIBRARY_PATH
and trace the executable with strace -ffZ ./Program.AppImage .
Its concept is that I want to turn each failing call to a successful
one, until the program runs flawlessly.
I program as a hobby, and have no way of knowing if any of the
trace calls can be safely ignored.

I would like to encourage development of such an implementation,
where strace -ffZ output is reduced as much as possible by default.
Here is the head of the current trace I am stuck at:

> access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file
> or directory)
>
> openat(AT_FDCWD, "/gnu/store/c8ndz685xbqm29r9zwlwsbjqj4ylh4m4-
> profile/lib/tls/x86_64/x86_64/libdl.so.2", O_RDONLY|O_CLOEXEC) = 
> -1 ENOENT (No such file or directory)

The second line is the interesting one.
According to an ancient post on the Linux Questions forum[1],
$PATH/lib/tls is the directory for glibc with thread support (NPTL).
I do not know if the glibc in Guix has the thread support or not.
However, it is the next two subdirectories that baffle me.
x86_64/x86_64?  I have never seen anything like this.
I thought, that maybe having a tls->. link in the lib directory
would suppress the failure, but lib also does not have
an x86_64 directory.

I have spent a couple of hours chasing the libdl libry,
only to realise that it is supplied by glibc, and it is
the AppImage program trying to reach it in a different place.
I strongly believe that solving this mode of failure will save
countless hours of futile struggle for future users of Guix Shell.
For the same purpose, the first error can be permanently silenced
by creating an empty file at /etc/ld.so.preload .