Linux. qmake. Libraries in the same directory as an application

blex

Linux.

Suppose that libraries are located in the same directory as an application.
If we start the application then it fails with message that library not found.

The simplest way to solve this is to add "." to $LD_LIBRARY_PATH.
The better approach is to specify linker flag -Wl,-rpath,'$$ORIGIN' in Makefile (for LFLAGS).

The question: How to add the flag to Makefile using *.pro file? I cannot understand what characters should be escaped and how to do this.

Any advices?

brandont

See "documentation.":http://doc.qt.nokia.com/4.7/qmake-project-files.html#declaring-other-libraries

baysmith

@
unix:!mac{
QMAKE_LFLAGS += -Wl,--rpath=\$$ORIGIN
QMAKE_LFLAGS += -Wl,--rpath=\$$ORIGIN/lib
QMAKE_LFLAGS += -Wl,--rpath=\$$ORIGIN/libs
QMAKE_RPATH=
}
@

Setting the QMAKE_RPATH clears the default rpath setting for the Qt libraries. This allows for bundling the Qt libraries with the application. If you want the rpath to include the path to the Qt libraries, don't set QMAKE_RPATH.

blex

[quote author="brandont" date="1290269827"]See "documentation.":http://doc.qt.nokia.com/4.7/qmake-project-files.html#declaring-other-libraries[/quote]

Thank you for link, but I already read that section. I will try to clarify my question.

If I add to *.pro file the string

@linux-g++-64:LIBS+=-Wl,-rpath,’$$ORIGIN’@

then I get in Makefile the flags:

@LIBS = -Wl,-rpath,’’@

instead of expected

@LIBS = -Wl,-rpath,’$$ORIGIN’@

So, the question: What I should add to *.pro file to get the expected string in Makefile

blex

[quote author="Bradley" date="1290273062"]
Setting the QMAKE_RPATH clears the default rpath setting for the Qt libraries. This allows for bundling the Qt libraries with the application. If you want the rpath to include the path to the Qt libraries, don't set QMAKE_RPATH.[/quote]

Bradley, thank you! Exactly what I want, even more! Note about QMAKE_RPATH also very useful.

But I got the string in Makefile
@LIBS = -Wl,-rpath,’$$ORIGIN’@
with slightly different number of back slash characters:
@QMAKE_LFLAGS += -Wl,-rpath='$$ORIGIN'@

So, the problem is solved.

blex

Problem still not solved.

I generate the *.pro file from the perl script. The command is the following:

@
$cmd_line = "qmake -project -o $ARGV[0].pro ".

<< skipped >>
" linux-g++-64:QMAKE_LFLAGS+=-Wl,-rpath='$$ORIGIN' ";

print $cmd_line;

if (system($cmd_line)) {

die "Error generating pro-file $ARGV[0], stopped";

}

@

But I should escape characters in the perl script. Please advice how to do that, because I spent nearly one hour without any result. Escape sequense in perl, then is bash, then in qmake arguments processing... In the output file I should get the following:

@
QMAKE_LFLAGS += -Wl,-rpath='$$ORIGIN'
@

tobias.hunger

Debian strongly "argues against using rpath":http://wiki.debian.org/RpathIssue: It can blow into your face when you do not have all the dependencies under control.

So rpath is not "the better way", it is just another way with different issues you need to consider.

DenisKormalev

Tobias, so you are for creating script that will set LD_LIBRARY_PATH ? Or there is another way, diffrent from rpath and LD_LIBRARY_PATH? I've already used LD_LIBRARY_PATH way, but if there is something better it will be good new knowledge.

blex

[quote author="Tobias Hunger" date="1291471523"]Debian strongly "argues against using rpath":http://wiki.debian.org/RpathIssue: It can blow into your face when you do not have all the dependencies under control.

So rpath is not "the better way", it is just another way with different issues you need to consider.[/quote]

Thank you for link, very interesting. But, unfortunately, I should adopt to the existing development environment in our company. So, the question is still open.

baysmith

Using LD_LIBRARY_PATH is equivalent to using rpath. The setting is in a script rather than in the executable, but the effect and the consequences are the same. Of course from the Linux distro point of view, neither LD_LIBRARY_PATH or rpath is good for library compatibility or security problems. However, from a developer of user software point of view, they are necessary for simplifying what is required for user installation.

goetz

[quote author="blex" date="1291471051"]Problem still not solved.
I generate the *.pro file from the perl script. The command is the following:
[/quote]

Generating backslashes with perl is a PITA. In your case you additionally must triple qoute the string:

quote for your perl script to generate the right string

quote for the shell command you execute

quote for the .pro file

I'd suggest you go the reverse order. Make it work in the .pro file, then construct the correct shell command line manually, then have the perl script spit out the command line.

xsacha

[quote author="Bradley" date="1291481435"]Using LD_LIBRARY_PATH is equivalent to using rpath. The setting is in a script rather than in the executable, but the effect and the consequences are the same. [/quote]
But LD_LIBRARY_PATH is much easier to change (for an end-user) if their paths have changed.

You can also use ldd to check where it is finding your libraries.