Re: [R-SIG-Mac] Some exceptions not thrown properly with clang4

2017-09-22 Thread Jonah S Gabry
Thanks for the responses. Kevin, your suggestion that issue relates to
mixing multiple copies of libc++ makes sense to me (I think you can even
end up with more than two in some cases) but I'm not enough of an expert in
this area to know for sure. But I did share your response with some of my
colleagues who may have better insights into this than I do.

On Thu, Sep 21, 2017 at 12:46 PM Kevin Ushey  wrote:

> From what I understand, the issue ultimately stems from the mixing of
> different C++ standard library implementations: the system-provided
> libc++, and the LLVM libc++ bundled with R.
>
> A similar issue is described and investigated with the V8 package:
>
> https://github.com/jeroen/V8/issues/37
>
> This becomes even more complicated with R packages that themselves
> attempt to link to external libraries, which themselves are typically
> compiled to use the system's libc++ rather than the R-provided LLVM
> libc++.
>
> To investigate, try launching R with DYLD_SHARED_REGION=avoid to see
> what system libraries are getting loaded (otherwise, macOS loads them
> all together as part of a single 'cache' library), e.g.
>
> R_HOME=/Library/Frameworks/R.framework/Resources \
> DYLD_SHARED_REGION=avoid \
> /Library/Frameworks/R.framework/Resources/bin/exec/R --vanilla
>
> (note that we run the executable directly to ensure the environment
> variables are inherited by the process)
>
> Then, load Rcpp and compile your example, and look at the libraries
> loaded by that R process. For example, I see:
>
> $ lsof -p 40556 | grep libc++
> R   40556 kevin  txtREG1,4   436256 119314065
> /usr/lib/libc++abi.dylib
> R   40556 kevin  txtREG1,4  1436752 108804146
> /usr/lib/libc++.1.dylib
> R   40556 kevin  txtREG1,4  1205156 118545962
> /Library/Frameworks/R.framework/Versions/3.4/Resources/lib/libc++.1.dylib
> R   40556 kevin  txtREG1,4   35 118545963
>
> /Library/Frameworks/R.framework/Versions/3.4/Resources/lib/libc++abi.1.dylib
> R   40556 kevin  txtREG1,4   862316 124608853
> /usr/local/clang4/lib/libc++.1.0.dylib
> R   40556 kevin  txtREG1,4   297040 124608857
> /usr/local/clang4/lib/libc++abi.1.0.dylib
>
> Note that the system libc++ gets loaded when R itself is launched; I
> suspect that R depends on some system libraries that themselves depend
> on the system libc++ implementation. My guess is that the mixture of
> multiple copies of libc++ leads to the issue you're seeing here.
>
> I'm not sure if there's a clean way to resolve this, but please
> correct me if I'm wrong or I've misunderstood / misrepresented
> anything.
>
> Best,
> Kevin
>
> On Thu, Sep 21, 2017 at 12:02 AM, Brian Ripley 
> wrote:
> >
> > The issue is not clang 4 per se.  It can be seen in the CRAN logs for
> quite a few packages built with the clang 4 build from r.research.att.com,
> all of which worked correctly with the LLVM distribution of clang 4.0.0
> (and 4.0.1): the latter required macOS Sierra (without saying so).  And, as
> you say, with at least one version of the Command Line Tools (via Xcode or
> directly), that for 10.12 (but that lacks OpenMP support).
> >
> >
> > > On 20 Sep 2017, at 23:53, Jonah S Gabry  wrote:
> > >
> > > Sorry if line breaks are missing from the test.cpp example file in my
> > > original post.
> > >
> > >> On Wed, Sep 20, 2017 at 2:00 PM, Jonah S Gabry 
> wrote:
> > >>
> > >> With clang4 installed and Makevars updated as described at
> > >> https://cran.r-project.org/bin/macosx/ we are finding unexpected
> behavior
> > >> related to exceptions. The issue was brought to our attention at
> > >>
> > >> http://discourse.mc-stan.org/t/error-in-rstan-2-16-2-after-
> > >> upgrading-to-r-3-4-1-with-clang-4-0-0/1893
> > >>
> > >> but here is a minimal example:
> > >>
> > >> Put the following in "test.cpp":
> > >>
> > >> #include  using namespace Rcpp; // [[Rcpp::export]] int
> > >> throw_exception() { std::stringstream errmsg; errmsg << "this is an
> > >> exception"; throw std::domain_error(errmsg.str()); return 0; }
> > >>
> > >> Then compile and test it with:
> > >>
> > >> Rcpp::sourceCpp("test.cpp")
> > >> throw_exception()
> > >>
> > >> The output is:
> > >>
> > >> Error in throw_exception() : c++ exception (unknown reason)
> > >>
> > >> But the expected output (and the output I get when using e.g. the
> clang
> > >> installation from Xcode) is:
> > >>
> > >> Error in throw_exception() : this is an exception
> > >>
> > >> Is this a known issue?
> > >>
> > >> Thanks,
> > >>
> > >> Jonah
> > >>
> > >> -
> > >>
> > >> I'm running the following:
> > >>
> > >> R version 3.4.1 (2017-06-30)
> > >> Platform: x86_64-apple-darwin15.6.0 (64-bit)
> > >> Running under: macOS Sierra 10.12.6
> > >>
> > >
> > >[[alternative HTML version deleted]]
> > >
> > > ___

[R-SIG-Mac] Xcode 9

2017-09-22 Thread peter dalgaard
Just a quick note: Xcode 9 will not presently create a working R on Sierra or 
earlier.

This is because it ships with an SDK for 10.13 (unreleased) and defines an 
entry for utimensat(), which is not actually in the system library for earlier 
versions. 

There is no way we can fix this reliably for the upcoming 3.4.2 release, so if 
you intend to build R from sources, either 

- just do not upgrade, stay on Xcode 8.3.3 

or 

- manually remove the line from config.h saying

#define HAVE_UTIMENSAT 1




The slightly longer story is that Apple decided to have their include files 
generate a _warning_ that utimensat() is only available in 10.13, like this: 

gcc -I../../../R/src/extra  -I. -I../../src/include -I../../../R/src/include  
-I/usr/local/include -I../../../R/src/nmath -DHAVE_CONFIG_H -g -O2  -c 
../../../R/src/main/platform.c -o platform.o
../../../R/src/main/platform.c:2474:5: warning: 'utimensat' is only available on
  macOS 10.13 or newer [-Wunguarded-availability-new]
utimensat(AT_FDCWD, to, times, 0);
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/sys/stat.h:374:5:
 note: 
  'utimensat' has been explicitly marked partial here
int utimensat(int __fd, const char *__path, const struct timespec __...
^
../../../R/src/main/platform.c:2474:5: note: enclose 'utimensat' in a
  __builtin_available check to silence this warning
utimensat(AT_FDCWD, to, times, 0);
^
../../../R/src/main/platform.c:2890:11: warning: 'utimensat' is only available
  on macOS 10.13 or newer [-Wunguarded-availability-new]
res = utimensat(AT_FDCWD, fn, times, 0) == 0;
  ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/sys/stat.h:374:5:
 note: 
  'utimensat' has been explicitly marked partial here
int utimensat(int __fd, const char *__path, const struct timespec __...
^
../../../R/src/main/platform.c:2890:11: note: enclose 'utimensat' in a
  __builtin_available check to silence this warning
res = utimensat(AT_FDCWD, fn, times, 0) == 0;
  ^
2 warnings generated.

Because of dynamic linking, we do not see the effect of this until we actually 
try running the binary:

begin installing recommended package MASS
dyld: lazy symbol binding failed: Symbol not found: _utimensat
  Referenced from: /Users/pd/r-release-branch/BUILD-dist/bin/exec/x86_64/R
  Expected in: /usr/lib/libSystem.B.dylib

dyld: Symbol not found: _utimensat
  Referenced from: /Users/pd/r-release-branch/BUILD-dist/bin/exec/x86_64/R
  Expected in: /usr/lib/libSystem.B.dylib

/Users/pd/r-release-branch/BUILD-dist/bin/INSTALL: line 34: 59149 Done  
  echo 'tools:::.install_packages()'
 59150 Abort trap: 6   | R_DEFAULT_PACKAGES= LC_COLLATE=C 
"${R_HOME}/bin/R" $myArgs --slave --args ${args}


Same warning also happens during the configure checks, but as it is not an 
error the test program compiles and links OK (but is never run), and we get

checking whether utimensat exists and is declared... yes

Ugh!...


- Peter D.


-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac