ld error

[rezso]

Compiling https://github.com/Secretchronicles/TSC/commit/79a2163a0f75b84d768865c6c9c3154d145a5879 fails:

[100%] Linking CXX executable tsc /usr/bin/ld: CMakeFiles/tsc.dir/src/scripting/objects/misc/mrb_timer.cpp.o: undefined reference to symbol 'pthread_condattr_setclock@@GLIBC_2.3.3' /lib/libpthread.so.0: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status

[refi64]

Have you built TSC before? If you have, first try a clean build.

Outside of that, this is probably an issue with the library linking order, though I use Ninja too and haven't had any problems. I'll try a clean build again, though, and see how it goes...

[rezso]

This is a clean build, with cmake 3.11.2 and make.

The generated build.make file contains $(CMAKE_COMMAND) -E cmake_link_script CMakeFiles/tsc.dir/link.txt --verbose=$(VERBOSE), but I cannot found libpthread in the CMakeFiles/tsc.dir/link.txt.

[Quintus]

TSC does not use pthreads directly, nor even C++11 threads (because legacy code). It uses boost::thread and as such there's this line in CMakeLists.txt:

find_package(Boost 1.50.0 COMPONENTS filesystem chrono thread system REQUIRED)

Note it expressly searches for the boost::thread library. Please first check if you have that one installed completely, with development headers. The find_package() call should detect all subdependencies of boost::thread as well, and that should include the dependency on pthreads; also check if pthreads is installed with development headers.

What OS do you use, and what version of CMake are you using? It's certainly possible to work around your problem by adding yet another find_package() call to find pthreads, but since searching for boost::thread should properly detect pthreads as well I'm not going to do that without further information. There might be a bug in your CMake's FindBoost module.

The mentioned commit does compile on my system (Debian 9).

[Quintus]

Also, please give the full build log of a clean build (including the cmake run).

[rezso]

Here is the full build log: https://gist.github.com/rezso/a9d9879c741f16c43a2fc77020838133

[rezso]

cmake version: 3.11.2

[refi64]

What's is UHUBUILD? Whatever it is, it could he screwing with your build environment, e.g. a mismatch between libc, Boost.Threads, and CMake, or similar. Can you try building TSC normally instead?

[rezso]

UHUBUILD don't screwing anything. This is the build system of my distro, and I made more than 4900 packages with it, without any problems. Here is the source, if interested: https://github.com/uhulinux/uhubuild

And a note: I simply added pthread to target_link_libraries() in CMakeLists.txt, so I can build TSC completely. But the cmake why not adds pthread to dependencies in the links.txt? This is the one question.

[refi64]

It really shouldn't have to. Depending on Boost.Threads is supposed to bring in pthreads unless either 1) the FindBoost module isn't working or 2) uhubuild is messing with the environment a bit.

Again, this leads to me to believe that uhubuild's chroot is somehow accidentally interfering with things, since that's the only major thing it seems is different. Can you at least try building it normally and see if it works?

[Quintus]

I agree with kirbyfan; try building it the traditional way at least once. We don't know your tool, and we need to exclude it as the source of the problem.

But the cmake why not adds pthread to dependencies in the links.txt? This is the one question.

Because it's a subdependency of boost::thread and the FindBoost.cmake module is supposed to find it. What is irratating, is that according to your build log it does find it. Also, boost::thread is not using pthreads on all platforms I think (notably Win32).

You're appearently using cutting-edge versions of all software, like GCC 8.1.0 and CMake cmake 3.11.2. Probably the rest of all libraries involved is as recent as well. Maybe CMake's FindBoost module has seen a regression bug. To determine that, you'll need to set up a micro C++ project using cmake that uses boost::thread and see if the error appears there as well.

I've tried building with your cmake option set, and it did compile fine again on my system.

[Quintus]

Btw. there's no need to run make install if you fear to pollute your system. The ld error happens at the link step before installation.

[rezso]

Another build of the code, with older stuffs: https://gist.github.com/rezso/18381d6c2acf6c8b7df3391851dee9fa cmake version: 3.10.1 Adding pthread to target_link_libraries not needed. I think, my previous build issue caused by newer cmake, or any newer dependency (boost, ld, anything).

[refi64]

Well, I apologize for blaming uhubuild. I can reproduce this with GCC 8.1.1 and CMake 3.11.3. I'll do some research into it and report back!

[refi64]

Hmm, I can also reproduce it with Clang 6 and LLD. This has got to be a CMake bug...

I can see in the Ninja build files that pthread is nowhere to be found. In addition, I can't find it anywhere in CMakeCache.txt.