[R][C++] CI job rhub/ubuntu-gcc12:latest is failing due to warnings on libarrow_bundled_dependencies.a

[raulcd]

Describe the bug, including details regarding any error messages, version, and platform.

The rhub/ubuntu-gcc12:latest job is failing on main and PRs:

• main

with:

 ❯ checking compiled code ... WARNING
  File ‘arrow/libs/arrow.so’:
    Found ‘_ZSt4cerr’, possibly from ‘std::cerr’ (C++)
      Objects: ‘../libarrow/arrow-19.0.1.100000187/lib/libarrow.a’,
        ‘../libarrow/arrow-19.0.1.100000187/lib/libarrow_bundled_dependencies.a’
    Found ‘_ZSt4cout’, possibly from ‘std::cout’ (C++)
      Objects: ‘../libarrow/arrow-19.0.1.100000187/lib/libarrow.a’,
        ‘../libarrow/arrow-19.0.1.100000187/lib/libarrow_bundled_dependencies.a’,
        ‘../libarrow/arrow-19.0.1.100000187/lib/libparquet.a’
    Found ‘__printf_chk’, possibly from ‘printf’ (C)
      Object:
        ‘../libarrow/arrow-19.0.1.100000187/lib/libarrow_bundled_dependencies.a’
    Found ‘abort’, possibly from ‘abort’ (C)
      Objects: ‘../libarrow/arrow-19.0.1.100000187/lib/libarrow.a’,
        ‘../libarrow/arrow-19.0.1.100000187/lib/libarrow_acero.a’,
        ‘../libarrow/arrow-19.0.1.100000187/lib/libarrow_bundled_dependencies.a’
    Found ‘exit’, possibly from ‘exit’ (C)
      Object:
        ‘../libarrow/arrow-19.0.1.100000187/lib/libarrow_bundled_dependencies.a’
    Found ‘puts’, possibly from ‘printf’ (C), ‘puts’ (C)
      Object:
        ‘../libarrow/arrow-19.0.1.100000187/lib/libarrow_bundled_dependencies.a’
    Found ‘rand’, possibly from ‘rand’ (C)
      Object:
        ‘../libarrow/arrow-19.0.1.100000187/lib/libarrow_bundled_dependencies.a’
    Found ‘srand’, possibly from ‘srand’ (C)
      Object:
        ‘../libarrow/arrow-19.0.1.100000187/lib/libarrow_bundled_dependencies.a’
    Found ‘stderr’, possibly from ‘stderr’ (C)
      Objects: ‘../libarrow/arrow-19.0.1.100000187/lib/libarrow.a’,
        ‘../libarrow/arrow-19.0.1.100000187/lib/libarrow_bundled_dependencies.a’
    Found ‘stdout’, possibly from ‘stdout’ (C)
      Object:
        ‘../libarrow/arrow-19.0.1.100000187/lib/libarrow_bundled_dependencies.a’
  File ‘arrow/libs/arrow.so’:
    Found non-API calls to R: ‘DATAPTR’, ‘OBJECT’
  
  Compiled code should not call entry points which might terminate R nor
  write to stdout/stderr instead of to the console, nor use Fortran I/O
  nor system RNGs nor [v]sprintf.
  Compiled code should not call non-API entry points in R.
  
  See ‘Writing portable packages’ in the ‘Writing R Extensions’ manual,
  and section ‘Moving into C API compliance’ for issues with the use of
  non-API entry points.

Error: R CMD check found WARNINGs
Execution halted
0 errors ✔ | 1 warning ✖ | 0 notes ✔

Component(s)

R, C++

[raulcd]

@jonkeane @amoeba

[assignUser]

I know we have had issue with the non-API entrypoints warnings before, I doubt we added some in? But might have been accidental. The C warnings are new I think? We will need an exception for those from CRAN because it's not really possible for us to remove these.

[jonkeane]

This looks suspiciously like wch/r-source@fb5500b

[amoeba]

I see we have a similar NOTE in r-patched (what is r-patched? just prelease?). Are there maybe a few references still in the codebase, like:

arrow/r/src/altrep.cpp

Line 1270 in d702d0c

int* ptr = reinterpret_cast<int*>(DATAPTR(x));

[jonkeane]

The Note in r-patched + also in devel is about so called non-API calls (slightly different than the "Compiled code should not call entry points..."). I have a possible idea for the second that I'll try to submit this week.

The non-API calls probably deserve a separate issue. They might be coming from cpp11, or there might be calls we will need to remove and use something else for them. #43044 was similar and https://cran.rstudio.com/doc/manuals/r-devel/R-exts.html#Moving-into-C-API-compliance-1 might have helpful pointers

[nealrichardson]

Also related to non-API calls, there is was thread from the r-package-devel mailing list yesterday: https://stat.ethz.ch/pipermail/r-package-devel/2025q1/011543.html

For this issue here, it looks like we can either rename the .a files to have a different extension, or we can delete them after we build the shared library. (I don't understand why they're checking the symbols of static libraries that have been linked into the shared library and aren't kept around in the built package, but 🤷 ). Deleting is probably cleanest. I'll put up a PR that tries that.