New Package Depending on 'RcppAlgos' Fails CRAN Tests on linux-arm64

[drag05]

CRAN test results on new package mention RcppAlgos failure on linux-arm64 tests. Here is CRAN's response on mailing list:
https://stat.ethz.ch/pipermail/r-package-devel/2026q2/012405.html
or
"The code fails the check for grepl("darwin|solaris", R.version$os)
(what's R.version$os on linux-arm64?) and ends up trying to run the
command for Solaris to detect the number of cores:

RcppAlgos/R/zzz.R

Line 46 in 9405564

system(cmd, TRUE)), error = function(e) NULL))) {next}

..and system("/bin/kstat ...", TRUE) does not swallow the error
message printed on the standard error."

Please advise.
Thank you!

[aitap]

Here's /proc/cpuinfo on the ARM64 machine running the failing check:

Details

processor	: 0
BogoMIPS	: 2000.00
Features	: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 sm3 sm4 asimddp sha512 sve asimdfhm uscat ilrcpc flagm sb paca pacg dcpodp sve2 sveaes svebitperm svesha3 svesm4 flagm2 frint svei8mm svebf16 i8mm bf16
CPU implementer	: 0x41
CPU architecture: 8
CPU variant	: 0x0
CPU part	: 0xd49
CPU revision	: 0
processor	: 1
BogoMIPS	: 2000.00
Features	: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 sm3 sm4 asimddp sha512 sve asimdfhm uscat ilrcpc flagm sb paca pacg dcpodp sve2 sveaes svebitperm svesha3 svesm4 flagm2 frint svei8mm svebf16 i8mm bf16
CPU implementer	: 0x41
CPU architecture: 8
CPU variant	: 0x0
CPU part	: 0xd49
CPU revision	: 0
processor	: 2
BogoMIPS	: 2000.00
Features	: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 sm3 sm4 asimddp sha512 sve asimdfhm uscat ilrcpc flagm sb paca pacg dcpodp sve2 sveaes svebitperm svesha3 svesm4 flagm2 frint svei8mm svebf16 i8mm bf16
CPU implementer	: 0x41
CPU architecture: 8
CPU variant	: 0x0
CPU part	: 0xd49
CPU revision	: 0
processor	: 3
BogoMIPS	: 2000.00
Features	: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 sm3 sm4 asimddp sha512 sve asimdfhm uscat ilrcpc flagm sb paca pacg dcpodp sve2 sveaes svebitperm svesha3 svesm4 flagm2 frint svei8mm svebf16 i8mm bf16
CPU implementer	: 0x41
CPU architecture: 8
CPU variant	: 0x0
CPU part	: 0xd49
CPU revision	: 0

Since it has neither core id nor cpu cores, all of the Linux-specific commands fail.

[jwood000]

Thanks @drag05 for reporting this, and thanks @aitap for providing the linux-arm64 /proc/cpuinfo details. The diagnosis here was correct.

The issue was in the startup-time core detection code in R/zzz.R. This code was originally written to estimate the number of physical cores, which is used by RcppAlgos for cache-size heuristics in the segmented sieve implementation. On linux-arm64, the /proc/cpuinfo fields used by the old Linux-specific shell commands are not present, as @aitap noted. After those Linux checks failed, the old fallback logic incorrectly tried commands for other operating systems as well, including the Solaris-specific /bin/kstat command. Since /bin/kstat is not available on linux-arm64, this produced:

sh: 1: /bin/kstat: not found

Because this code runs during .onLoad(), the warning appeared under several unrelated R CMD check sections.

This is now fixed on main via #63. The fix removes the cross-OS shell-command fallback and replaces the old shell-based detection with a quieter, more portable approach based on parallel::detectCores(logical = FALSE), falling back to logical = TRUE and finally to 1L if needed. The separate maximum-thread check remains handled by the existing std::thread::hardware_concurrency() path.

The linux-arm64 GitHub Actions check is now passing. I plan to submit this fix to CRAN along with a few other minor updates within the next few days.

[drag05]

Thank you, Joseph! I will follow RcppAlgos passing CRAN checks and then re-submit my package.   Dragos ------ Original Message ------ From: ***@***.*** To: ***@***.*** Cc: ***@***.***; ***@***.*** Sent: Saturday, June 6th 2026, 04:08 PM Subject: Re: [jwood000/RcppAlgos] New Package Depending on 'RcppAlgos' Fails CRAN Tests on linux-arm64 (Issue #64)   jwood000 left a comment (jwood000/RcppAlgos#64) <#64 (comment)> Thanks @drag05 <https://github.com/drag05> for reporting this, and thanks @aitap <https://github.com/aitap> for providing the linux-arm64 /proc/cpuinfo details. The diagnosis here was correct. The issue was in the startup-time core detection code in R/zzz.R. This code was originally written to estimate the number of physical cores, which is used by RcppAlgos for cache-size heuristics in the segmented sieve implementation. On linux-arm64, the /proc/cpuinfo fields used by the old Linux-specific shell commands are not present, as @aitap <https://github.com/aitap> noted. After those Linux checks failed, the old fallback logic incorrectly tried commands for other operating systems as well, including the Solaris-specific /bin/kstat command. Since /bin/kstat is not available on linux-arm64, this produced:sh: 1: /bin/kstat: not found   Because this code runs during .onLoad(), the warning appeared under several unrelated R CMD check sections. This is now fixed on main via #63 <#63> . The fix removes the cross-OS shell-command fallback and replaces the old shell-based detection with a quieter, more portable approach based on parallel::detectCores(logical = FALSE), falling back to logical = TRUE and finally to 1L if needed. The separate maximum-thread check remains handled by the existing std::thread::hardware_concurrency() path. The linux-arm64 GitHub Actions check is now passing. I plan to submit this fix to CRAN along with a few other minor updates within the next few days. — Reply to this email directly, view it on GitHub <#64?email_source=notifications&email_token=AJOW72NXK35IKWPEP4EUXSD46R22ZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRUGAZDEOBQGA32M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4640228007> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJOW72KWNO3VLF4N2Z4JMZ346R22ZAVCNFSM6AAAAACZ4KD2BWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DMNBQGIZDQMBQG4> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AJOW72NCMA2CCZSN6FGBBZ346R22ZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRUGAZDEOBQGA32M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/AJOW72PEDAK7ZZDMV54LPFD46R22ZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRUGAZDEOBQGA32M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI> . Download it today!  You are receiving this because you were mentioned.Message ID: ***@***.***>

[jwood000]

@drag05,

I don’t think you should need to re-submit solely because of this RcppAlgos issue. Once the patched version of RcppAlgos is on CRAN, your package should be checked against the updated dependency in subsequent CRAN checks.

My understanding is that the failure was caused by RcppAlgos during dependency checks on linux-arm64, not by your package itself. So after the RcppAlgos update is accepted, I would expect your package to pass that part of the check without any changes on your side.

Of course, if CRAN explicitly asks you to re-submit, follow their guidance, but I don’t think the RcppAlgos fix should require a package change from you.

Cheers