> Reed A Cartwright
> on Wed, 11 Oct 2023 22:25:35 -0700 writes:
> Okay, I'll reach out to the CRAN team shortly.
> I wanted to run it by the group here first because my interactions with
the
> CRAN team haven't always been positive and I need to make sure that I'm
not
Okay, I'll reach out to the CRAN team shortly.
I wanted to run it by the group here first because my interactions with the
CRAN team haven't always been positive and I need to make sure that I'm not
missing something "obvious".
On Wed, Oct 11, 2023, 22:22 Simon Urbanek
wrote:
> Reed,
>
> please
Reed,
please contact CRAN - this list can only help with general developer's
questions, not specific issues with a particular CRAN setup - only the
corresponding member of CRAN running the setup can help. I don't see anything
obvious - we can see that it's a mismatch of run-times between the cm
Also the most recent source code tested by CRAN is here:
https://github.com/reedacartwright/rbedrock/tree/v0.3.1
On Wed, Oct 11, 2023 at 7:51 PM Reed A. Cartwright
wrote:
> Update: I submitted a new version of the package, but it did not fix the
> issue. The package has now been archived and I
Update: I submitted a new version of the package, but it did not fix the
issue. The package has now been archived and I do not have access to the
error log output anymore from r-devel-linux-x86_64-fedora-clang.
I did reproduce CRAN's configuration in a VM using the information provided
by CRAN for
Is there any way to submit packages directly to the CRAN's clang17 setup? I
can enable verbose output for CMake and compare the output, but I'd rather
not clog up the CRAN incoming queue just to debug a linker error?
On Wed, Sep 27, 2023 at 2:43 PM Simon Urbanek
wrote:
> It looks like a C++ run-
It looks like a C++ run-time mismatch between what cmake is using to build the
static library and what is used by R. Unfortunately, cmake hides the actual
compiler calls so it's hard to tell the difference, but that setup relies on
the correct sequence of library paths.
The rhub manually forces
I was unable to reproduce the error on the rhub's clang17 docker image.
I notice that the linking command is slightly different between systems.
And this suggests that I need to find some way to get CRAN to pass -stdlib
flag at the linking stage.
CRAN:
/usr/local/clang17/bin/clang++ -std=gnu++17
You might be able to reproduce it with the clang17 container here:
https://r-hub.github.io/containers/
You can either run it directly or with the rhub2 package:
https://github.com/r-hub/rhub2#readme
Gabor
On Wed, Sep 27, 2023 at 8:29 PM Reed A. Cartwright
wrote:
>
> My package, RBedrock, is now
My package, RBedrock, is now throwing an error when compiled against
Clang17. The error log is here:
https://www.stats.ox.ac.uk/pub/bdr/clang17/rbedrock.log
The important part is
"""
Error: package or namespace load failed for ‘rbedrock’ in dyn.load(file,
DLLpath = DLLpath, ...):
unable to load
10 matches
Mail list logo
