Get the shared library's fully qualified path in Linux

[c600g]

In a FPC/Lazarus shared library project on Windows, it is possible to get the fully qualified path name of the DLL using SysUtils.GetModuleName( hInstance ).

I know that it is possible to get the library name on Linux (see https://forum.lazarus.freepascal.org/index.php?topic=46695.0). However, this does not return the library's path - only it's filename.

Is there a way to return the shared library's fully qualified path on Linux?

Cheers 

[MarkMLl]

Interesting question, I suspect that it's complicated by the fact that in Linux (possibly in unix, i.e. also the BSDs etc.) the shared library paths are preconfigured: see ld.so.conf etc. In extremis you could probably inspect /proc/XXX/fdinfo where XXX is the current PID.

MarkMLl

[Zvoni]

why not just fire off a "which Library.so"?
or is he looking for a "custom" libraries path?

[MarkMLl]

PATH isn't the same as the library search path.

MarkMLl

[Zvoni]

PATH isn't the same as the library search path.

MarkMLl

crap. Forgot that. thx.

FWIW: https://unix.stackexchange.com/questions/22178/which-equivalent-for-shared-libraries

If you have an executable and you want to see where it's picking up libraries, run

ldd /path/to/executable

This will account for libraries on the default search path as well as libraries in this executable's rpath if any.

[MarkMLl]

This will account for libraries on the default search path as well as libraries in this executable's rpath if any.

But not for .so which have been loaded dynamically under program control :-/

I really don't have time to go digging into this in depth, but my recollection is that at least on Linux this is all handled outside the kernel (perhaps somewhere in libc? I forget) so should at least be inspectable. Now it stands to reason that if a program loads a .so explicitly it should know where it found it (think of all the problems of loading database libraries particularly if the expected symlink hasn't been set up) but that doesn't mean that some other part of the program can examine the library (accessible via pointers etc.) and say whence it came.

In my case I normally wrap a dynamic library (.so or .dll) in an instance of a class, but I don't think I've ever looked at exposing the load path.

MarkMLl

[AmatCoder]

In a FPC/Lazarus shared library project on Windows, it is possible to get the fully qualified path name of the DLL using SysUtils.GetModuleName( hInstance ).

I know that it is possible to get the library name on Linux (see https://forum.lazarus.freepascal.org/index.php?topic=46695.0). However, this does not return the library's path - only it's filename.

Is there a way to return the shared library's fully qualified path on Linux?

As far as I remember, dladdr function gives you a full path to the library, but it needs to be compiled to be position-independent (at least in C).

[MarkMLl]

As far as I remember, dladdr function gives you a full path to the library, but it needs to be compiled to be position-independent (at least in C).

I think you're right. Can't comment on the PI aspect, which probably depends on lots of things.

MarkMLl

[c600g]

Thanks for the ideas, all. I think the /proc/XXX/fd idea is doable, but at this time it isn't critical that I have this functionality on Linux. I just thought it reasonable that a loaded library would know it's own path (as it knows it's filename).

[Zvoni]

Thanks for the ideas, all. I think the /proc/XXX/fd idea is doable, but at this time it isn't critical that I have this functionality on Linux. I just thought it reasonable that a loaded library would know it's own path (as it knows it's filename).

Then again: Why would you need to know the Filesystem-location of the library within its own code?

[MarkMLl]

Thanks for the ideas, all. I think the /proc/XXX/fd idea is doable, but at this time it isn't critical that I have this functionality on Linux. I just thought it reasonable that a loaded library would know it's own path (as it knows it's filename).

I think AmatCoder's suggestion is a good one, but don't know whether it's Linux-specific.

Then again: Why would you need to know the Filesystem-location of the library within its own code?

Because of any search path the loader might apply. In e.g. a tech support environment you'd very much want to know what /actual/ file was loaded. Another case is where a dynamically-loaded library loads another library dynamically, with the handles being available but not the names.

MarkMLl

[Zvoni]

Then again: Why would you need to know the Filesystem-location of the library within its own code?

Because of any search path the loader might apply. In e.g. a tech support environment you'd very much want to know what /actual/ file was loaded. Another case is where a dynamically-loaded library loads another library dynamically, with the handles being available but not the names.

MarkMLl

Sorry, still not getting it.
A shared library is accessed from a „host“-application.
Irrespective if static or dynamic, the lib has to be „findable“ for the host, otherwise it fails to run the code inside the lib.
If he wants to know the libs location from within its own code, the code of the lib must have been called, meaning its host has found it, meaning its location is known

[MarkMLl]

meaning its host has found it, meaning its location is known

Those don't follow. There can be an OS-specific library search path in the way, of any number of symlink redirections like you typically get with a database library.

MarkMLl

[AmatCoder]

meaning its host has found it, meaning its location is known

Location is known by the OS but not by the application (it only knows the name of the library).

Example:
Application ask to the OS for a library (by name) -> OS returns an opaque pointer (not the full path of the library).