On 10/19/25 15:29, Sounkou Mahamane Toure wrote:
Dear Simon,
Thank you for this information. I will be reworking my package to use an
external statically linked executable and therefore only require a basic go
installation. I shall send as you said the emails requesting the external
libraries in the case of a second submission to CRAN. In this submission,
the package is likely going to be `Os_type: unix`. There is an existing
MSYS2 go package for the "Rgo" scenario.
The toolchains and pre-compiled libraries in Rtools come from (slightly
modified) MXE, not from Msys2. Using the go compiler from Msys2 for
interoperability within a single address space with code compiled by
Rtools hence wouldn't be safe.
For interoperability with an external executable (produced by go), one
can simply use the default go implementation for Windows, it doesn't
have to come from Msys2.
For interoperatibility within a single address space, the go compiler
would have to be part of Rtools (and all code coming to that address
space from the go side would have to be created by compilers in Rtools).
In principle, it should be possible as GCC supports go.
Best
Tomas
As you said, it would be great to get the feedback of the maintainers of
other Go using packages with c-shared/c-archive linking to see if there is
any appetite for a "Rgo" package for safer R/Go interop. I've added the
feedback from this thread as a comment to the arrow-adbc issue. I shall
experiment with the plugin system and see the implementation details of the
other languages.
Thanks in advance,
Sounkou Mahamane Toure
[1] https://packages.msys2.org/packages/mingw-w64-ucrt-x86_64-go
[2] https://github.com/apache/arrow-adbc/pull/2262#issuecomment-3419647801
Le dim. 19 oct. 2025 à 07:57, Simon Urbanek <[email protected]> a
écrit :
Sounkou,
as usual, you should start with the instructions in "External Libraries
for CRAN packages"[1] which really boils down to sending an e-mail to CRAN
and CCing me and Uwe. That is assuming that produced Go binaries are
self-contained and don't need a run-time. If that's not the case, then it
gets a lot more complicated as it would require static run-time built with
R tools and that may complicate Windows support substantially (since MXE
doesn't have Go AFAICS, you'd have to ask Tomas). In the simple case we can
install toolchains on the build machines if they are officially available
and compatible. The latter is an issue here as you pointed out so it may be
worth discussing that. We may want to test things first before rolling it
out.
The way I see it, given the constraints in Go, it would be worthwhile to
write something like an "Rgo" package that is the only Go runtime and any R
package that wants to add Go code would use it to load its code as Go
plugin. This is in concept similar to other languages like Python
(reticulate) or Java (rJava) where you always load only one run-time and
then simply use the corresponding language-provided loading mechanism to
load any additional code/modules. This is just based on a cursory glance,
so Go enthusiasts may want to comment on the feasibility.
Cheers,
Simon
[1] https://cran.r-project.org/web/packages/external_libs.html
On Oct 18, 2025, at 15:35, Sounkou Mahamane Toure <
[email protected]> wrote:
Dear All,
I have recently submitted a Go using Package to CRAN and it was
archived (i have yet to receive the rejection email).
I have anticipated the warnings (at least on Unix) and made comments
during the submission. A pointer from Ivan Krylov around the potential
of crashing R in the case of loading multiple go buildmode c-shared
loaded in the same process suggests that my comments may have been
misguided (even though I used the c-archive mode).
I figure for the fairly limited use case and the existing design
strategy of limiting communication between the go and C runtime to
pipes, I can execute an external go process instead. One issue remains
tough, is that in order to build this binary at installation time, a
golang toolchain is required.My package failed on win-builder on
windows because go was not found on the PATH of that machine. And as
it happens that shipping with the package pre-built cross-compiled
binaries like it is done in the pmtiles package is not advisable,
options become limited.
Krilov also referenced the case of the adbcbigquery and allied
packages that are likely published on r-multiverse instead of CRAN for
similar reasons.
It would be great if CRAN were to clarify its views on go using
packages and the toolchain.
Thank you in advance
Best regards,
Sounkou Mahamamane Toure
References :
The check on debian can be found here :
https://win-builder.r-project.org/incoming_pretest/goserveR_0.1.3_20251005_222222/Debian/00check.log
golang c-shared restrictions : https://github.com/golang/go/issues/65050
The check on windows :
https://win-builder.r-project.org/incoming_pretest/goserveR_0.1.3_20251005_222222/Windows/00install.out
pmtiles builder of cross-compiled binaries :
https://github.com/walkerke/pmtiles/blob/5fcd3082bb21d5f442d458c42d5165c64c1cf173/tools/build_binaries.sh
arrow-adbc issue : the https://github.com/apache/arrow-adbc/pull/2262
[[alternative HTML version deleted]]
______________________________________________
[email protected] mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[[alternative HTML version deleted]]
______________________________________________
[email protected] mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
______________________________________________
[email protected] mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
