boost::geometry compilation failing with LLVM 19

[Jean-Romain]

I received an email from Prof Bryan Ripley

LLVM 19 is under preparation (18.1.7 is final), and a large number of
C++-using packages are failing to install with the current snapshot (and
have for a couple of months). Most of these are from a broken
StanHeaders headers, but others can be seen at
https://www.stats.ox.ac.uk/pub/bdr/clang19/ (which contains a
README.txt). Those new since 18.1.7 are

In my specific case I have no control on the error. It comes from boost::geometry which itself is using boost::qvm https://www.stats.ox.ac.uk/pub/bdr/clang19/lidR.log Do you know if there is any plan for a boost update in a close future? Otherwise my only option will be to get rid of the features.

[eddelbuettel]

I tend to update BH once a year in December, hitting one out of every three releases.

If you need a submodule sooner I suggest a local copy in your package until BH can catch up.

(Sorry for any delays I was gone for two days of cycling.)

[Jean-Romain]

Thank you for your reply. So I'll disable the feature. I checked boost 1.85 and there is not fix and I don't know how to fix it anyway.

[dcooley]

I've posted this on boost::qvm so hopefully it will get resolved upstream.

[dcooley]

Update: qvm is being fixed

[eddelbuettel]

Let's hope it gets into the December release that will be the basis of the next BH release (following the pattern).

[dcooley]

yep; although a few of us have until 9th October to fix this, so we'll have to go down the 'local copy' route until then.

[eddelbuettel]

Oh, sorry to hear. Just had three of those myself in the last two weeks. And yes, local copy is best.

[dcooley]

qvm now fixed in their develop branch

[JeremyGelb]

Hello ! I am one of the lucky guys that have the same problem with the geometry lib. Could one of you explain me how to have a local copy of the library in my package ? It would be very appreciated !

[eddelbuettel]

In src/Makevars (and src/Makevars.win) declare an additional include directory, maybe below src/ itself. Store what you need from updated upstream Boost (as opposed to what my BH has from their last December's release) in it.

[JeremyGelb]

Thank you @eddelbuettel, I will give it a try.

[eddelbuettel]

Let us know how it goes, and if we can help. It would be good to have a worked example.

[JeremyGelb]

it seems to work if I use the whole boost library locally. However, I would like to use only the required parts. I am stuck at compiling the tool "bcp" that is supposed to extract all the dependencies of a boost submodule.

[eddelbuettel]

If you can use for example a Docker container, you can use that to get a Boost binary installation from a Linux distribution and use its bcp binary.

[eddelbuettel]

We now have Boost 1.87.0-0 in the main branch, and at R-universe. So you could try that to see if it helps with these build issues.

You can follow #103 to see how we are progressing towards CRAN migration.

[JeremyGelb]

This is excellent news !

I could not make it work with a local copy of boost, and I am very happy to know that you are working on the next release of BH.

During my last try, I got an error on CRAN on Ubuntu woth clang 19 which occured during the installation :

*** caught segfault ***
address (nil), cause 'unknown'

It seems that the error is happening when loading a c++ module of my package

Traceback:
1: Module(module, mustStart = TRUE, where = env)
2: doTryCatch(return(expr), name, parentenv, handler)
3: tryCatchOne(expr, names, parentenv, handlers[[1L]])
4: tryCatchList(expr, classes, parentenv, handlers)
5: tryCatch(Module(module, mustStart = TRUE, where = env), error = function(e) e)
6: loadModule(module = "spatial_index_cpp", what = TRUE, env = ns, loadNow = TRUE)

It is rather strange because I have not edited this module since the last version and the package is installing correctly on other platforms. I also tried to validate it with rhub and it worked well even with ubuntu and clang19 : https://github.com/JeremyGelb/spNetwork/actions/runs/11527593888/job/32093568292.

Let me know if I can do something to help.

[eddelbuettel]

Hm, that is frustrating. Modules can be finicky and prefer to have all compilation units compiled by the same compiler. Maybe in the CRAN instances it got mixed? It is hard to tell. Maybe you can debug in a container?

[JeremyGelb]

That's a good point. I will also try to bring this module in its own package and see if I can make it work on CRAN

[eddelbuettel]

BH 1.87.0-1 is now arriving at CRAN and should help with clang-19.