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

[MacOS CI] Issue with cmath, boost and Apple #3722

Closed
kunaltyagi opened this issue Mar 7, 2020 · 16 comments · Fixed by #3736
Closed

[MacOS CI] Issue with cmath, boost and Apple #3722

kunaltyagi opened this issue Mar 7, 2020 · 16 comments · Fixed by #3736
Labels
kind: compile error Type of issue kind: todo Type of issue module: ci needs: feedback Specify why not closed/merged yet

Comments

@kunaltyagi
Copy link
Member

Your Environment

  • Operating System and version: MacOS 10.14 (CI)
  • Compiler: AppleClang 11
  • PCL Version: HEAD

Context

MacOS CI is red

Current Behavior

/usr/local/include/boost/math/special_functions/fpclassify.hpp:552:17: error: no member named 'isnan' in namespace 'std'; did you mean simply 'isnan'?
        return (std::isnan)(x);
                ^~~~~
/usr/local/include/boost/math/special_functions/math_fwd.hpp:885:9: note: 'isnan' declared here
   bool isnan BOOST_NO_MACRO_EXPAND(T t);
        ^
@SergioRAgostinho
Copy link
Member

Probably the same as #2601

@kunaltyagi
Copy link
Member Author

Possibly. Apple loves breaking non XCode tool-chain. We'll most likely have to wait for an update?

@SergioRAgostinho
Copy link
Member

Any idea of where to report this? It feels like something that the team from Azure pipelines should be aware. They have too many azure-pipelines-* repos :/

@shrijitsingh99
Copy link
Contributor

shrijitsingh99 commented Mar 11, 2020

Any idea of where to report this? It feels like something that the team from Azure pipelines should be aware. They have too many azure-pipelines-* repos :/

An issue can be created at virtual-environments since azure-pipelines-image-generation has been replaced.

Possibly. Apple loves breaking non XCode tool-chain. We'll most likely have to wait for an update?

Can we not switch to using the Xcode bundled toolchain instead of being dependent on updates to the VM-image?
I made a quick demo (CI Status).

@kunaltyagi
Copy link
Member Author

switch to using the Xcode bundled toolchain

That's a possibility and IMO probably better for MacOS. If your build succeeds, please go ahead with a PR 😄

@shrijitsingh99
Copy link
Contributor

So I did some more testing and only the Xcode toolchain with macOS SDK 10.15 works, rest all configurations are broken and are not working.
So if we switch to the default Xcode version and use the latest SDK on the VM, future builds should not break.

@kunaltyagi
Copy link
Member Author

How is your CI using XCode? XCode.app isn't available on the PR I tried to emulate you

@shrijitsingh99
Copy link
Contributor

c is small in Xcode.
It should be XCODE_APP_PATH=`/Applications/Xcode.app', you cant use XCODE_APP_PATH=`ls -d /Applications/XCode*since there are multiple versions of Xcode available.

@SergioRAgostinho
Copy link
Member

Side note: Ci appears to be running green again for OSX builds.

@kunaltyagi
Copy link
Member Author

Where? #3732 just ended on red

@kunaltyagi
Copy link
Member Author

@shrijitsingh99 Thanks a lot. This seems to have done the trick. Also, I added Catalina CI 😄 (1 more hour on 1 pipeline)

@SergioRAgostinho
Copy link
Member

Here #3731, but it was false alarm. The entire CI ran in 14 minutes. :)

@kunaltyagi
Copy link
Member Author

kunaltyagi commented Mar 12, 2020

The entire CI ran in 14 minutes

What wouldn't I give to have a build time of 14 minutes....

It doesn't build common or anything, and doesn't throw an error either. Might be a bug hiding in CMake.

CMake config log since CI deletes old logs
-- The C compiler identification is AppleClang 11.0.0.11000033
-- The CXX compiler identification is AppleClang 11.0.0.11000033
-- Check for working C compiler: /Applications/Xcode_11.3.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
-- Check for working C compiler: /Applications/Xcode_11.3.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -- works
--   outofcore: Requires visualization.
--   examples: Code examples are disabled by default.
--   people: Requires octree.
--   simulation: Disabled by default.
--   tests_2d: Requires filters.
--   tests_common: Requires common.
--   tests_features: Requires 2d.
--   tests_filters: Requires octree.
--   tests_geometry: Requires common.
--   tests_io: Requires octree.
--   tests_kdtree: Requires common.
--   tests_keypoints: Requires filters.
--   tests_people: Requires octree.
--   tests_octree: Requires common.
--   tests_outofcore: Requires visualization.
--   tests_recognition: Requires ml.
--   tests_registration: Requires filters.
--   tests_search: Requires octree.
--   tests_surface: Requires octree.
--   tests_segmentation: Requires ml.
--   tests_sample_consensus: Requires search.
--   tests_visualization: Requires octree.
--   tools: Disabled manually.
-- Configuring done
-- Generating done
CMake Warning:
  Manually-specified variables were not used by the project:

    BUILD_apps_3d_rec_framework
    BUILD_apps_cloud_composer
    BUILD_apps_in_hand_scanner
    BUILD_apps_modeler
    BUILD_apps_point_cloud_editor

@shrijitsingh99
Copy link
Contributor

The entire CI ran in 14 minutes

What wouldn't I give to have a build time of 14 minutes....

It doesn't build common or anything, and doesn't throw an error either. Might be a bug hiding in CMake.

CMake config log since CI deletes old logs

Yeah, it could not find boost dependency. Shouldn't we have something in the CI to catch such types of error i.e. if it just skips building packages for some reason? Cause it gives wrong indication that the CI was successful even though it wasn't.

@kunaltyagi
Copy link
Member Author

Shouldn't we have something in the CI to catch such types of error

Should: yes, but maybe it's compromised or doesn't exist. Maybe FindBoost is quiet or some other bug is present in CMake

@shrijitsingh99
Copy link
Contributor

shrijitsingh99 commented Mar 13, 2020

Shouldn't we have something in the CI to catch such types of error

Should: yes, but maybe it's compromised or doesn't exist. Maybe FindBoost is quiet or some other bug is present in CMake

Yeah so to catch all of this. We could have a script run at the end of the tests to see if actually all the modules listed were actually built and fail if any module was skipped.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind: compile error Type of issue kind: todo Type of issue module: ci needs: feedback Specify why not closed/merged yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants