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

Fix library error for Github Actions for Clang C++20 #784

Conversation

dhebbeker
Copy link
Contributor

@dhebbeker dhebbeker commented Nov 9, 2023

I observed that the GitHub Actions fail. Through analysis since which commit the build fails, I to applied a fix to make the workflow running successfully again.

I am not sure why this fixes the workflow. 🤷 I merely re-applied f208eb4. I think that change accidentally got lost in the merge 95c7f44.

(cherry picked from commit f208eb4)

The line got lost in 95c7f44.
Copy link

Review changes with SemanticDiff

@dhebbeker dhebbeker marked this pull request as ready for review November 9, 2023 11:09
@jwellbelove jwellbelove changed the base branch from master to pull-request/#784-Fix-library-error-for-Github-Actions-for-Clang-C++20 November 14, 2023 18:37
@jwellbelove jwellbelove merged commit 772db03 into ETLCPP:pull-request/#784-Fix-library-error-for-Github-Actions-for-Clang-C++20 Nov 14, 2023
58 checks passed
@dhebbeker dhebbeker deleted the feature/try-to-fix-GitHub-Actions-for-clang-C++20 branch November 14, 2023 18:48
@jwellbelove
Copy link
Contributor

Unfortunately the changes cause clang compilation to fail on my local CI scripts.

-- Looking for C++ include pthread.h
-- Looking for C++ include pthread.h - not found
CMake Error at /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
  Could NOT find Threads (missing: Threads_FOUND)
Call Stack (most recent call first):
  /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
  /usr/share/cmake-3.22/Modules/FindThreads.cmake:238 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  UnitTest++/CMakeLists.txt:45 (find_package)

@dhebbeker
Copy link
Contributor Author

Sorry, I wouldn't know how to resolve that. From a quick research it seems that this error message may be a symptom for anything else (i.e. qcoro/qcoro#22 (comment)).

@jwellbelove
Copy link
Contributor

If I comment out the line set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -stdlib=libc++") then everything is fine.

I'm running
Ubuntu 22.04
Clang 15.0.7

@dhebbeker
Copy link
Contributor Author

Somehow, without that line it does not work on the GitHub runner. I guess this is related to to workaround you applied in 95c7f44#diff-24e820d109223f3d266ca9b6edc626ef33158ab4140adec4c207b7e15bbbbc33R20-R25 and #777 (comment) respectively actions/runner-images#8659.

Would it help if you would update your local clang to version 17? At least that seams to be the workaround applied for the runner...

@jwellbelove
Copy link
Contributor

I was hoping that Github would sort the issue out very soon, so that workarounds wouldn't have to be applied.

Unfortunately clang-17 doesn't seem to be available for Ubuntu 22.04 (E: Unable to locate package clang-17). (I'm not a Linux expert)

@jwellbelove
Copy link
Contributor

After a web search I tried adding find_package(Threads), but that just causes all STL header includes to fail.

@dhebbeker
Copy link
Contributor Author

dhebbeker commented Nov 15, 2023 via email

@jwellbelove
Copy link
Contributor

It looks like the Github Actions is using Clang 14, whilst I am using Clang 15.

@dhebbeker
Copy link
Contributor Author

dhebbeker commented Nov 15, 2023 via email

@jwellbelove
Copy link
Contributor

"But the script .github/workflows/clang.yml installs clang v17 isn't it?"

The fix didn't work. The compiler was not updated. clang identified as v14,

@dhebbeker
Copy link
Contributor Author

🤔 I have been checking the build logs.

221cc42 has been used by the GitHub Actions. That commit does contain the temporary fix. The run for Clang C++20 Linux - STL (ubuntu-22.04) did fail. After a presumably successful installation of clang 17, the compiler called by the build process identifies itself as clang 14.

I think a step in the installation process is missing. Or the workflow should instruct to use that specific clang version. This has been mentioned in actions/runner-images#8659 (comment)

I can not reproduce the exact workaround on my machine as my Ubuntu version is outdated. But maybe you can try this for your local installation:

After the manual installation of clang 17 (using llvm.sh), instruct the build process to specifically use that clang version. The change for the GitHub workflow should be like follows:

-        export CC=clang
-        export CXX=clang++
+        export CC=clang-17
+        export CXX=clang++-17

Or select the default version to be used on your machine:

sudo update-alternatives --config clang
sudo update-alternatives --config clang++

It would be good if both, the hosted workflows and your local installation would be running without errors.

A workaround for the GitHub Action would be to remove GCC13 (like sourcemeta/jsontoolkit@caa66fb) or to use a different runner like actions/runner-images#8659 (comment).

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 this pull request may close these issues.

2 participants