ldconfig not following symlinks

Hi Forums,

I have decided to give Lazarus/FreePascal another try, because I read a tutorial about dynamic layouts, which i found kind of lacking in the LCL before.

I installed Lazarus, Freepascal, and qt4pas along with the -devel packages. When recompiling Lazarus for qt or compiling a project for qt, the linker ld complains about missing qt4intf library.

I looked up in ldconfig, but the output of

ldconfig -p | grep qt4intf

is empty

manually starting ldconfig won’t help and manually linking the library with

ldconfig -l /usr/lib/libqt4intf.so

gives me the output

ldconfig: Datei /usr/lib/libqt4intf.so übergangen, da sie keine reguläre Datei ist.

“ldconfig: File /usr/lib/libqt4intf.so skipped, as it is no regular file”
I looked up for the file myself and found that it is a symlink to file:///usr/lib/libQt4Pas.so which is a symlink to file:///usr/lib/libQt4Pas.so.5.2.0. Is there any way to get this working or do I have to rename the real file to libqt4intf.so? What I normally don’t want to do (the files are provided by the same package, so it’s doable without breaking too much, if there’s no other way)…

That command doesn’t do what you think. It’s not for you to use, it’s for library maintainers. (Too long to explain here and not relevant.) It looks like the problem is you have not installed the qt4inf library, whatever it is. You have to find the packages that contains it and install that.

Thank you for your answer. The command for linking a library manually is from the manpage. I didn’t know about this before.

The package that provides the lib is installed (libqt4pas5 from packman 11.2 i586), but the “lib” is a symlink that links to another symlink which links then to a valid lib. I’ve solved that by copying the target file to /usr/lib/libqt4intf.so, but the package seems to be further broken, because a source-file provided by the package seems to miss something…

I believe I have to test Lazarus without qt support though, or dig further into the problem.

The symlink scheme is normal for shared libraries, it generally works like this:

libsomething.so -> libsomething.so.5 -> libsomething.so.5.2.0

Perhaps it was the second issue that was the real problem, not the symlink scheme?