cmake 3.5.1 no longer passes -soname to linker reliably

hi, can you please upload a reduced tarball somewhere with a minimal set of files to reproduce the issue?
thanks!

Hi, I can't download the sources because of bad connection, however:

SHARED instead of MODULE is already part of the fix.

if it doesn't work you can do something like:
set_target_properties(UbuntuGesturesQml PROPERTIES
  ENABLE_EXPORTS On
  OUTPUT_NAME UbuntuGesturesQml
  VERSION 0.0.0
  SOVERSION 0
  )

with the appropriate values and see if it fixes the issue.

thanks

do you override this file?
https://sources.debian.net/src/cmake/3.5.1-1/Modules/Platform/Linux.cmake/

in particular this variable set(CMAKE_SHARED_LIBRARY_SONAME_C_FLAG "-Wl,-soname,")

to reproduce:

tar xxf unity8-cmakebug.tar.xz
cd unity8-cmakebug
mkdir build
cd build
cmake ..
make
make testFloatingFlickable # works
cmake . -DUNITY_PLUGINPATH=/usr/lib/x86_64-linux-gnu/unity8/qml
make testFloatingFlickable # broken

¿?

No, I don't override anything - and I tried setting the properties as you suggested, that didn't help.

Sorry, I forgot to remove the coverage part from the main CMakeLists.txt - you can just drop it, it's irrelevant. Also the bits calling PKG_CONFIG_EXECUTABLE.

In any case, you would need qtbase5-dev, qtdeclarative5-dev, qtbase5-private-dev, qtdeclarative5-private-dev, libxi-dev, qtdeclarative5-ubuntu-ui-toolkit-plugin, unity8-private to build/run this, so your connection issues might make this tricky...

I did download the unity8 branch, dpkg-buildpackaged it, added all the dependencies, changed MODULE to SHARED.

I can't reproduce in a clean xenial environment (pbuilder)

/usr/bin/c++ -fPIC -fvisibility=hidden -std=c++11 -fno-permissive -pedantic -Wall -Wextra -Wl,-z,defs -shared -Wl,-soname,libUbuntuGestures.so -o libUbuntuGestures.so CMakeFiles/UbuntuGestures.dir/CandidateInactivityTimer.cpp.o CMakeFiles/UbuntuGestures.dir/DebugHelpers.cpp.o CMakeFiles/UbuntuGestures.dir/Timer.cpp.o CMakeFiles/UbuntuGestures.dir/TimeSource.cpp.o CMakeFiles/UbuntuGestures.dir/TouchOwnershipEvent.cpp.o CMakeFiles/UbuntuGestures.dir/TouchRegistry.cpp.o CMakeFiles/UbuntuGestures.dir/UnownedTouchEvent.cpp.o CMakeFiles/UbuntuGestures.dir/UbuntuGestures_automoc.cpp.o /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5.5.1 /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5.5.1 /usr/lib/x86_64-linux-gnu/libQt5Network.so.5.5.1 /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.5.1 /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1

I see the stuff injected correctly.
also with your tarball
/usr/bin/c++ -fPIC -fvisibility=hidden -std=c++11 -fno-permissive -pedantic -Wall -Wextra -Wl,-z,defs -shared -Wl,-soname,libUbuntuGesturesQml.so -o libUbuntuGesturesQml.so CMakeFiles/UbuntuGesturesQml.dir/plugin.cpp.o CMakeFiles/UbuntuGesturesQml.dir/AxisVelocityCalculator.cpp.o CMakeFiles/UbuntuGesturesQml.dir/Damper.cpp.o CMakeFiles/UbuntuGesturesQml.dir/Direction.cpp.o CMakeFiles/UbuntuGesturesQml.dir/DirectionalDragArea.cpp.o CMakeFiles/UbuntuGesturesQml.dir/FloatingFlickable.cpp.o CMakeFiles/UbuntuGesturesQml.dir/PressedOutsideNotifier.cpp.o CMakeFiles/UbuntuGesturesQml.dir/TouchDispatcher.cpp.o CMakeFiles/UbuntuGesturesQml.dir/TouchGate.cpp.o CMakeFiles/UbuntuGesturesQml.dir/TouchGestureArea.cpp.o CMakeFiles/UbuntuGesturesQml.dir/UbuntuGesturesQml_automoc.cpp.o ../../../libs/UbuntuGestures/libUbuntuGestures.so /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5.5.1 /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5.5.1 /usr/lib/x86_64-linux-gnu/libQt5Network.so.5.5.1 /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.5.1 /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1 -Wl,-rpath,/unity8-cmakebug/build/libs/UbuntuGestures:

