Closed kalibera closed 8 months ago
@kalibera Thanks for this (and the parallel email with CRAN paper trail). It should be easy to apply.
We are etching closer to (belatedly) migrating to Eigen 3.4.0 (see issue #103, scroll to bottom) and I should also check if we need / use this change there. Is there a winbuilder or alike setup (GitHub Actions maybe?) that reproduces the failure?
Looks like I can carry the one-liner straight over to the corresponding file in the PR. Possibly cherry-pick your PR.
@kalibera I added a changelog entry and will merge with that.
@kalibera Thanks for this (and the parallel email with CRAN paper trail). It should be easy to apply.
Thanks.
We are etching closer to (belatedly) migrating to Eigen 3.4.0 (see issue #103, scroll to bottom) and I should also check if we need / use this change there. Is there a winbuilder or alike setup (GitHub Actions maybe?) that reproduces the failure?
There is nothing provided by CRAN, I am not sure about others. When I checked last, there wasn't any fast server hardware yet available to buy. Not even a Windows server OS for the platform. Probably both of that would be needed to setup such box.
To get a personal Windows/arm64 box, the best now is probably still an Apple silicon mac running Windows 11 in a virtual machine. It is very likely many of these problems would be seen with LLVM also on x86_64 Windows. Then there is some devkit from Microsoft, though I recall it used to be sold out.
@yixuan I carried this over to your 3.4.0 branch via two cherry-picks, a rebase appeared to have been more work.
@eddelbuettel This looks great. Many thanks!
Without this fix, e.g. DAISIE fails to build on clang/Windows due to undefined symbol sched_yield().
I am seeing this with LLVM 17, where clang identifies as gcc 4.2. I think ideally the ifdef should be changed so that modern clang also uses the C++ version - I see on godbolt that clang 6.0.0 should be good enough, but I am not sure how to portably check the "clang" way.