Linking internal libraries

[Paul Thexton]

Thank you @aha_1980

Yes I want the tests to find the libraries at runtime. On the macOS platform this is simple to achieve as I can use the install_name_tool to change where the linked library should be found, but on Linux I need to use either rpath or LD_LIBRARY_PATH

The reason for this is that I want to be able to build the projects on a build server and have it execute "make check" (with relevant additional logging arguments supplied) as a build step.

The test project described is just a sample I put together to test the layout I want to use in a real project.

[VRonin]

in Top Level, UnitTests should require LibOne and LibTwo. does it?
Could you post "TopLevel.pro"?

[Paul Thexton]

Top level .pro file is very simple

TEMPLATE = subdirs

CONFIG += ordered

SUBDIRS += LibOne \
    LibTwo \
    UnitTests

UnitTests.depends = LibOne LibTwo

[VRonin]

Last question, what is DESTDIR of each of those projects?

[aha_1980]

@Paul-Thexton

Why do you use CONFIG += ordered? You already specify the dependencies.

Please see here why this is not recommended: https://blog.rburchell.com/2013/10/every-time-you-configordered-kitten-dies.html

[Paul Thexton]

@VRonin I haven't specified a DESTDIR for this sample project, the outputs are generated in to the current project folder.

@aha_1980 I think it was supplied by the template when I created the project, you're right that it's superfluous :)

[vivaladav]

@Paul-Thexton no need to play around with rpath.

I created an example project that does what you are trying to do:

|TestingLib (TEMPLATE = subdirs)
|-->SimpleMath (TEMPLATE = lib)
|--> UnitTest (TEMPLATE = app)

This is the UnitTest .pro

QT += testlib
QT -= gui

CONFIG += qt console warn_on depend_includepath testcase
CONFIG -= app_bundle

TEMPLATE = app

SOURCES += \
    TestSimpleMath.cpp

HEADERS += \
    TestSimpleMath.h

DEPENDPATH += \
    ../SimpleMath

INCLUDEPATH += \
    ../SimpleMath

CONFIG(release, debug|release) {
    LIBS += -L../SimpleMath -lSimpleMath

    !build_pass:message(Release build!)
    !build_pass:message($$LIBS)
}

CONFIG(debug, debug|release) {
        LIBS += -L../SimpleMath -lSimpleMath

        !build_pass:message(Debug build!)
        !build_pass:message($$LIBS)
    }
}

The idea is to use LIBS to point to where the shared lib is.

[Paul Thexton]

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_PATH

What 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

[aha_1980]

@Paul-Thexton said in Linking internal libraries:

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

Yes, that's correct. Creator parses the LIBS += -L lines and adds everything after -L to LD_LIBRARY_PATH.

I'm not sure where target_wrapper.sh comes from. Is that created by qmake?

Anyhow, if your structure is somewhat statically, I'd just create my own script to setup the environment as needed.

[Paul Thexton]

target_wrapper.sh is created by qmake yes. There are various "solutions" to this problem around on stackoverflow and so on where people have the exact same problem, but none of the solutions provided actually work (probably due to the internals of the Qt mkspecs changing over the years that breaks those workarounds).

I've got a way of making it work which I'd prefer not to do (it's one more thing to maintain in a codebase which potentially could get very large over time), but really it feels like there's something missing in qmake as the target_wrapper.sh already accommodates the change required to point to the Qt libs, it feels like it should also have been pointing at any other dependency locations.

[aha_1980]

@Paul-Thexton: Well, you can search on bugreports.qt.io if there is already a report for this, if not you can create your own report.

But if you really want to have this function, you should modify qmake yourself and submit your patch to Gerrit. If that's worth the work, you have to decide yourself.

[vivaladav]

@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]

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

[vivaladav]

@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.

[vivaladav]

hey @Paul-Thexton, I just noticed that Qt Creator 4.5 is not creating target_wrapper.sh any more. Can you confirm this?

[Paul Thexton]

@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.

[karlheinzreichel]

Did you set your rpath dependencies with QMAKE_LFLAGS ?

e.g.

QMAKE_LFLAGS += '-Wl,-rpath,\'\$$ORIGIN/libs\''
QMAKE_LFLAGS += '-Wl,-rpath,\'$${QMAKE_LIBDIR_QT}\''

[Paul Thexton]

@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]

@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.

[Paul Thexton]

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 :)