r: Go-based drivers are warned by macOS R CMD check on R-universe

[eitsupi]

What happened?

The following warning occurs:

Warning: Check: compiled code, Result: WARNING
  File ‘adbcflightsql/libs/adbcflightsql.so’:
    Found ‘___stderrp’, possibly from ‘stderr’ (C)
      Object: ‘go/libadbc_driver_flightsql.a’
    Found ‘_abort’, possibly from ‘abort’ (C)
      Object: ‘go/libadbc_driver_flightsql.a’
    Found ‘_exit’, possibly from ‘exit’ (C)
      Object: ‘go/libadbc_driver_flightsql.a’
  
  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.
  
  See ‘Writing portable packages’ in the ‘Writing R Extensions’ manual.

https://github.com/r-universe/r-multiverse/actions/runs/15459357852/job/43517535179#step:6:118
https://github.com/r-universe/apache/actions/runs/15934153289/job/44950249028#step:6:118

This looks like the same issue to apache/arrow#45870, but I am not sure why it is only detected on macOS.

Stack Trace

No response

How can we reproduce the bug?

No response

Environment/Setup

No response

[paleolimbot]

Yes, we've had to work around this in CI by ignoring those warnings. Basically, we can't control what the go runtime contains (it almost certainly writes to stdout/can abort if it needs to). We could cheat and clean up the static library (this is what Arrow does)...since we're not putting the Go based drivers on CRAN I hadn't thought too hard about it.

[eitsupi]

Thanks!

The reason I am concerned about this was because if the check on R-universe has a warning, it will not be registered in the Production repository of R-multiverse. (Of course this is not necessarily a big problem, I just think it would be better to fix it if it can be easily fixed)
https://r-multiverse.org/status/staging/adbcflightsql.html
https://r-multiverse.org/production.html