(I had to install also pkg-config libsystemsettings-dev libunity-api-dev)

actually as you said before:
 cmake ..
make
make testFloatingFlickable # works
cmake . -DUNITY_PLUGINPATH=/usr/lib/x86_64-linux-gnu/unity8/qml
make testFloatingFlickable # broken

the second make is just changing an LD_LIBRARY_PATH variable, no rebuilds are actually performed.
You are trying to LD_PRELOAD a system qml library instead of the just built one.
Not sure what is wrong, maybe an ABI incompatibility or something else, but it seems to have nothing to do with cmake to me.

test good.
VERBOSE=1 make testFloatingFlickable
cd /unity8-cmakebug/build/tests/plugins/Ubuntu/Gestures && env QML2_IMPORT_PATH=/unity8-cmakebug/build/tests/utils/modules:/unity8-cmakebug/build/plugins LD_LIBRARY_PATH=/unity8-cmakebug/build/plugins/Ubuntu/Gestures UNITY_TESTING=1 LANGUAGE=C LC_ALL=C.UTF-8 LD_LIBRARY_PATH=/unity8-cmakebug/build/plugins/Ubuntu/Gestures /unity8-cmakebug/build/tests/plugins/Ubuntu/Gestures/FloatingFlickableTestExec -o /unity8-cmak...

OK then, my environment must've gotten weird by the time I've noticed the -soname missing.

It is a fact, though, that new cmake caused something to change since this was working before. I can't currently say what that is.

And it's not a change in how the test is invoked - below's a diff between the last passing and failing runs (http://autopkgtest.ubuntu.com/packages/u/unity8/xenial/amd64/) - 3.5 did add another LD_LIBRARY_PATH (I suppose that's an issue in our cmake module), but they actually both have the same value, and I've verified this doesn't even matter anyway, since the link is done via a relative path, so LD_LIBRARY_PATH doesn't really matter at all...
http://pastebin.ubuntu.com/15575765/

It's not about the library path after all, but rather about QML2_IMPORT_PATH - it's fine if it's using the locally built one - fails if using the installed one.

FWIW we *did* want to use the installed ones in autopkgtest (a local one shouldn't even be built - our issue).

As for SONAME being set in the .so - I believe the problem only appears after you've packaged the file and it was stripped. And SHARED or MODULE doesn't seem to make a difference now.

I've now compared the output from objdump for libUbuntuGestures.so as installed from https://launchpad.net/ubuntu/+source/unity8/8.12+16.04.20160323.2-0ubuntu1 and https://launchpad.net/ubuntu/+source/unity8/8.12+16.04.20160330-0ubuntu1

And here's the twist: the previous one, built with cmake 3.2, does have the SONAME, while the new one, built with cmake 3.5.1, does not. So I think this might actually be fallout of both building the packages *and* using cmake 3.5.1 during testing...

TBH I'm quite lost with this. Am looking more into what's happening.

In the mean time, we're skipping this test to unblock things.

I don't understand, locally make test works, when the library is outside the build directory it doesn't.

I suspect the culprit is your path.h.in file, that hardcodes local paths.

maybe strace might help here to find the issue.

[Expired for cmake (Ubuntu) because there has been no activity for 60 days.]