I'm porting a Windows 7 software project to CentOS 6.5. The project is composed of 4 executable and 9 plugins. The project depends on 12 shared libraries from Qt4.8, Chilkat and FFmpeg.

The software needs to be delivered as a RPM with all dependencies included.
The 4 executables are copied into a folder named PICTE.
The 12 shared libraries are copied into a folder PICTE/lib

Linking the Chilkat lib works with the following spec in the .pro file
QMAKE_CXXFLAGS += -ffriend-injection
QMAKE_LFLAGS = -Wl,-rpath,lib
LIBS += -l lib/libchilkat-9.5.0.so
LIBS += -l lib/libQtCore.so.4.8.6
LIBS += -l lib/libQtGui.so.4.8.6
LIBS += -l lib/libQtNetwork.so.4.8.6

However, the Qt libs return the error "No such file or directory".
I have also tried this with the dot reference:
QMAKE_LFLAGS = -Wl,-rpath,.
and also with:
QMAKE_LFLAGS = -Wl,-rpath-link,lib
QMAKE_LFLAGS = -Wl,-rpath-link,.
and with quotes:
QMAKE_LFLAGS = '-Wl,-rpath-link,lib'
and got the same result.

This seems like it should be possible to link to shared libraries bundles with my app.
Does anyone have a working example on how to do this?

Thanks,
Jeff H

Should be easy - if they are installed. And you should specify the full path, not a relative path.

If you are linking 32 bit applications they MIGHT be in /lib (partly depends on distribution), but they could also be in /usr/lib.

If you are linking on a 64 bit system, /lib is the wrong place. Look in /lib64.

When something is "missing", you might just look to see where it really is (hint - use find).

Also note - specifying the subversions of a library (such as /lib/libchilkat-9.5.0.so) can work - but it means that no other update will. The advantage of something like /lib/libchilkat.so.9 is that any 9 level version should work and allows updates to the library without having to update the application as well. Usually the library /lib/libchilkat.so.9 would have a symbolic link to the current version which could be /lib/libchilkat.so.9.5.0.

The emphasis of my question needs to be on "local" copies of libraries. These local lib copies are located in "/opt/picte/lib" and the four executables that use the libs are located in "/opt/picte".
Also, the chilkat lib is provided by its vendor as "libchilkat-9.5.0.so" not "libchilkat.so.9.5.0".
The problem that I'm having is that the Jenkins build system is always including a reference to the Jenkins system in the dependency path when I try to run RPM to install this software on a target machine.