Nov 29, 2015 Ubuntu 15 CMake Build Errors


Can’t build from source, cmake throws out errors:

CheckSymbolExists.c:(.text+0x16): undefined reference to `pthread_create'
CMakeFiles/cmTryCompileExec2162094804.dir/build.make:88: recipe for target 'cmTryCompileExec2162094804' failed
make[1]: Leaving directory '/CMakeFiles/CMakeTmp'
Makefile:118: recipe for target 'cmTryCompileExec2162094804/fast' failed
collect2: error: ld returned 1 exit status
make[1]: *** [cmTryCompileExec2162094804] Error 1
make: *** [cmTryCompileExec2162094804/fast] Error 2

File /CMakeFiles/CMakeTmp/CheckSymbolExists.c:
/* */
#include <pthread.h>

int main(int argc, char** argv)
#ifndef pthread_create
  return ((int*)(&pthread_create))[argc];
  return 0;

-- Configuring incomplete, errors occurred!

I have pthreads (I use it a lot)

libpthread-stubs0-dev is already the newest version.
libpthread-stubs0-dev set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 42 not upgraded.


hi @Cracker_Hax did you delete the cmakecache file?


This happened with a fresh clone.


Actually I am getting the same error.


collect2: error: ld returned 1 exit status
CMakeFiles/cmTryCompileExec2209125504.dir/build.make:88: recipe for target ‘cmTryCompileExec2209125504’ failed
make[1]: Leaving directory '/home/hifi/hifi/build/CMakeFiles/CMakeTmp’
Makefile:118: recipe for target ‘cmTryCompileExec2209125504/fast’ failed
make[1]: *** [cmTryCompileExec2209125504] Error 1
make: *** [cmTryCompileExec2209125504/fast] Error 2


I use Ubuntu 14.04 with my build server and it built fine last build 11 hours ago but I will try on an Ubuntu 15.04 server right now and see what it gives me.


I’m on an older Ubuntu but did a fresh checkout and am not seeing the pthread_create error…

Just as a sanity check have you tried linking something lately to pthread? A quick pass/fail one-liner for that is:

/bin/echo -e '#include <pthread.h>\nint main(int argc,char**) { if(argc<0)pthread_create(0,0,0,0); }'| g++ -x c++ - -lpthread

Also adding --debug-output to your cmake invocation might help reveal additional clues:

$ cmake .. --debug-output

EDIT: Actually, I was getting the error – but only if I look manually in my CMakeFiles/CMakeError.log does it show up and otherwise it seems completely benign (just some kind of cruft from cmake checks).

In my case to actually get through to a build I had to comment-out the cmake_policy line in cmake/externals/quazip/CMakeLists.txt:

cmake_policy(SET CMP0046 OLD)

… and after that everything was fine. Despite the pthread error still showing up in CMakeError.log.


I was getting

CMake Error at cmake/externals/quazip/CMakeLists.txt:7 (string):
  string sub-command REPLACE requires at least four arguments.

Which, for normal builders like us, we don’t have QT_CMAKE_PREFIX_PATH set, so to fix it, I went into the hifi folder and ran:

nano +7 cmake/externals/quazip/CMakeLists.txt

then replaced

with this line of code that actually checks if its set or not


I don’t feel like doing a PR on this right now but hopefully one of you guys can get this fixed from:


Yeah that worked. Thanks Coal!


Agreed thanks @Coal!


Welcome @Cracker_Hax and @KevinMThomas! Its now fixed in the repo so all is good now.


Hi @Coal are you experiencing the same error I am when making the assignment-client under 15.04 as of this morning? I deleted the CMake cache and have the latest repo however still getting an error in the make.


In file included from /usr/include/x86_64-linux-gnu/qt5/QtGui/QOpenGLContext:1:0,
from /home/hifi/hifi/libraries/gl/src/gl/OffscreenQmlSurface.cpp:20:
/usr/include/x86_64-linux-gnu/qt5/QtGui/qopenglcontext.h:49:2: warning: #warning qopenglfunctions.h is not compatible with GLEW, GLEW defines will be undefined [-Wcpp]
#warning qopenglfunctions.h is not compatible with GLEW, GLEW defines will be undefined
/usr/include/x86_64-linux-gnu/qt5/QtGui/qopenglcontext.h:50:2: warning: #warning To use GLEW with Qt, do not include <qopengl.h> or after glew.h [-Wcpp]
#warning To use GLEW with Qt, do not include <qopengl.h> or after glew.h
/home/hifi/hifi/libraries/gl/src/gl/OffscreenQmlSurface.cpp: In constructor ‘OffscreenQmlRenderer::OffscreenQmlRenderer(OffscreenQmlSurface*, QOpenGLContext*)’:
/home/hifi/hifi/libraries/gl/src/gl/OffscreenQmlSurface.cpp:86:25: error: ‘class QMyQuickRenderControl’ has no member named ‘prepareThread’
libraries/gl/CMakeFiles/gl.dir/build.make:146: recipe for target ‘libraries/gl/CMakeFiles/gl.dir/src/gl/OffscreenQmlSurface.cpp.o’ failed
make[3]: *** [libraries/gl/CMakeFiles/gl.dir/src/gl/OffscreenQmlSurface.cpp.o] Error 1
CMakeFiles/Makefile2:930: recipe for target ‘libraries/gl/CMakeFiles/gl.dir/all’ failed
make[2]: *** [libraries/gl/CMakeFiles/gl.dir/all] Error 2
CMakeFiles/Makefile2:143: recipe for target ‘assignment-client/CMakeFiles/assignment-client.dir/rule’ failed
make[1]: *** [assignment-client/CMakeFiles/assignment-client.dir/rule] Error 2
Makefile:110: recipe for target ‘assignment-client’ failed
make: *** [assignment-client] Error 2


Yup - linux server components compile has been fail since;

Maybe @Jherico has some thoughts. Unlike all the breaking of linux compiles over last 15 months I have yet to figure out a workaround/fix for this one.


Glad I didn’t update.


Well, in my case I run an automated Jenkins build box that compiles and creates a docker image for running stack. It’s a toy I’ve been running since sometime last year and, since it’s not mission critical I don’t get my BP up when it breaks. There’s a lot more currently broken with the past few days flurry of commits than the linux stack build that’s probably a lot more important.


i think that’s a method introduced in Qt 5.5…

jherico doesn’t usually throw that kind of curve ball without a heads-up so my best guess is you guys are catching things mid-flight / WIP or there was an inadvertent merge.

ps: how long does it take you guys to a fresh build (when it works)? incremental builds are snappy, but i’ve also been tinkering with distcc and with a cluster of three machines it still seems to take over 10 minutes to do a clean build so i’m curious what’s considered typical


Well I missed the memo in readme on github - QT5.5.1 is indeed now required which I remember seeing ages ago as a would be happening thing then, regrettably now, forgot. Now the joy of figuring out which arcane gods to pray to for building a QT5.5.1 on Linux that has the right set of bits for HF.


Having the same issue. I tried but gave up and now @thoys is working on my cloud trying to compile Qt 5.5 as the run method did not work because I was unable to init a DISPLAY because it is on a cloud and simply a term window.


Yup @KevinMThomas - this is going to get nasty. Somewhere, I suspect, HF still has a build box for doing all this on Linux, it would be nice, if for once they’d share some of that information. Someone once found a repo for HF’s Ubuntu 14.04 based Linux config, but, I can’t remember who or where it was. I’m rebuilding docker containers now basing on Ubuntu 15.10 with compiled QT5.5.1, but, that’s of little help to those trying to run on droplets directly or, worse yet, trying to run Interface.