I have a library I've created. I also have my own application that uses this library.

Now, since in this day and age you can use a prefix and choose where to install applications, I would really much like to know, inside my library, where I am installed - since I know that I have some files scattered around in different places. I just don't know the prefix they used when they installed me.

So, to sum up: how can a class constructor inside a library (.so-file) find the path of the library.so-file?

Thanks!

It's actually very difficult if not impossible to determine that... and, I would think, you really should not need to. You want the user to decide how-and-where he "found you." And you ought not need to know where that actually was.

Ok, so maybe there is another solution to this problem:
My build/install system (which is cmake, btw) installs the library in $PREFIX/lib and also puts some files in $PREFIX/share/<myname>/

Now, I have a class constructor inside this library that needs to access those files inside the share-folder. But I don't know the prefix. :/

Where the library is stored and found by the linker/loader should be completely independent of any filesystem references embedded within its object code. The behavior of the runtime code should be identical no matter where the loader finds the library.
What is more germane to the question would be the 'present working directory', which always has some value that refers to a place in the filesystem. Paths expressed at runtime can be either absolute (relative to '/' ) or relative to the current working directory. The concept of current working directory holds on a per-process basis, so the same runtime binary may execute from almost any current working directory, and may also change directories at runtime. Nothing you build into a library (except code that explicitly changes directories) can change this, nor can you change this by storing your libraries differently.

--- rod.

Yeah, so you told me what not to do.. And I understand your point. But you haven't given me any ideas to a solution to my problem.

Maybe you missed it:

CASE 1
The user installs my library with prefix: /usr/local

The library gets installed by the build system to:
/usr/local/lib/libdynapt.so
The build system also installs some important files:
/usr/local/share/dynapt/chii.rpe, among others...

CASE 2
The next user uses another prefix: /usr
Library: /usr/lib/libdynapt.so
Files: /usr/share/dynapt/chii.rpe



Now, my application (called Tricera) is linked (-ldynapt) and creates an instance of a class which is defined inside the library, let's call it ClassHideki();

Problem is, there's a lot of stuff going on inside this ClassHideki and eventually we get down to a class that needs to access those extra files (for example chii.rpe). Now, I am trying to remove the hardcoded path /usr/share/dynapt/chii.rpe from my source, making it work with other prefixes.

Have in mind that I, thorugh ClassHideki(), may need to let Tricera get the path to chii.rpe for some reason.

So, what you are saying is that I should not "calculate" the path to chii.rpe depending on where libdynapt.so is. I got that.

So any other ideas how to find this file?

EDIT: It doesn't have to be runtime, I know that. But still, I need help here.. I am no good at either cmake or the #<stuff>.. :P

You are trying to do work that the loader does. When you create a runtime binary that uses shared object libraries, the linking loader resolves all of these issues for you. It uses the information in $LD_LIBRARY_PATH and/or /etc/ld.so.conf to find the necessary libraries. Your runtime code doesn't need to do anything to go out and locate its own object code.
--- rod.

No, my goal is not to locate the .so-file. I want to locate the files inside $PREFIX/share/dynapt/