Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CMake build doesn't check for pthreads #103

Closed
diizzyy opened this issue Apr 20, 2022 · 6 comments · Fixed by #110
Closed

CMake build doesn't check for pthreads #103

diizzyy opened this issue Apr 20, 2022 · 6 comments · Fixed by #110

Comments

@diizzyy
Copy link
Contributor

diizzyy commented Apr 20, 2022

Currently there's no check for pthreads which would be nice on UNIX systems at least

@carenas
Copy link
Contributor

carenas commented Apr 20, 2022

this is a "feature" of sorts, since it might block you from building with cmake where autotools is available and since that is the preferred way (as documented in the README)

any particular reason you wouldn't be able to use autotools instead in your environment?, cmake is mainly used in Windows AFAIK where this pthread checking is a non issue.

@diizzyy
Copy link
Contributor Author

diizzyy commented Apr 20, 2022

Sorry, I can't find any wording about preference so one would expect both to perform the same. While I don't have any issues with Autotools it would be nice if both worked as expected.

@jwsblokland
Copy link

@diizzyy It should be straightforward to add the additional package to CMake configuration. However, as far as I can tell none of the defined targets require pthreads but maybe I am missing something. Could you tell me which compiler and cmake options you have used?

@diizzyy
Copy link
Contributor Author

diizzyy commented Apr 21, 2022

@jwsblokland
The only occurrence I seem to find is in src/sljit so you might be correct that it's not needed/used

@carenas
Copy link
Contributor

carenas commented Apr 21, 2022

it's not needed/used

It is definitely needed/used (if jit is enabled in UNIX and as described in the README), but most linkers will be happy to build a DSO with unresolved symbols and those might even work if those symbols are resolved eventually when loading a binary.

with pthread being commonly embedded as part of the libc, and most systems dynamically solving those symbols at load time (except from memory in AIX or Cygwin) then I can see how it would not be easy to notice but that doesn't mean autotools shouldn't be still preferred.

carenas added a commit to carenas/pcre2 that referenced this issue Apr 22, 2022
PhilipHazel pushed a commit that referenced this issue Apr 22, 2022
@diizzyy
Copy link
Contributor Author

diizzyy commented Apr 22, 2022

Thanks! :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants