Guix Shell with FHS Feedback: lib/tls/x86_64/x86_64?

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:

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 .

On Tue, Dec 06, 2022 at 09:07 AM, Marek Pa?nikowski wrote:

Hello!

(resending as it seems debbugs in Emacs doesn't automatically add the

bug number email in the To/CC list.)

Great! You may want to see this recent mailing list thread and draft

blog post which also covers exactly this in an example:

specifically: https://lists.gnu.org/r/guix-devel/2022-12/msg00156.html

and: https://issues.guix.gnu.org/60112

In the FHS container you shouldn't need to set LD_LIBRARY_PATH. There

was a bug in the first weeks after it was merged (where this would work

around it), but assuming you have updated somewhat recently this

shouldn't be needed in genera.

I think this way lies madness. There will always be a ton of failing

calls, by nature of how things work. In particular, if you haven't see

this blog post, which covers exactly this (library loading), it was

enlightening for me at least:

But in general I agree, I also use strace to find out what is breaking.

Often you want to see the last set of calls, but not always.

Yes, the first one should be ignored as far as I know and is not

important.

The second one could be a failure, if that is where it stops looking for

libdl and errors out. So a more complete log, or at least the end where

an actual failure happens, would be helpful. As well as the exact

command you are running and the AppImage (if it is free software, of

course) would be good. Usually you'll see lots of these ENOENT errors

until it finds it in one of the search paths, or else an actual error

that the library could not be found and loaded.

This link didn't show for me.

I'm not certain you are actually failing at libdl. The FHS container

will show this library in /lib and in the ld cache, which should cover

just about everything trying to find it. More details would be helpful.

Hope this helps in the meantime!

John

Hi John,

On Fri, 23 Dec 2022 at 05:39, John Kehayias via Bug reports for GNU Guix <bug-guix@gnu.org> wrote:

Well, I think it is about Gnus and not Debbugs. There is bunch of

option to reply with Gnus. :-)

9 candidates:

gnus-summary-reply

gnus-summary-wide-reply

gnus-summary-very-wide-reply

gnus-summary-reply-with-original

gnus-summary-reply-broken-reply-to

gnus-summary-wide-reply-with-original

gnus-summary-reply-to-list-with-original

gnus-summary-very-wide-reply-with-original

gnus-summary-reply-broken-reply-to-with-original

Personally, I have this config (the only Gnus keybinding I use ;-))

(define-key gnus-summary-mode-map "R" 'gnus-summary-wide-reply-with-original)

(define-key gnus-article-mode-map "R" 'gnus-summary-wide-reply-with-original)

which is consistent with Emacs Notmuch key binding.

Hope that helps,

simon

Hi simon,

On Thu, Jan 05, 2023 at 12:31 PM, Simon Tournier wrote:

Yes that helps, exactly what I would have expected, thanks! It is now also my only Gnus keybindings, matching my others (mu4e in my case).

Much appreciated,

John