Fixed cmake 3.16.0 incompatibility.

[marcfehling]

Fixes #9116.

I chose with the most pragmatic way of resolving this issue: By simply imitating what CMake did in previous versions.

There may be other ways of fixing this, e.g. by considering pthreads at the TARGET_LINK_LIBRARIES stage via

LIST(APPEND THREADS_LIBRARIES ${CMAKE_THREAD_LIBS_INIT})

However right now, we just add a linker flag, and I didn't want to overhaul the whole process without being able to assess the consequences.

[tamiko]

see above

comment didn't post

[tamiko]

Would you mind changing this to REGEX_REPLACE a match ^pthreads$ with -lpthreads? That way you don't need the version check and we avoid accidentally producing -l-lpthreads the moment something changes in a future CMake version.

[tamiko]

mhm What about you just check for your expectation then?

IF("${CMAKE_THREAD_LIBS_INIT}" MATCHES "^pthread$")
  STRING(PREPEND CMAKE_THREAD_LIBS_INIT "-l")
ENDIF()

[marcfehling]

I understand your concerns and like your suggestion. Adapted changes correspondingly.

[marcfehling]

But on the other hand, FindThreads is able to find other libraries as well which are also affected by this change. Would it make more sense to check whether CMAKE_THREAD_LIBS_INIT starts with -l and prepend it whenever it's missing?

[marcfehling]

Unfortunately, negative lookahead is not available in cmake, so we cannot ask for something like ^(?!-l).*$. Instead, I came up with something different. You'll find my idea in a separate commit.

You may decide which one we should prefer and which one we should drop :)

[tamiko]

/rebuild

[masterleinad]

Somewhat in line with https://gitlab.kitware.com/cmake/cmake/issues/19823, it seems that CMAKE_THREAD_LIBS_INIT is empty for Mac OS X resulting in a lonely -l in the linker flags.

[marcfehling]

Added a check for emptiness for that particular variable. Hopefully Mac OS X will be happy with that.

[tamiko]

Sorry for letting you jump through so many hoops. Would you mind testing my suggestion to simply check for ^pthread$?

[marcfehling]

Testers are happy!

@tamiko I gave your proposal a try on my machine as well and it did what expected. However, since CMAKE_THREAD_LIBS_INIT may have values different from pthread, i.e. posix, pthreads and thread at least, I would prefer the current more versatile variant.

[tamiko]

As a general remark: We are currently using CMAKE_THREAD_LIBS_INIT as a linker flag which is probably not the intended use here. So if this breaks in the future, we should revisit the whole thread library handling again.

[marcfehling]

As a general remark: We are currently using CMAKE_THREAD_LIBS_INIT as a linker flag which is probably not the intended use here. So if this breaks in the future, we should revisit the whole thread library handling again.

Exactly, we should hand CMAKE_THREAD_LIBS_INIT over during the TARGET_LINK_LIBRARIES stage. But this hotfix does its job for now...