wlav

Yes, it's a run-time thing. PCH may need to be rebuild whenever switching args, but that's it. Aside, I pushed the first changes for LLVM16 yesterday; hopefully be done soon,...

It doesn't look like these: ``` export CLING_STANDARD_PCH="none" set EXTRA_CLING_ARGS="-O2 -march=native -std=c++17" ``` were actually set and/or propagated (not sure about the change in set/export either). Can you check on...

Since yours is a CERN project, my first question would be whether you have ROOT somewhere on that box. Point being that ROOT's cppyy is mostly the same, but does...

Not sure, I'm not too familiar with the conda release nor the ROOT install on lxplus. However, the PCH (which would containt `CppyyLegacy`) is build using rootcling, which may have...

Ah yes, of course: the libraries are in your case picked up through `LD_LIBRARY_PATH` and the `cppyy_backend` ones aren't in there, but are available only through the Python package path....

It's pre-installed on lxplus, with ROOT. Only caveats seem to be that you need to set `CLING_STANDARD_PCH=none` (this is not a good idea otherwise, but it'll use modules with ROOT...

Closing b/c it seems completed. Feel free to reopen or start a new issue if there are more questions.

I have no other answer than it is clearly picking up ROOT's version of cppyy. Yes, this should not happen with a virtual environment, but clearly it does. I can...

Well, ROOT doesn't have `CppyyLegacy`, master does, so that diagnosis is clear. As for the stack trace, it only show the top-level `cppyy` module, but the bindings live in `libcppyy.so`...

This seems to be a regression that was introduced in the update to LLVM16. It works fine in current cppyy. There are a few changes in the update to the...