Skip to content

[R-pkg-devel] what is difference between Mac setup of rhub and CRAN

7 messages · Gábor Csárdi, Jan Wijffels

#
Hello,

I'm trying to find out what is different between the rhub and CRAN software
for Mac OS to fix the FAIL statement on a package I maintain called
ruimtehol (https://CRAN.R-project.org/package=ruimtehol).
The package builds and checks fine on all CRAN platforms except Mac
OS r-release-osx-x86_64.
1/ CRAN running R 3.4.4: r-oldrel-osx-x86_64  : OS X 10.11.6: Xcode 8.2.1,
clang 4.0.0, GNU Fortran 6.1
2/ CRAN running R 3.5.2: r-release-osx-x86_64 : OS X 10.11.6: Xcode 8.2.1,
clang 4.0.0, GNU Fortran 6.1
3/ rhub running R 3.5.2: unknown setup


The ruimtehol R package builds and checks fine on both CRAN running R 3.4.4
and rhub running R 3.5.2 but apparently FAILS on CRAN running R 3.5.2.

*Question 1*: Can someone indicate what is the difference between the 3
platforms regarding Mac setup (which possibly might give an indication on
what this check problem on the ruimtehol package)
*Question 2*: What can be a reason why a package fails on r-release-osx-x86_64
but checked fine on r-oldrel-osx-x86_64?

FYI. Rhub build on Mac OS with R 3.5.2. is available at
https://artifacts.r-hub.io/ruimtehol_0.1.2.tar.gz-147a4e1367b49538e6134bf0fdf76a32
       CRAN check restuls of the package are at
https://cran.r-project.org/web/checks/check_results_ruimtehol.html

thank you,
Jan

Jan Wijffels
Statistician
www.bnosac.be  | +32 486 611708
#
The R-hub macOS machine is also 10.11.6, and has XCode 8.2.1, but does
not use the CRAN clang 4.0.0 compiler currently. Seems like your
package has compiled code, so this _might_ matter. Sometimes there are
issues when linking C++ libs produced by different compilers, because
the ABIs can be slightly different. E.g. exceptions are sometimes lost
between compilation units. So if you are linking to a system library
that was compiled with the standard macOS compiler, then this can come
up. I suggest you download the clang compiler from CRAN and try to
reproduce it locally.

Best,
Gabor
On Thu, Jan 31, 2019 at 9:03 AM Jan Wijffels <jwijffels at bnosac.be> wrote:
#
Gabor.

Thanks for the input.
I don't have a Mac machine at my disposal but another user of the package
tried helping out debugging here:
https://github.com/bnosac/ruimtehol/issues/10

The package has C++ code which relies on clang-3.3 or newer and relies on
-pthread. It has in it's src/Makevars (
https://github.com/bnosac/ruimtehol/blob/master/src/Makevars)

PKG_LIBS = -pthread
PKG_CPPFLAGS = -pthread

Is that what you mean with linking to a system library?
What version of the compiler is running on rhub and how is it different
from CRAN r-release-osx-x86_64 or even CRAN r-oldrel-osx-x86_64
About CRAN (Question 2): What can be a reason why a package fails on
r-release-osx-x86_64 but checked fine on r-oldrel-osx-x86_64

Jan

Jan Wijffels
Statistician
www.bnosac.be  | +32 486 611708
On Thu, 31 Jan 2019 at 10:50, G?bor Cs?rdi <csardi.gabor at gmail.com> wrote:

            

  
  
#
See answers inline.
On Thu, Jan 31, 2019 at 10:16 AM Jan Wijffels <jwijffels at bnosac.be> wrote:
[...]
Possibly, yes.
R-hub uses the standard system compiler in Xcode. CRAN checks use
their custom built clang compiler. This is usually compatible with the
system compiler, except for some rare ABI issues. You can download it
at https://cran.r-project.org/bin/macosx/tools/  The check flavors
page at https://cran.r-project.org/web/checks/check_flavors.html might
be outdated, as it still shows clang 4.0.0. I don't know, I cannot
speak for CRAN.
Hard to say. I think you only have a real chance to fix this if you
can reproduce it on your machine.

Gabor

[...]
#
Gabor. Thanks for the input. I unfortunately do not have a Mac at my
disposal to check this at that would be indeed the most optimal solution to
find out differences in the setups.

Is there someone on this mailing list which can comment on the CRAN
machines about MacOS to answer

What can be a reason why a package fails on r-release-osx-x86_64 but
checked fine on r-oldrel-osx-x86_64 as  the
https://cran.r-project.org/web/checks/check_flavors.html seem to indicate
they have the same setup? My package is using C++ code which relies on
clang-3.3 or newer and relies on -pthread. The src/Makevars are at
https://github.com/bnosac/ruimtehol/blob/master/src/Makevars

Jan

Jan Wijffels
Statistician
www.bnosac.be  | +32 486 611708
On Thu, 31 Jan 2019 at 11:26, G?bor Cs?rdi <csardi.gabor at gmail.com> wrote:

            

  
  
#
I can reproduce your problem, and indeed it seems that it is a
compiler ABI incompatibility issue. I am not sure how it could be
fixed, though.

With the CRAN compiler it gets stuck here:

### Name: embed_articlespace
### Title: Build a Starspace model for learning the mapping between
###   sentences and articles (articlespace)
### Aliases: embed_articlespace

### ** Examples

library(udpipe)
data(brussels_reviews_anno, package = "udpipe")
x <- subset(brussels_reviews_anno, language == "nl")
x$token <- x$lemma
x <- x[, c("doc_id", "sentence_id", "token")]
set.seed(123456789)
model <- embed_articlespace(x, early_stopping = 1,
                            dim = 25, epoch = 25, minCount = 2,
                            negSearchLimit = 1, maxNegSamples = 2)
#> Start to initialize starspace model.
#> Build dict from input file :
/var/folders/59/0gkmw1yj2w7bf2dfc3jznv5w0000gn/T//RtmpL18Wso/textspace_1200026295f3c.txt
#> Read 0M words
#> Number of words in dictionary:  1274
#> Number of labels in dictionary: 0
#> Loading data from file :
/var/folders/59/0gkmw1yj2w7bf2dfc3jznv5w0000gn/T//RtmpL18Wso/textspace_1200026295f3c.txt
#> Total number of examples loaded : 470
#> 2019-01-31 10:50:04 Start training epoch 1 with learning rate 0.01

Gabor
On Thu, Jan 31, 2019 at 10:34 AM Jan Wijffels <jwijffels at bnosac.be> wrote:
#
Yes, that is exactly the problem I'm facing with that R package.
Anyone knows how do I find out which ABI issue it is & who should I contact
to try to find a solution?

Jan Wijffels
Statistician
www.bnosac.be  | +32 486 611708
On Thu, 31 Jan 2019 at 11:59, G?bor Cs?rdi <csardi.gabor at gmail.com> wrote: