Linking internal libraries
-
Hi,
Thanks for your input on this.
That's pretty close to what I have in my unit test pro file, certainly the end result of adding "-L{path} -l{lib}" to LIBS is what I am already doing.
I've created the same structure you just described, and I still get the same issue. When attempting to run the successfully compiled and linked unit test from a console, it cannot find libSimpleMath.so
When running the unit tests directly from QtCreator these work, printing out the value of $LD_LIBRARY_PATH to stderr from the slot shows that QtCreator determined it needed to add $$absolute_path(../SimpleMath) to LD_LIBRARY_PATH before executing the test, but the produced target_wrapper.sh file only contains
LD_LIBRARY_PATH=/usr/local/digia/Qt5.8.0/5.8/gcc_64/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH} export LD_LIBRARY_PATHWhat I am trying to achieve is to gather the results of unit tests when run on a headless build server when I have executed
make check TESTARGS="-o result.xml,xml"Running make check on a terminal fails because LD_LIBRARY_PATH is not correctly set at any location.
I have put a zip of the project structure matching what you created in your example on filebin
@Paul-Thexton sorry, when I wrote you last time it was pretty late and I missed testing the executable from the command line.
You are right, it does't work and target_wrapper.sh is completely useless.
I will look into this as I need to sort it out too, but let us know if you manage to find a proper solution :)
-
@Paul-Thexton sorry, when I wrote you last time it was pretty late and I missed testing the executable from the command line.
You are right, it does't work and target_wrapper.sh is completely useless.
I will look into this as I need to sort it out too, but let us know if you manage to find a proper solution :)
Thanks @vivaladav - the way I've worked around this for the time being (on Linux platform) is to explicitly build a LD_LIBRARY_PATH environment to force in to the make system.
Obviously this is dependent on the following
- All folders required for inclusion are at the same level
- There are no name clashes with libraries (there never should be of course, but it's not impossible with poorly structured projects)
If anybody finds this post who has similar problems, this is what I do to force LD_LIBRARY_PATH to contain all folders at the project top level so that "make check" works.
export LD_LIBRARY_PATH=`find . -mindepth 1 -maxdepth 1 \! -name ".*" -type d | xargs realpath | awk '{if(NR != 1){printf ":"}printf "%s", $0} END{print ""}'` export TESTARGS="-o TEST.xml,xml" make check -
Thanks @vivaladav - the way I've worked around this for the time being (on Linux platform) is to explicitly build a LD_LIBRARY_PATH environment to force in to the make system.
Obviously this is dependent on the following
- All folders required for inclusion are at the same level
- There are no name clashes with libraries (there never should be of course, but it's not impossible with poorly structured projects)
If anybody finds this post who has similar problems, this is what I do to force LD_LIBRARY_PATH to contain all folders at the project top level so that "make check" works.
export LD_LIBRARY_PATH=`find . -mindepth 1 -maxdepth 1 \! -name ".*" -type d | xargs realpath | awk '{if(NR != 1){printf ":"}printf "%s", $0} END{print ""}'` export TESTARGS="-o TEST.xml,xml" make check@Paul-Thexton nice one, even if I would recommend you to fill a bug report as things should be handled better by qmake.
An alternative and simpler solution would be to build and link the library as static. I appreciate this might not be always what wanted, but it can be ok in many cases.
-
hey @Paul-Thexton, I just noticed that Qt Creator 4.5 is not creating target_wrapper.sh any more. Can you confirm this?
-
hey @Paul-Thexton, I just noticed that Qt Creator 4.5 is not creating target_wrapper.sh any more. Can you confirm this?
@vivaladav I've just tried with Creator 4.5 and the file is still created, however I've installed it as a standalone and still using the Qt5.8.0 Kit
I will download Qt5.10.0 later and confirm what happens, and whether my solution above is still valid - I suspect it'll be something in qmake for 5.10 that has changed.
-
Did you set your rpath dependencies with QMAKE_LFLAGS ?
e.g.
QMAKE_LFLAGS += '-Wl,-rpath,\'\$$ORIGIN/libs\'' QMAKE_LFLAGS += '-Wl,-rpath,\'$${QMAKE_LIBDIR_QT}\'' -
Did you set your rpath dependencies with QMAKE_LFLAGS ?
e.g.
QMAKE_LFLAGS += '-Wl,-rpath,\'\$$ORIGIN/libs\'' QMAKE_LFLAGS += '-Wl,-rpath,\'$${QMAKE_LIBDIR_QT}\''@karlheinzreichel yes. The problem is that qmake internally also sets the rpath for the location of the Qt libs (which can be seen in the compile output) and compilers don't seem to like two rpaths being set, I don't know the internals of linux Elf format well enough to say for certain, but it could well be that only one rpath is supported.
-
@vivaladav I've just tried with Creator 4.5 and the file is still created, however I've installed it as a standalone and still using the Qt5.8.0 Kit
I will download Qt5.10.0 later and confirm what happens, and whether my solution above is still valid - I suspect it'll be something in qmake for 5.10 that has changed.
@Paul-Thexton it happens with Qt 5.10 yes, but it happened only in a project with 1 app, 1 lib and 1 unit test app.
I will need to investigate this further, but it seems the whole target_wrapper thing is a mess at the moment.
-
In case anybody else finds this post looking for a solution to the problem, I had a real dig around all of the Qt mkspec stuff and found the variable that needs setting to do this properly...
QMAKE_RPATHDIR
i.e.: QMAKE_RPATHDIR += $$RELATIVE_PATH_TO_SHLIB_BUILD
Pretty straightforward in the end, but if that answer's in the documentation anywhere then it's hidden deep :)
-
Hi,
Some more information about it QMAKE_RPATHDIR here.
-
In case anybody else finds this post looking for a solution to the problem, I had a real dig around all of the Qt mkspec stuff and found the variable that needs setting to do this properly...
QMAKE_RPATHDIR
i.e.: QMAKE_RPATHDIR += $$RELATIVE_PATH_TO_SHLIB_BUILD
Pretty straightforward in the end, but if that answer's in the documentation anywhere then it's hidden deep :)
@Paul-Thexton it's always easy when you know the solution... ;-)
Thanks for sharing it!
