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

clang16 compatibility under C++17 #92

Closed
weberse2 opened this issue Mar 6, 2023 · 6 comments
Closed

clang16 compatibility under C++17 #92

weberse2 opened this issue Mar 6, 2023 · 6 comments

Comments

@weberse2
Copy link

weberse2 commented Mar 6, 2023

CRAN has now started to test using clang 16 (a beta version) in C++17 mode for any C++ code on CRAN.

boost does not support clang 16... and there are issues due to the actual removal of pre-C++17 language features which have been removed by the C++17 standard. In the past compilers seemingly avoided to really remove language features even if put into C++17 mode, but clang 16 pulls the trigger now.

This leads to all rstan derived package to run into compile problems coming from the used phoenix headers. The compile issues can be resolved with these fixes as proposed by Prof Ripley:

in src/Makevars[.win] 
PKG_CPPFLAGS = -D_HAS_AUTO_PTR_ETC=0

or one can add

#if __cplusplus >= 201703L
# define _HAS_AUTO_PTR_ETC 0
#endif

If it is possible to address the matter in BH directly, then that would be great.

@eddelbuettel
Copy link
Owner

Thanks for the heads-up, I had actually not yet seen clang16 reports.

Thanks also for sharing the fix suggested by Brian Ripley.

It is somewhat involved to release BH which is why I switched a few years ago to annual releases. Before making such a change I would have test it against all reverse-dependencies. Moreover there isn't really common configuration file for all of Boost (that I am aware of). So I am leaning towards asking the affected libraries to make this change, if at all possible. The local src/Makevars{,win} seems like right place. Do you think you live with that?

@weberse2
Copy link
Author

weberse2 commented Mar 6, 2023

Bumping BH must be quite some work to do, I see. For rstan dependent R packages which use rstantools the situation should be resolved once the next update is posted to CRAN.

As the fix is quite simple it is fair to ask for the Makevars solution. For the record if anyone hits this, a great way to test if things worked is by way of testing things with the docker image found here:

https://hub.docker.com/u/rhub

There you find a rhub/clang16 image as kindly pointed out by Uwe Ligges to me.

Then maybe keep this issue here open until the next to be released BH will contain either a new boost supporting clang16 under C++17? Another way to address this is to have some doc around where people find this piece of information (which could be just this issue being still open here)?

@eddelbuettel
Copy link
Owner

For the record I am also a fan of https://apt.llvm.org/ -- an apt repo to make installing clang version easy. I have use that in containers, you can also use it for CI such as GitHub Actions. If you search at GitHub you probably see some yaml files using it.

@eddelbuettel
Copy link
Owner

BH 1.84.0-0 is now at CRAN (after a pre-release made in December). Can you check if this is still an issue?

@weberse2
Copy link
Author

rstan moved away from using a phoenix based parser and as such the problem with the Phoenix library is not any longer an issue. Not sure if older Stan versions can be compiled with boost 1.84-0. I think this can be closed or should we investigate further? Thanks for the note and for the update of BH!

@eddelbuettel
Copy link
Owner

Thanks for the update. In that case I will close this -- be sure to reopen if need be.

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

No branches or pull requests

2 participants