cmake 3.5.1 no longer passes -soname to linker reliably

Bug #1564571 reported by Michał Sawicz on 2016-03-31
This bug affects 1 person
Affects Status Importance Assigned to Milestone
cmake (Ubuntu)

Bug Description

I'm not exactly sure what's going on here, but cmake 3.5 caused our tests to fail, I've tracked it down to this difference in linking:

For whatever reason the below isn't passed any more,

> -Wl,-soname,

which results in our tests failing to find symbols:

> QObject::connect: signal not found in DirectionalDragArea

Re-running the linker command with the missing options makes it all work again.

You can even see there are two spaces where the -Wl,-soname option should be.

FWIW, the CMakeLists.txt in question is:

I suppose this should be SHARED and not MODULE if we want to link to it, but that doesn't change anything actually.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: cmake 3.5.1-1ubuntu1
ProcVersionSignature: Ubuntu 4.4.0-16.32-generic 4.4.6
Uname: Linux 4.4.0-16-generic x86_64
ApportVersion: 2.20-0ubuntu3
Architecture: amd64
CurrentDesktop: Unity
Date: Thu Mar 31 20:25:08 2016
SourcePackage: cmake
UpgradeStatus: No upgrade log present (probably fresh install)

Michał Sawicz (saviq) wrote :

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

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
  OUTPUT_NAME UbuntuGesturesQml
  VERSION 0.0.0

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


Changed in cmake (Ubuntu):
importance: Undecided → Medium
status: New → Incomplete

do you override this file?

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

Michał Sawicz (saviq) wrote :

to reproduce:

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


Michał Sawicz (saviq) wrote :

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

Michał Sawicz (saviq) wrote :

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

Download full text (4.1 KiB)

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, -o 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/ /usr/lib/x86_64-linux-gnu/ /usr/lib/x86_64-linux-gnu/ /usr/lib/x86_64-linux-gnu/ /usr/lib/x86_64-linux-gnu/

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, -o 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/ /usr/lib/x86_64-linux-gnu/ /usr/lib/x86_64-linux-gnu/ /usr/lib/x86_64-linux-gnu/ /usr/lib/x86_64-linux-gnu/ /usr/lib/x86_64-linux-gnu/ -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 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...


Michał Sawicz (saviq) wrote :

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

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 as installed from and

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 file, that hardcodes local paths.

maybe strace might help here to find the issue.

Launchpad Janitor (janitor) wrote :

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

Changed in cmake (Ubuntu):
status: Incomplete → Expired
Changed in cmake (Ubuntu):
status: Expired → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers