Shared libraries in Linux

Hi,

I have a question about shared libraries in Linux.

When create my application in Windows, I can add the libraries I want to use simply in the .pro file:

Code:

---

win32:release {
        LIBS    += release/frist.dll \
            release/second.dll
}
 
win32:debug {
        LIBS    += debug/frist.dll \
            debug/second.dll
}

---

The same code doesn't work in Linux:

Code:

---

unix {
        LIBS    += release/libfrist.so.1.0.0 \
            release/libsecond.so.1.0.0
}

---

I'm able to compile the executable, but when I try to execute it, just nothing happens.
I used ldd (terminal command) to list all libraries which are used by my executable. It lists my *.so-file, but it says "not found". The Qt libraries are also listed, but that can be found. Why isn't Linux able to find my libraries? I put them in the same directory as the executable. I also tried to put them to /usr/lib and to put them to /lib but that didn't work, too. Do I need to register the libraries first or did I do something wrong when I compiled the executable?

It is "-L directorycontainingthelibrary -l nameofthelibrary" (both on Windows and Linux).

Thanks for the answer. The syntax works on Windows and I'll try it tomorrow on Linux.

I'll tried to use the syntax like explained on Linux, but it does not work. On Windows it is working fine.

Here's the code of my project file:

Code:

---

unix {
        LIBS += -L../ -lIO \
             -L../ -lDialogs
}

---

The compiler just says:

Quote:

---

cannot find -lIO
cannot find -lDialogs
collect2: Id returned 1 exit status

---

What does the last line mean?

The files libIO.so and libDialogs.so are stored in the same directory as the project file. This is also the path where the compiler stores the binary files (I tested it without using the libraries).
It doesn't work if I remove the 'lib' before the libraries' filenames, too. When I compile the libraries, I also get some 'shortcuts' with version numbers of my *.so-file. Do I need them?

I'm also wondering, why the compiler stored the binary files directly in the project folder. When I compile the same project on Windows, the compiler stored the binary files in the debug/release-folder (which is in the project folder). I'm not using a shadow build to specify the output directory (on Windows and Linux).

Quote:

---

The compiler just says:

Code:

---

cannot find -lIO
cannot find -lDialogs
collect2: Id returned 1 exit status

---

What does the last line mean?

---

It means that ld (LD in lower case), your linker, failed. The two lines before it tell you why: neither IO nor Dialogs is the name of a library, or they cannot cannot be found in the standard library location or the additional (-L) paths you gave the linker. You should have files libIO.so and libDialogs.so for this to work as written. File names on Linux are case sensitive.

Thanks for helping.

I have the both library files (with the correct names, I mind the case sensitivity) in the directory where my project and the executables are stored. Maybe the problem is, that I'm using a relative path (-L../). I'll try to use an absolute path, when I'm working on Linux again. Makes it a difference, what kind of path I use on Linux (on Windows I noticed no difference)? And when I use a relative path, to what directory is it relative? I think it is the directory, where my Project-File is stored.

I have an other question. The partition where the project files (of all my projects) are stored uses the NTFS file system. I'm not able to run my executables directly from that partition. Of course I tryed to set the entitlement of the executable to be able to run it, but that doesn't seem to work properly. If I copy the executable to an other partition with ext4 file system, I'm able to set the entitlement and to run the application. Is that a common problem (I found nothing on the Internet about it)? The distribution I'm using is LinuxMint.

And there is still that question:

Quote:

---

When I compile the libraries, I also get some 'shortcuts' with version numbers of my *.so-file. Do I need them?

---

Sorry for asking so many questions, I hope you can help me :)

You are using a relative path to the parent directory, the files are not there, and the default library search path rarely (if ever) includes the current directory.

I doubt the NTFS partition preserves UNIX file permissions which are required to determine what is executable (rather than guessing based on file name like Windows).

The "shortcuts" are symbolic links and are part of Linux/UNIX mechanisms to permit loading of libraries based on partial or no version numbers and simultaneous installation of different versions. The real file will typically be libblah.so.1.0.0 and the other links will be libblah.so, libblah.so.1, libblah.so.1.0, often forming a chain. You need at least the bare libblah.so during development or the "-lblah" option will not find the library. The other links are typically created automatically by the ldconfig program at install time.
http://tldp.org/HOWTO/Program-Librar...libraries.html

I finally solved the problem. The problem was just a missing permission (and not the relative path). There is the reading permission required but not the permission to execute. I guess the permission was missing, because the libraries were stored on a partition with NTFS file system (which doesn't support the UNIX permissions) and have just been copied to the ext4 partition.

Thanks for your help.