Open matteo-agnelli opened 7 years ago
It isn't a known issue but I'm not really surprised since I never really tested the package with static linking. In fact, because of the Qt licensing policy I never really tried static linking with Qt (it would force my released work to be LGPL). So my first question before thinking too far is : do you really want to statically link, knowing your final work will have to be licensed either as GPL or as LGPL.
Now, if I tried to to understand, I would guess that system dependencies are not an issue when dynamically linking since they are referenced in the dynamic libs. But when statically linking, they are not known and must be specified at build time. It could be interesting to ldd
the .so
files to confirm.
I'm surprised the Qt-provided CMake files don't manage this situation. The Qt::Core target should have a dependency with those system libraries.
It would be necessary to run tests to really understand. Could you open a PR containing your current modifications of the test_package?
Hey Olivier!
First of all thanks for the great work :) I've been using this conan package to develop with Qt (v5.8.0). Everything works perfectly if I build shared libs. However, if I enable the option '-o Qt:shared=False', the test_package fails.
There seems to be a linker issue for the test applications (helloworld1/2, hellogui) against several system libraries (libz, libpthread, libglib-2.0, ...) and other libs (libqtpcre, ...). If I hardcode those in the target_link_libraries in the cmake file for the helloworld1/2 everything works fine. Still having issues with the hellogui executable though.
Is this a known issue? Should the conan package export those libraries as well so that the ${CONAN_LIBS} point to those or am I doing something wrong? I'm guessing that if the test_package fails I will probably have the same issue for my application as well...
Thanks a lot! Matteo