dlopen vs. RUNPATH

[Ludovic Courtès]

ludo@gnu.org (Ludovic Courtès) skribis:

> I have a use case where libgcc_s.so fails to be dlopen’d, even though
> its directory is in the main application’s RUNPATH:

On further inspection, I think the explanation is that
pthread_cancel_init uses __libc_dlopen, which causes libpthread’s name
space (its ‘link_map’) to be used, not the application’s name space.
Neither libpthread’s RUNPATH nor $LD_LIBRARY_PATH points to the
directory of libgcc_s, hence the failure (conversely,
dlopen("libgcc_s.so") from the application succeeds.)

One possible fix would be to augment $(user-defined-trusted-dirs).

Ludo’.