Re: [R-SIG-Mac] How to correct tcltk path?

[Prof Brian Ripley via R-SIG-Mac]

On 04/04/2024 17:46, Kasper Daniel Hansen wrote:

You need to install XQuartz. This is IMO stated somewhat clearly at
   https://cran.r-project.org/bin/macosx/
("somewhat", because - as always - it seems pretty clear when you know what
its trying to say)


And definitely clear in the R-admin manual:

"Various parts of the build require XQuartz to be installed: see 
https://www.xquartz.org/releases/.20 These include the tcltk package and 
the X11 graphics device: attempting to use these without XQuartz will 
remind you."


Without the actual messages, I cannot check if that corresponds to what 
the OP saw.  But it probably was from


message("tcltk DLL is linked to ", shQuote(this))
stop("X11 library is missing: install XQuartz from 
www.xquartz.org",


and he omitted the second line 





Kasper

On Thu, Apr 4, 2024 at 9:13 AM Gregory via R-SIG-Mac <
r-sig-mac@r-project.org> wrote:


Hello,

I'm having an issue with R looking for tcltk in the wrong place. Whenever
I start R, I get a message: tcltk DLL is linked to
'/opt/X11/lib/libX11.6.dylib'. However, there is no /opt/X11 on my system
and tcltk is really in /opt/R/arm64, where the R binary installer put it.
Where is R getting the /opt/X11 path and how do I correct that? So far I've
tried exporting DYLD_LIBRARY_PATH=opt/R/arm64:$DYLD_LIBRARY_PATH to my
environment in my zprofile, but that hasn't worked.

Possibly relevant details:
M2 MacBook Pro, MacOS Sonoma 14.4.1
R.version 4.3.3 installed with binary installer from CRAN.

Thanks in advance,
Gregory

Sent with [Proton Mail](https://proton.me/) secure email.
 [[alternative HTML version deleted]]

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






--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] Graphics in R, version 4.3.2, does not work well in MacOS

[Prof Brian Ripley via R-SIG-Mac]

You need to make clear what graphics device and R build you used: the 
default on a CRAN build of macOS is quartz(), which has nothing to do 
with XQuartz.  But is this a CRAN build?  AFAIK quartz() is not the 
default device in RStudio.


And also give the information (sessionInfo()) requested in the posting 
guide.  As Christophe Dutang has posted, this works for him on arm64 
macOS (and also for me).  CRAN provides both Intel and arm64 builds 


As the posting guide also asks, you should try R-patched: binary 
installers are available at https://mac.r-project.org/ for both 
architectures.


The macOS GUI is usually called R.app (see e.g. the R-admin manual). 
RGUI is for Windows.


On 16/02/2024 09:25, María de los Ángeles Casares de Cal via R-SIG-Mac 
wrote:

Dear Simon and anyone else who might be interested in this:

I have studied in more detail the problem referred to in the message below, and 
can confirm that R does not work well on macOS when I do graphics (plots).
I have only tested with the "abline” command, using the examples that are in 
R’s help. And it does not work.
I have tested it on several computers, in Terminal and with RGUI.
I have also checked it in RStudio in macOS (it does work) and with R in Windows 
(it does work).

What I have done is the following:
In the "abline" command help, the first example is:
## Setup up coordinate system (with x == y aspect ratio):
plot(c(-2,3), c(-1,5), type = "n", xlab = "x", ylab = "y", asp = 1)
## the x- and y-axis, and an integer grid
abline(h = 0, v = 0, col = "gray60")
text(1,0, "abline( h = 0 )", col = "gray60", adj = c(0, -.1))
abline(h = -1:5, v = -2:3, col = "lightgray", lty = 3)
abline(a = 1, b = 2, col = 2)
text(1,3, "abline( 1, 2 )", col = 2, adj = c(-.1, -.1))

if I run line by line, R does not do the plots (only open the Quartz window).
If I run all together, R does the plots sometimes yes and sometimes no.

I have the latest stable version of XQuartz (2.8.5)

What could be the problem?

Thank you in advance.
Best regards.
María-Ángeles Casares-de-Cal



Inicio del mensaje reenviado:

De: María de los Ángeles Casares de Cal 
Asunto: Spanish version of R, version 4.3.2, does not work
Fecha: 14 de febrero de 2024, 20:29:09 CET
Para: r-sig-mac@r-project.org

Hi everyone,

I have a problem since I have installed the last version of R 4.3.2 (spanish 
version)
R does not work!

For example:

x <- 1:20#this is ok
y <- 10 + rnorm(n=20,mean=0,sd=1)#this is ok
plot(x,y,pch=20,col="red")#this is ok, but I have to run some times 
this
model <- lm(y~x)#this is ok
summary(model)  #this is ok
abline(model)   #R does not plot the regression line in 
the window where I have the points.

(And this code in RStudio works well).

(I have installed the last version of XQuartz.)

I do not know what is the problem.
Perhaps, because is the Spanish version?
How can I install the English version?

Any help?
Thank you in advance.

Best regards.
María-Ángeles Casares-de-Cal



[[alternative HTML version deleted]]

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


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] Cross compilation and linking without -undefined

[Prof Brian Ripley]

This is just a default.  AFAICS it is set in DYLIB_LDFLAGS and you can 
set that as you wish - it is documented in config.site.


That cross-compilation cannot test-load is a major reason not to use it 
and why support for packages was downplayed on Windows.


On 02/01/2024 19:21, Jeroen Ooms wrote:

R on MacOS defaults to linking with "-undefined dynamic_lookup" when
building packages, which suppresses linking errors due to undefined
symbols. Undefined symbols often indicate that the package has omitted
a required library in PKG_LIBS, or that the architecture of the static
lib does not match the target. When this happens, CMD INSTALL usually
fails to load the package dylib in the subsequent "test-load" step,
unless the undefined symbols are already preloaded in the process via
base R (e.g. zlib, iconv, etc) in which case it goes unnoticed.

I was wondering what is the benefit of suppressing linking errors this
way? Afaik R does not do this on other platforms. A failure at the
"test-load" step gives a cryptic error indicating only the mangled
name of the first undefined symbol. The linker can provide much nicer
error messages, detailing the names and locations of undefined
symbols.


It may, but it often does not.  Frequently test-loading shows issues in 
complex C++-using packages: you mention 'arrow' and that is a current 
(and frequent) failure on Linux.



Another motivation for looking into this is to support cross compiling
of R packages on MacOS. We are exploring several ways to cross compile
R packages, including:

   macos-x86_64 -> macos-arm64 (by overriding -arch in Makeconf)
   linux-x86_64 -> macos-x86_64 (using osxcross)
   linux-x86_64 -> macos-arm64 (using osxcross)

The main challenge with cross compiling is that we cannot test-load
the R package on the host machine, so we always have to build with
--no-test-load. However this is dangerous in combination with the
"-undefined" flag, because we don't catch undefined symbols anymore.

Unfortunately undefined symbols are a common problem when cross
compiling, because some packages mistakenly assume host == target, and
then build/link a lib for the wrong arch. If we don't catch this, we
end up shipping broken binary R packages to end-users, which we want
to prevent.

To remedy this, I am testing to build packages using the same setup as
CRAN (MacOSX11.sdk + libs from
https://mac.r-project.org/bin/darwin20/) but without the "-undefined
dynamic_lookup" flag, like so:

   sed -i.bak 's/-undefined dynamic_lookup//g' $(R RHOME)/etc/Makeconf

This works fine for almost all packages. Some do reveal a linking
problem, but these are mostly real bugs and easily fixable. For
example the httpuv package fails with:

ld: Undefined symbols:
   _deflate, referenced from:
   GZipDataSource::getData(unsigned long) in gzipdatasource.o
   GZipDataSource::deflateNext() in gzipdatasource.o
   _deflateEnd, referenced from:
   GZipDataSource::~GZipDataSource() in gzipdatasource.o

Note how the above message from the linker is very clear in what is
missing and where. This error is accurate, because httpuv indeed calls
external libz, but fails to set "-lz" in PKG_LIBS. This was never
noticed because libz.dylib is preloaded in R, hence the test-load does
not notice the bug.

Another example is 'arrow' which was missing "-framework Security" in
PKG_LIBS. This will be fixed in the upcoming CRAN release. There were
a few more of such cases where PKG_LIBS was missing some lib of
Framework, but they are mostly fixable.

One problem I have not solved is the RcppParallel package, which
bundles another library (libtbb) which is not linked but lazy-loaded
(not sure why). This causes linking errors or some other packages that
have LinkingTo: RcppParallel. Perhaps this can be solved by providing
a static libtbb via the cran recipes, such that RcppParallel does not
have to bundle one.

It would be really nice if eventually R could remove "-undefined" from
the default linker flags when building R packages. This makes build
logs more informative and easier to debug, and forces packages to
specify complete linker flags, which will eventually enable safer
cross-compiling (including of universal binaries).


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] Is it safe to upgrade to Somoma yet -- As far as R goes?

[Prof Brian Ripley]

On 31/10/2023 18:24, Kevin Thorpe wrote:



On Oct 31, 2023, at 1:46 PM, Prof Brian Ripley  wrote:

On 31/10/2023 13:47, Kevin Thorpe wrote:

Hello.
I saw that a minor release has been rolled up with binaries coming soon. My 
question is whether or not the issues identified (I’m thinking mainly of a 
window focus issue reported on this list) after Sonoma released have been 
patched in this version. I did not see anything specific in the summary of 
changes that went with the email notification to r-help.


Because you are talking about R.app aka Mac-GUI and that is a separate project. 
 See
https://svn.r-project.org/R-packages/trunk/Mac-GUI/NEWS

As for R itself, there are major ramifications of the un-announced replacement 
of libiconv in  macOS 14 and further changes in 14.1 (and who knows what else 
has been changed without being in the release notes).  I certainly would not 
use any version of R older than 4.3.2, and R-devel would be preferred for 
package development (and that will need further changes to R which I guess will 
be ported to R-patched in due course).

With 14 you are likely to see silent substitutions in iconv() (which is used 
pervasively in R): in 14.1, Aborts from libiconv.  Although the latter is 
supposedly Open Source, only the 14.0 changes have been published thus far (and 
Apple often does not publish them for .x versions).



Thank you for this reply. I have never used iconv() directly so looked it up 
and see it has to do with conversion of character encodings. I guess that means 
it can happen in the background, especially when importing data. Correct?


In many, many places 'in the background', at C level as well as R level. 
 As I said, it is 'pervasive'.



It wasn’t clear to me if, "in 14.1, Aborts from libiconv,” means that in 14.1 
when iconv() is used it will fail.

Would a fair interpretation of all this be to hold off a little while longer? 
If so, is there a spot, similar to the GUI NEWS you pointed me to, that I can 
watch myself and not keep bothering the community?


R-devel's NEWS file.

If you develop R packages or if you work with non-ASCII data, consider 
holding off for a quite a while.  But I am not the right person to ask 
-- someone has to try the new versions to find and debug the problems 


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] Is it safe to upgrade to Somoma yet -- As far as R goes?

[Prof Brian Ripley]

On 31/10/2023 13:47, Kevin Thorpe wrote:

Hello.

I saw that a minor release has been rolled up with binaries coming soon. My 
question is whether or not the issues identified (I’m thinking mainly of a 
window focus issue reported on this list) after Sonoma released have been 
patched in this version. I did not see anything specific in the summary of 
changes that went with the email notification to r-help.


Because you are talking about R.app aka Mac-GUI and that is a separate 
project.  See

https://svn.r-project.org/R-packages/trunk/Mac-GUI/NEWS

As for R itself, there are major ramifications of the un-announced 
replacement of libiconv in  macOS 14 and further changes in 14.1 (and 
who knows what else has been changed without being in the release 
notes).  I certainly would not use any version of R older than 4.3.2, 
and R-devel would be preferred for package development (and that will 
need further changes to R which I guess will be ported to R-patched in 
due course).


With 14 you are likely to see silent substitutions in iconv() (which is 
used pervasively in R): in 14.1, Aborts from libiconv.  Although the 
latter is supposedly Open Source, only the 14.0 changes have been 
published thus far (and Apple often does not publish them for .x versions).



--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] Build / source of libRblas.vecLib.dylib

[Prof Brian Ripley]

On 31/10/2023 16:08, Colin Rundel wrote:

The short version of the question - does anyone know what build process is used to 
generate the libRblas.vecLib.dylib that is included in 
/Library/Frameworks/R.framework/Versions/4.3-arm64/Resources/lib by 
R-4.3.1-arm64.pkg? I have not been able to find any direct references in the R source 
files or the build scripts on svn.r-project.org/R-dev-web/ 
.


I asked Simon a few weeks ago -- it is not in the docs.  He said

"the currently shipped version is the umbrella one - i.e. it is simply 
created with -sub_umbrella Accelerate"


which is beyond my mach-O knowledge (and not easy to search for).

Also, it is incomplete (read on) and can cause segfaults.


The longer version with context - I was recently interested in experimenting 
with the Accelerate framework / vecLib. Using CRAN's binary pkg installer 
libRblas.vecLib.dylib is provided and it is straightforward to change the 
libRblas.dylib symlink and get everything working.

However, I've typically used homebrew's formula distribution to install R on my 
systems which compiles R from source. The maintainers have currently opted to 
compile and directly link to openblas which prevents the swapping of blas 
engines via changing symlinks. Changing back to configuring / compiling with 
--enable-BLAS-shlib is easy enough but since Apple has now changed how 
framework dylibs are accessed it seems like something along the lines of 
libRblas.vecLib.dylib is needed,


Something is needed, as the accelerate functions do not use the same ABI 
as the Fortran compiler used to compile R, and so 'shims' are needed 
(and those in the R sources only cover issues in LAPACK, not direct BLAS 
calls).  See


https://cran.r-project.org/doc/manuals/r-devel/R-admin.html#Accelereate

for how this can be done with 'new' Accelerate in R-devel.  My 
experiments showed OpenBLAS to work comparably to 'new' Accelerate.


How best to work around those ABI differences is still under investigation.

I just can't for the life of me figure out how to create it / whereit comes from at the moment. An additional wrinkle is that for homerbrew 
fomulae everything must be compiled from source so the dylib can't just 
be bundled or downloaded.


Thanks,
-Colin
[[alternative HTML version deleted]]

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


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] R 4.3.1 fails on Mac OS X Sonoma

[Prof Brian Ripley]

On 02/10/2023 05:41, David Winsemius wrote:

Neither of you have mentioned anything about the need for reinstallation of 
Xquartz. Was that done?


I did not need to do so when updating to Sonoma.  And of course the 
E.app console (not 'base R') which seems to be the issue does not use X11.


I also did not need to reinstall CLT on this occasion.

The main issue I have found with Sonoma is that it has changed to a 
different (apparently FreeBSD-derived) implementation of iconv with 
(deliberate but undocumented in the release notes) changes in behaviour 
yet still reporting itself as 'libiconv 1.11' using a call specific to 
GNU libiconv).  We have started added workarounds to R-devel and R-patched.




—
David.

Sent from my iPhone


On Oct 1, 2023, at 10:02 AM, William Revelle  wrote:

Rodney,

Thanks for your quick reply.

It turns out this is just a problem with the base R  for Mac graphics window 
(which is to say, the version I like).  I can still use R-studio (which I don’t 
like as much).

I can wait patiently for a patch to the Mac version while using R-Studio.

That way I don’t have to go through the hassle of trying to reinstall 13.x and 
dumping 14.0.

Bill



On Oct 1, 2023, at 11:22 AM, Sparapani, Rodney  wrote:

Hi Bill:
Well, I am usually pretty cautious about this.  I don’t move to the
next release until R is ready.  For Ventura, it took quite awhile
before that happened.  Sorry
--
Rodney Sparapani, Associate Professor of Biostatistics, He/Him/His
Vice President, Wisconsin Chapter of the American Statistical Association
Institute for Health and Equity, Division of Biostatistics
Medical College of Wisconsin, Milwaukee Campus
From: R-SIG-Mac  on behalf of William Revelle 

Date: Sunday, October 1, 2023 at 11:19 AM
To: r-sig-mac@r-project.org 
Subject: [R-SIG-Mac] R 4.3.1 fails on Mac OS 1
ATTENTION: This email originated from a sender outside of MCW. Use caution when 
clicking on links or opening attachments.


Dear Mac users of R and developers.


I recently updated to the Sonoma OS for Mac  (14.0)  and it has a serious 
problem for graphics.

plot(1:10) creates a graphic window but I can not switch back to the console 
window using either command-1 or the mouse.

Anybody else having this problem?  Any suggestions for a patch?

I am running a MacBook Pro with M1 Max.

Bill


(resent because of bad mail address)
William Revellepersonality-project.org/revelle.html
Professorpersonality-project.org
Department of Psychology 
https://urldefense.com/v3/__http://www.wcas.northwestern.edu/psych/__;!!H8mHWRdzp34!6ejyrhAkkZDmz7rI2sf4kna51unncXyvnIMc9xJ12h6pMfylTwNR8QeWq8RTUAAR7NMYOzH5OX_pOA$
Northwestern University
https://urldefense.com/v3/__http://www.northwestern.edu/__;!!H8mHWRdzp34!6ejyrhAkkZDmz7rI2sf4kna51unncXyvnIMc9xJ12h6pMfylTwNR8QeWq8RTUAAR7NMYOzE95PXdSw$
Use R for psychology personality-project.org/r
It is 90 seconds to midnight
https://urldefense.com/v3/__http://www.thebulletin.org__;!!H8mHWRdzp34!6ejyrhAkkZDmz7rI2sf4kna51unncXyvnIMc9xJ12h6pMfylTwNR8QeWq8RTUAAR7NMYOzFQyyeCDA$

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-sig-mac__;!!H8mHWRdzp34!6ejyrhAkkZDmz7rI2sf4kna51unncXyvnIMc9xJ12h6pMfylTwNR8QeWq8RTUAAR7NMYOzHD4ZY2UQ$



William Revellepersonality-project.org/revelle.html
Professorpersonality-project.org
Department of Psychology www.wcas.northwestern.edu/psych/
Northwestern Universitywww.northwestern.edu/
Use R for psychology personality-project.org/r
It is 90 seconds to midnightwww.thebulletin.org

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


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


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] Rcmdr

[Prof Brian Ripley]

On 01/08/2023 00:27, John Fox wrote:

Hello Simon,

Actually the Rcmdr *does* import (and use) the tcltk2 package, but I've 
had no other report of this kind of problem and haven't observed it myself.


Best,
  John


A possible clue.  tclrk2 on Linux used to do something very similar 
(including the infinite loop) if the X server had died but the DISPLAY 
variable was set.


So I would investigate the XQuartz installation, maybe starting with a 
precautionary re-install of the latest non-beta version (currently 
2.8.5).  Then check package tcltk works correctly.


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] M1+ R package test failures (local and Mac Builder)

[Prof Brian Ripley]

Apple Clang 14.0.3 and its associated SDK change to MacOSX13.3.sdk broke 
about 25 CRAN packages (3 with segfaults) and 17 remain broken (and also 
with Xcode/CLT 15 beta 4 which uses a newer build of 14.0.3).  But in my 
checks mmrm 0.2.2 is not one of them.


Packages should aim to be platform-independent. So rather than expect 
all check systems to run the same toolchain, make sure your package 
works on all that are available.  I believe mac-builder uses different 
ones for 'release' and for 'development' but you write as if it uses 
just one -- and I know that there have been changes since R 4.3.0 was 
released.


It is possible to download different CLTs from 
https://developer.apple.com/download/all/ and switch between them (for 
the compiler you will need to install them in turn but you can switch 
between installed SDKs).  I have 14.2, 14.3.1 and 15 beta 4 downloaded 
and switch between them.


Given the several recent security alerts, if you are running macOS 
13.3.1 I would suggest you update to 13.5.


On 25/07/2023 14:50, Sabanes Bove, Daniel via R-SIG-Mac wrote:

Hi R@Mac developers,

I switched yesterday to a new M2 MacBook, coming from a 3+ year old Intel
MacBook.
The concrete problem is that my R package mmrm (including C++ and in
particular Eigen/TMB code) successfully compiles, but the tests fail, i.e.
the compiled and installed R package does not behave correctly.


You give us no idea of the problems.  Please do re-read the posting guide.


First I thought that this is just my local toolchain which is not yet
appropriately configured, but I tried to read more on that and got OpenMP
and gfortran and it should be ok.
So I thought ok, maybe I will try the Mac Builder website and find out in
which commit the R package broke.

Unfortunately, the problem is that the Mac Builder does not help us
sufficiently here, because even the current CRAN release (0.2.2, where
tests based on CRAN binary pass fine locally and on CRAN) leads to test
failures on Mac Builder.

I do see a few differences between the CRAN reported setup and the mac
Builder:
- CRAN is running under macOS Big Sur 11.6.7, while Mac Builder is running
under macOS Ventura 13.3.1 (same as my local machine)
- CRAN uses C++ compiler ‘Apple clang version 13.0.0 (clang-1300.0.29.30)’
(and not 14.0.0 as used for the R compilation!) for the package build,
while Mac Builder uses ‘Apple clang version 14.0.3 (clang-1403.0.22.14.1)’
(this is the same as on my local machine)

At least Mac Builder and my local machine thus use a similar setup it
seems (even though M1 vs M2 difference exists)

My question is: what are your tips on how to move forward here? How can we
set up the Apple clang version and maybe other build flags locally - as
well as on Mac Builder for the whole community - to really match the CRAN
configuration sufficiently well and thus allow for successful package
builds?

Thanks all,
best regards
Daniel

[[alternative HTML version deleted]]

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


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] gfortran: command not found

[Prof Brian Ripley]

On 08/07/2023 00:41, Spencer Graves wrote:

Hello, Simon Urbanek and Professor Ripley:


On 7/7/23 4:21 AM, Simon Urbanek wrote:



On Jul 7, 2023, at 6:54 PM, Prof Brian Ripley  
wrote:


An alternative is not to have gfortran on the path and use a personal 
Makevars file, as documented at 
https://cran.r-project.org/doc/manuals/r-devel/R-admin.html#macOS-packages .


Reasons to do it that way include

a) GCC builds have included other compilers including gcc in the same 
directory as gfortran, and I have been caught in the past by 
badly-written software looking for gcc as a C compiler and finding 
that one rather than Apple's gcc which is a wrapper for clang.  (The 
current gfortran distribution only includes 
x86_64-apple-darwin20.0-gcc and similar.)


b) If the gfortran you have installed differs from that used to build 
R, you may need to set FLIBS, and this has happened as different CRAN 
distributions have been built with different versions of gfortran.


When I do want gfortran on the path, for example to build other 
software, I do symlink it to somewhere on my path.


I would prefer if Simon continues to give the full path as FC in 
etc/Makeconf: anyone who wants a different compiler can use a 
personal Makevars.  (Continues at least for arm64, and I would prefer 
consistency.)





I agree - it wasn't entirely intentional (it's really historical), but 
then there was request for a PATH-less gfortran settings. After this 
discussion I agree that it's not a good idea since the instructions on 
CRAN should be fully self-sufficient *and* we want to avoid other 
incompatible Fortran compilers. (I have trouble reaching the x86_64 
build machine from home right now, so I'll change it on Monday).



   Might it be feasible and appropriate for me to try to do this on 
my 2014 MacBook Pro running macOS 11.7.8?



   I ask, because I have so far not been able to parse the 
instructions in the link Prof. Ripley provided above.  I found a ".r" 
subdirectory in my default directory, but its contents seems to be only 
"crashpad_database".  I did not see anything that looked to me like, 
"HOME/.R/Makevars-R_PLATFORM".  ???


You need to create the file (which is called ~/.R/Makevars in the 
section I referred you to).   Using a case-insenstive file system does 
not help (I had no idea what created ~/.r/crashpad_database, but 
Googling suggests RStudio).


(If you did not have ~/.r, you would need mkdir ~/.R in a Terminal.)
Then use your favourite editor to create a file ~/.r/Makevars containing 
the single line


FC=/opt/gfortran/bin/gfortran


The only issue is if you ever install a new gfortran you will need to 
edit/remove this file -- it is easily forgotten.  As Simon says he is 
changing this soon, I would make a note to remove the file when you 
update R.


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] gfortran: command not found

[Prof Brian Ripley]

An alternative is not to have gfortran on the path and use a personal 
Makevars file, as documented at 
https://cran.r-project.org/doc/manuals/r-devel/R-admin.html#macOS-packages .


Reasons to do it that way include

a) GCC builds have included other compilers including gcc in the same 
directory as gfortran, and I have been caught in the past by 
badly-written software looking for gcc as a C compiler and finding that 
one rather than Apple's gcc which is a wrapper for clang.  (The current 
gfortran distribution only includes x86_64-apple-darwin20.0-gcc and 
similar.)


b) If the gfortran you have installed differs from that used to build R, 
you may need to set FLIBS, and this has happened as different CRAN 
distributions have been built with different versions of gfortran.


When I do want gfortran on the path, for example to build other 
software, I do symlink it to somewhere on my path.


I would prefer if Simon continues to give the full path as FC in 
etc/Makeconf: anyone who wants a different compiler can use a personal 
Makevars.  (Continues at least for arm64, and I would prefer consistency.)



On 07/07/2023 00:07, Simon Urbanek wrote:




On 7/07/2023, at 10:15 AM, Spencer Graves  wrote:

Hi, Simon:


  Thanks for this.  I have more questions:


On 7/6/23 4:52 PM, Simon Urbanek wrote:

In the shell:
PATH=/opt/gfortran/bin:$PATH R CMD INSTALL ...



  Please excuse my ignorance, but I don't understand this.  I previously tried 
"PATH=/bin:/sbin:/user/bin:/user/sbin:/system/Library/ export PATH", 
recommended on a page associated with support.apple.com, as mentioned below.  That did 
not seem to work for me.



That one sets the specified fixed path and then exports it. Setting a fixed 
PATH by hand is typically a bad idea since it removes all existing entries - 
and the one you listed didn't even have gfortran on it. Exporting is another 
alternative if you want to set the PATH for all subsequent commands.

The line I sent just prepends the /opt/gfortran/bin to the PATH for the one R 
CMD command, but doesn't affect anything else. I would recommend reading a 
basic tutorial on unix shell if you really want to know more (actually a good 
idea if you ever want to use the Terminal and not kill your machine).



  How is this different?  What did I do wrong before that this would 
fix?  [Or feel free to ignore this question:  My immediate problem seems to be 
fixed, and I'm not eager to do more experimentation with this now ;-]


in R if using install.packages()
Sys.setenv(PATH=paste0("/opt/gfortran/bin:", Sys.getenv("PATH")))



  If I set this in RStudio, will it affect what I do in "Terminal" on 
my Mac and vice versa?



No, it is only valid for the current R session (and I don't know about RStudio 
- it's not R so sometimes R rules don't apply), that's why I said it's for the 
case where you run install.packages() in the R session.


Note that another alternative is to simply symlink gfortran to your 
/usr/local/bin since that is on the PATH on macOS by default, i.e., you only 
need to run this in the Terminal once (requires admin access):

sudo ln -sfn /opt/gfortran/bin/gfortran /usr/local/bin/gfortran

Cheers,
Simon






  This looks like a potentially similar thing to do from what I did. Is the 
effect of this different?  If so, how? [Again, please feel free to ignore this question.  
I'm not eager to practice my "do-it-myself lobotomy" skills ;-]


  Thanks,
  Spencer Graves>

On Jul 7, 2023, at 5:58 AM, Spencer Graves  wrote:

1.  I need to apologize to Simon:  I failed to see his reply to the original 
post.  Then I found the instructions and installed gfortran-12.2-universal.pkg, 
as indicated there, but it still didn't work.


2.  I'm not finding clear instructions on how to update the path on macOS 11.7.8, which 
is the latest version available for my 2014 MacBook Pro with a 2.8 GHz Quad-Core Intel 
Core i7.  I found several pages with differing instructions.  I found one in 
"support.apple.com" that recommended something that didn't work.[2]


  Further suggestions?


  Thanks again very much.
  Spencer Graves


[2] "support.apple.com" recommended "PATH=/bin:/sbin:/user/bin:/user/sbin:/system/Library/ export PATH", then "env".  I 
did "env" to get the current path, than appended ":/opt/gfortran/bin" to that and executed the revised 
"PATH=...:/opt/gfortran/bin export PATH".  However, when I checked with "env" again, the change was not displayed.  I rebooted 
with the same result.


https://support.apple.com/guide/terminal/use-environment-variables-apd382cc5fa-4f58-4449-b20a-41c53c006f8f/mac


On 7/6/23 11:01 AM, Simon Urbanek wrote:

AFACT he didn't say so, there was no response, just double-posting of the same 
question after is was answered.
The installer says:
The resulting compiler will live in /opt/gfortran and can be called with
/opt/gfortran/bin/gfortran
so it's advisable to have 

Re: [R-SIG-Mac] Problems compiling with R CMD build and devtools::build()

[Prof Brian Ripley]

On 17/05/2023 21:59, Simon Urbanek wrote:

Jarrett,

Duncan's suggestion was correct, but you are using older R, so I'd recommend 
simply upgrading R to the latest release.

If you want to use old R, you have to install the older Fortran binaries that 
match your R version, but that's not entirely trivial so it's easier to just 
upgrade R instead.


It is possible to use a binary R installation with a version of gfortran 
other than it was built with (I have occasionally needed to use a later 
gfortran).  This is discussed in the manual, at

https://cran.r-project.org/doc/manuals/r-devel/R-admin.html#macOS-packages
and
https://cran.r-project.org/doc/manuals/r-devel/R-admin.html#Customizing-package-compilation

The crucial part is that FLIBS (in etc/Makeconf or overridden in a 
personal or site Makevars) has to match the compiler in use.


To reduce confusion I always specify the full path to gfortran in FC.



Cheers,
Simon



On 18/05/2023, at 6:43 AM, Jarrett Phillips  wrote:

Hi Duncan,

I did exactly that, but still got the error above when I try building in
both RStudio via devtools::build() and the Terminal via R CMD build.

To confirm that the right gfortran successfully installed in the correct
location, I did

jarrettphillips@Jarretts-MacBook-Pro ~ % /opt/gfortran/bin/gfortran

*aarch64-apple-darwin20.0-gfortran:* *fatal error: *no input files

compilation terminated.


Any other ideas?




On Wed, May 17, 2023 at 2:13 PM Duncan Murdoch 
wrote:


I think the simplest solution is to remove the gfortran you installed,
and then install it back using the installer on

   https://mac.r-project.org/tools/

Duncan Murdoch

On 17/05/2023 1:26 p.m., Jarrett Phillips wrote:

Hi Rodney,

When I paste the directories into the Terminal, I get

no such file or directory:



suggesting that they don't exist.


Seems like I need to create them (I'm a newbie)?


What should be my next steps?


Thanks!


Cheers,


Jarrett




On Wed, May 17, 2023 at 1:25 PM Jarrett Phillips <

phillipsjarre...@gmail.com>

wrote:


Hi Rodney,

When I paste the directories into the Terminal, I get

no such file or directory:



suggesting that they don't exist.


Seems like I need to create them (I'm a newbie)?


What should be my next steps?


Thanks!


Cheers,


Jarrett





On Wed, May 17, 2023 at 1:07 PM Sparapani, Rodney 
wrote:


Hi Jarrett:



Do the two directories exist that clang is warning you about?



'/opt/R/arm64/gfortran/lib/gcc/aarch64-apple-darwin20.6.0/12.0.1'
'/opt/R/arm64/gfortran/lib'



--

Rodney Sparapani, Associate Professor of Biostatistics, He/Him/His

Director, Wisconsin Chapter of the American Statistical Association

Institute for Health and Equity, Division of Biostatistics

Medical College of Wisconsin, Milwaukee Campus



*From: *R-SIG-Mac  on behalf of

Jarrett

Phillips 
*Date: *Wednesday, May 17, 2023 at 11:54 AM
*To: *r-sig-mac@r-project.org 
*Subject: *[R-SIG-Mac] Problems compiling with R CMD build and
devtools::build()

ATTENTION: This email originated from a sender outside of MCW. Use
caution when clicking on links or opening attachments.


Hi All,

I'm trying to generate a `tar.gz` file on a Mac for R package

submission

to
CRAN but am having issues.

I'm using `devtools`, specifically `build()` and `install()`.

My package relies on compiled code via `Rcpp/RcppArmadillo`.

 build("HACSim_OO")
 ── R CMD build
─
 ✔  checking for file ‘/Users/jarrettphillips/Desktop/HAC
simulation/HACSim_OO/DESCRIPTION’ ...
 ─  preparing ‘HACSim’:
 ✔  checking DESCRIPTION meta-information ...
 ─  cleaning src
 ─  installing the package to process help pages
  ---
 ─  installing *source* package ‘HACSim’ ...
** using staged installation
** libs
clang++ -arch arm64 -std=gnu++11 -
I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG



-I'/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library/Rcpp/include'




-I'/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library/RcppArmadillo/include'

-I/opt/R/arm64/include-fPIC  -falign-functions=64 -Wall -g -O2

-Wall

-pedantic -fdiagnostics-color=always -c RcppExports.cpp -o

RcppExports.o

clang++ -arch arm64 -std=gnu++11
-I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG



-I'/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library/Rcpp/include'




-I'/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library/RcppArmadillo/include'

-I/opt/R/arm64/include-fPIC  -falign-functions=64 -Wall -g -O2

-Wall

-pedantic -fdiagnostics-color=always -c accumulate.cpp -o accumulate.o
clang++ -arch arm64 -std=gnu++11 -dynamiclib
-Wl,-headerpad_max_install_names -undefined dynamic_lookup

-single_module

-multiply_defined suppress

-L/Library/Frameworks/R.framework/Resources/lib

Re: [R-SIG-Mac] Problem installing RUcausal library on MAC

[Prof Brian Ripley]

On 24/04/2023 07:17, Simon Urbanek wrote:

Varin,

you're missing the Fortran compiler which the package requires. To make the 
life a bit easier on you, upgrade to R 4.3.0 and then install GNU Fortran from 
https://mac.r-project.org/tools/

If you don't want to upgrade R then you'll need the Fortran from here: 
https://github.com/R-macos/gcc-darwin-arm64/releases/tag/R-4.2.0-release


Or if you do have a gfortran installation which does not match that used 
for a binary installation of R you can use a ~/.R/Makevars file, as in 
https://cran.r-project.org/doc/manuals/r-devel/R-admin.html#Customizing-package-compilation 
.




Cheers,
Simon




On Apr 24, 2023, at 9:05 AM, varin sacha via R-SIG-Mac 
 wrote:

R-experts,

What is going wrong?

At the end of this page there is the installation command :
https://gitlab.science.ru.nl/gbucur/RUcausal/-/blob/master/README.Rmd

Working with a MAC, I have tried to install the RUcausal library (copy and 
paste the installation command).

It is written that the package has been built on Linux using the GNU Compiler 
Collection. To install the package, open an R instance and run:
install.packages('devtools') # required package
devtools::install_git('https://gitlab.science.ru.nl/gbucur/RUcausal')

I get this error message :

  ERROR: package installation failed
Error: Failed to install 'RUcausal' from Git:
  ! System command 'R' failed
0d0bz2p4xg64gn/T/RtmpMs1teQ/Rinst6453ee77bb8/RUcausal’



install.packages('devtools') # required package
--- Please select a CRAN mirror for use in this session ---
trying URL 
'https://stat.ethz.ch/CRAN/bin/macosx/big-sur-arm64/contrib/4.2/devtools_2.4.5.tgz'
Content type 'application/x-gzip' length 421790 bytes (411 KB)
==
downloaded 411 KB


The downloaded binary packages are in

/var/folders/t_/myv0vvms11g40d0bz2p4xg64gn/T//Rtmp7SUtUd/downloaded_packages

devtools::install_git('https://gitlab.science.ru.nl/gbucur/RUcausal')

Downloading git repo https://gitlab.science.ru.nl/gbucur/RUcausal
'/usr/bin/git' clone --depth 1 --no-hardlinks 
https://gitlab.science.ru.nl/gbucur/RUcausal 
/var/folders/t_/myv0vvms11g40d0bz2p4xg64gn/T//Rtmp7SUtUd/file61a2a8e336a
── R CMD build 
──
─ installing the package to process help pages
  ---ges
─ installing *source* package ‘RUcausal’ ...
  ** using staged installation
  ** libs
  clang++ -arch arm64 -std=gnu++14 
-I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG 
-I'/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library/Rcpp/include' 
-I'/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library/RcppArmadillo/include'
 -I/opt/R/arm64/include -fPIC -falign-functions=64 -Wall -g -O2 -Wall -pedantic -c 
RcppExports.cpp -o RcppExports.o
  clang++ -arch arm64 -std=gnu++14 
-I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG 
-I'/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library/Rcpp/include' 
-I'/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library/RcppArmadillo/include'
 -I/opt/R/arm64/include -fPIC -falign-functions=64 -Wall -g -O2 -Wall -pedantic -c 
compute_DAG_probabilities_BGe_fast.cpp -o compute_DAG_probabilities_BGe_fast.o
  clang++ -arch arm64 -std=gnu++14 -dynamiclib -Wl,-headerpad_max_install_names 
-undefined dynamic_lookup -single_module -multiply_defined suppress 
-L/Library/Frameworks/R.framework/Resources/lib -L/opt/R/arm64/lib -o 
RUcausal.so RcppExports.o compute_DAG_probabilities_BGe_fast.o 
-L/Library/Frameworks/R.framework/Resources/lib -lRlapack 
-L/Library/Frameworks/R.framework/Resources/lib -lRblas 
-L/opt/R/arm64/gfortran/lib/gcc/aarch64-apple-darwin20.6.0/12.0.1 
-L/opt/R/arm64/gfortran/lib -lgfortran -lemutls_w -lquadmath 
-F/Library/Frameworks/R.framework/.. -framework R -Wl,-framework 
-Wl,CoreFoundation
  ld: warning: directory not found for option 
'-L/opt/R/arm64/gfortran/lib/gcc/aarch64-apple-darwin20.6.0/12.0.1'
  ld: warning: directory not found for option '-L/opt/R/arm64/gfortran/lib'
  ld: library not found for -lgfortran
  clang: error: linker command failed with exit code 1 (use -v to see 
invocation)
  make: *** [RUcausal.so] Error 1
  ERROR: compilation failed for package ‘RUcausal’
─ removing 
‘/private/var/folders/t_/myv0vvms11g40d0bz2p4xg64gn/T/RtmpMs1teQ/Rinst6453ee77bb8/RUcausal’
  ---
  ERROR: package installation failed
Error: Failed to install 'RUcausal' from Git:
  ! System command 'R' failed
0d0bz2p4xg64gn/T/RtmpMs1teQ/Rinst6453ee77bb8/RUcausal’


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

Re: [R-SIG-Mac] Please test R 4.3.0 RC, more information below

[Prof Brian Ripley]

On 18/04/2023 11:01, Göran Broström wrote:

About the Fortran compiler:

Den 2023-04-18 kl. 05:18, skrev Simon Urbanek:

Dear Mac users,





Package developers, please check the CRAN result pages for your
package to make sure it passes checks. Also please note that we are
now using a universal GNU Fortran compiler that works both on Intel
and arm64 Macs - you can download an Apple Installer from 
https://mac.r-project.org/tools/


I have GNU Fortran (GCC) 12.0.1 20220312 (experimental)

in /opt/R/arm64/gfortran/bin/gfortran

Should it be uninstalled/removed in some way before installing
gfortran-12.2-universal.pkg, and if so, how?


Not necessary, as the newer compiler installs into /opt/gfortran.  You 
may need to change FC and FLIBS in a ~/.R/Makevars if you use one, and 
you may need to adjust your path if you use Fortran other than for R 
packages.


To remove the older version, delete /opt/R/arm64/gfortran/ .

--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] Symbol not found: _timespec_get

[Prof Brian Ripley]

On 04/04/2023 18:45, Tomas Kalibera wrote:


On 4/4/23 18:26, Jennifer Wokaty wrote:

Hi,

I tried installing the x86_64 alpha available today at 
https://mac.r-project.org/big-sur-x86_64/R-4.3-branch/R-4.3-branch-x86_64.pkg; however, I'm getting the following error:


$ sudo installer -pkg R-4.3-branch-x86_64.pkg -target /
installer: Package name is R 4.3.0 for macOS (X86_64)
installer: Upgrading at base path /
installer: The upgrade was successful.
$ R
dyld: lazy symbol binding failed: Symbol not found: _timespec_get
   Referenced from: 
/Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/lib/libR.dylib (which was built for Mac OS X 11.0)

   Expected in: /usr/lib/libSystem.B.dylib

dyld: Symbol not found: _timespec_get
   Referenced from: 
/Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/lib/libR.dylib (which was built for Mac OS X 11.0)

   Expected in: /usr/lib/libSystem.B.dylib

Abort trap: 6

Is this a problem with the .pkg file?


Hi Jen,

could you please report your macOS version, e.g. via sessionInfo()? Is 
it at least 11?


'they' probably cannot run R to run sessionInfo().  Use 'About this Mac' 
from the Apple menu to find the version without R.


The header has

__API_AVAILABLE(macosx(10.15), ios(13.0), tvos(13.0), watchos(6.0))
int timespec_get(struct timespec *ts, int base);

which says timespec_get is available from macOS 10.15 (Catalina)

We have had trouble with this before: configure.ac says

## timespec_get is C11.
## macOS added timespec_get in 10.15 but used 10.15's SDK for 10.14 
(Darwin 18)


and it skips detection for Darwin <= 18.



Tomas



Jennifer Wokaty (they/them)

Waldron Lab at CUNY SPH
Bioconductor Core Team-- 

Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] arm downloads appear broken

[Prof Brian Ripley]

On 27/02/2023 08:09, Prof Brian Ripley wrote:
Your subject line is alarmist -- you only provide any evidence for 1 out 
of > 19000 CRAN packages (and not R itself).


Package RGtk2 was archived in 2021.  The current rattle (5.5.1) does not 
depend on it.  A direct download is available from rattle's CRAN landing 
page.  You have not told us what version of rattle you downloaded nor 
from where.


For me just now R 4.2.2 successfully downloaded

trying URL 
'https://cran.wu.ac.at/bin/macosx/big-sur-arm64/contrib/4.2/rattle_5.5.1.tgz'


I should have said that rattle does not declare a *strict* dependency on 
RGtk2.  When I try to run rattle() I see


> rattle()
Error in rattle() :
The RGtk2 package is not available but is required.
Please install the package using, for example:

  install.packages("RGtk2")

which would have failed.

Maybe you have some non-CRAN version of RGtk2 installed?

rattle's DESCRIPTION does say

  Note that RGtk2 and cairoDevice have been archived on CRAN.
  See <https://rattle.togaware.com> for installation instructions.

If you followed that, it would be something to take up with the 'rattle' 
maintainer.



On 27/02/2023 04:32, Keith Bierman wrote:

I've tried several (4.2 branches.pkg, R-GUI8191 dmg  R installs fine,
but attempts to the load rattle fail. If I missed some obvious


Loading rattle seems to have worked -- it was running rattle() that failed.


configuration switch, feel free to point me at the FM! ;>
Seems to me that the downloads marked arm64 should only suck in
arm64-compatible dependencies..

. library(rattle)
Loading required package: tibble
Loading required package: bitops
Rattle: A free graphical interface for data science with R.
Version 5.5.1 Copyright (c) 2006-2021 Togaware Pty Ltd.
Type 'rattle()' to shake, rattle, and roll your data.

rattle()

Loading required package: RGtk2
Error in library.dynam("RGtk2", pkgname, libname) :
   shared object ‘RGtk2.so’ not found
Authorization required, but no authorization protocol specified

Need GTK+ ? (Restart R after installing)

1: Install GTK+
2: Do not install GTK+

Selection: 1
trying URL 'http://r.research.att.com/libs/GTK_2.24.17-X11.pkg'''

Which consistently seems to load the *INTEL* version of GTK, so of course
it installs, but fails to run, and tries to install again. Loop forever.


From the installer:


Requirements:

- Mac OS X 10.6 (Leopard) or higher, Intel 64-bit Mac


I*t supports Intel 64-bit Macs only.* All files will be installed in

*/Library/Frameworks/GTK+.framework/Versions/2.24.X11*

Keith Bierman
khb...@gmail.com
303 997 2749 <http://voice.google.com/calls?a=nc,%2B13039972749>

[[alternative HTML version deleted]]

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




--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] arm downloads appear broken

[Prof Brian Ripley]

Your subject line is alarmist -- you only provide any evidence for 1 out 
of > 19000 CRAN packages (and not R itself).


Package RGtk2 was archived in 2021.  The current rattle (5.5.1) does not 
depend on it.  A direct download is available from rattle's CRAN landing 
page.  You have not told us what version of rattle you downloaded nor 
from where.


For me just now R 4.2.2 successfully downloaded

trying URL 
'https://cran.wu.ac.at/bin/macosx/big-sur-arm64/contrib/4.2/rattle_5.5.1.tgz'


On 27/02/2023 04:32, Keith Bierman wrote:

I've tried several (4.2 branches.pkg, R-GUI8191 dmg  R installs fine,
but attempts to the load rattle fail. If I missed some obvious
configuration switch, feel free to point me at the FM! ;>
Seems to me that the downloads marked arm64 should only suck in
arm64-compatible dependencies..

. library(rattle)
Loading required package: tibble
Loading required package: bitops
Rattle: A free graphical interface for data science with R.
Version 5.5.1 Copyright (c) 2006-2021 Togaware Pty Ltd.
Type 'rattle()' to shake, rattle, and roll your data.

rattle()

Loading required package: RGtk2
Error in library.dynam("RGtk2", pkgname, libname) :
   shared object ‘RGtk2.so’ not found
Authorization required, but no authorization protocol specified

Need GTK+ ? (Restart R after installing)

1: Install GTK+
2: Do not install GTK+

Selection: 1
trying URL 'http://r.research.att.com/libs/GTK_2.24.17-X11.pkg'''

Which consistently seems to load the *INTEL* version of GTK, so of course
it installs, but fails to run, and tries to install again. Loop forever.


From the installer:


Requirements:

- Mac OS X 10.6 (Leopard) or higher, Intel 64-bit Mac


I*t supports Intel 64-bit Macs only.* All files will be installed in

*/Library/Frameworks/GTK+.framework/Versions/2.24.X11*

Keith Bierman
khb...@gmail.com
303 997 2749 

[[alternative HTML version deleted]]

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


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] macOS may not give R much time in a long compute

[Prof Brian Ripley]

Are you using R.app (you failed to say)?

If so, have you acted on the documentation about 'app nap'?  E.g. §4.1 
of the R-admin manual.


On 18/02/2023 12:31, Spencer Graves wrote:

Hello:


   During a long compute (in a while loop), I've asked R to report 
progress via:



# Progress report every 3 minutes
   et3i <- proc.time()-startT3i
   if(max(et3i)>180){
     startT3i <- proc.time()
     cat('iscan = ', iscan3, '; et3i = ',
     round(et3i[1:3]), '\n')
   }


   When it's running properly, I get something like the following:


iscan =  22992 ; et3i =  180 26 104


   However if I leave my computer running unattended, I can get 
reports like the following:



iscan =  32124 ; et3i =  22 1 180


   Evidently, macOS 11.7.4 decided NOT to give time to R.


   Suggestions?
   Thanks,
   Spencer Graves


  sessionInfo()
R version 4.2.2 (2022-10-31)
Platform: x86_64-apple-darwin17.0 (64-bit)
Running under: macOS Big Sur 11.7.4

Matrix products: default
LAPACK: 
/Library/Frameworks/R.framework/Versions/4.2/Resources/lib/libRlapack.dylib


locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

loaded via a namespace (and not attached):
[1] compiler_4.2.2 tools_4.2.2    knitr_1.42 xfun_0.37
 >



--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] List of unnecessary messages when I plot something in R from Terminal

[Prof Brian Ripley]

Please do read ?sessionInfo

 Where R was compiled under macOS 10.x (as the CRAN Intel
 distributions have been) but running under ‘Big Sur’ or later,
 macOS reports itself as ‘10.16’ (which R recognizes as ‘Big Sur
 ...’) and not ‘11.x’ or later.

This is only an issue on Intel binary distributions: the arm64 ones are 
built on macOS 11.


On 12/02/2023 09:48, Calboli Federico (LUKE) wrote:

Pretty use R does disinguish MacOS versions:


sessionInfo()

R version 4.2.2 (2022-10-31)
Platform: aarch64-apple-darwin20 (64-bit)
Running under: macOS Ventura 13.2

for me.  So if one is on Ventura but R thinks it is running on a different OS, 
that’s a starting point right there.

BW

F


On 11. Feb 2023, at 23.53, Jeff Newmiller  wrote:

Operating systems are designed to be as backward-compatible as possible... R 
Core doesn't generally know what distinguishing features will identify a new OS 
until it is released, nor what it will be called, so R has a handicap.

On February 11, 2023 1:12:42 PM PST, Christofer Bogaso 
 wrote:

Actually when I check from the Apple icon, then I see that I am
actually running Ventura

For some reason, R's sessionInfo() is reporting that I am running Big Sur.

Not sure why R is reporting wrong. Thanks,


'macOS Big Sur ...' is not 'wrong'.


On Sun, Feb 12, 2023 at 2:38 AM Christofer Bogaso
 wrote:


Hi,

I am running Big Sur. Below is my sessionInfo()


sessionInfo()


R version 4.2.1 (2022-06-23)

Platform: x86_64-apple-darwin17.0 (64-bit)

Running under: macOS Big Sur ... 10.16


Matrix products: default

BLAS:   
/Library/Frameworks/R.framework/Versions/4.2/Resources/lib/libRblas.0.dylib

LAPACK: 
/Library/Frameworks/R.framework/Versions/4.2/Resources/lib/libRlapack.dylib


locale:

[1] C/UTF-8/C/C/C/C


attached base packages:

[1] stats graphics  grDevices utils datasets  methods   base


loaded via a namespace (and not attached):

[1] compiler_4.2.1

On Sun, Feb 12, 2023 at 1:55 AM Simon Urbanek
 wrote:


Christofer,

yes, unfortunately this is a known bug in macOS Ventura affecting a lot of 
command-line programs that use GUI. Do not upgrade to Ventura (usually a good 
advice given the long list of known bugs in Ventura) or wait for a fix from 
Apple.

Cheers,
Simon




On Feb 11, 2023, at 11:28 PM, Christofer Bogaso  
wrote:

Hi,

When I plot something in R, then it open Quartz and in the console I
see below messages


plot(1:4)



1   HIToolbox   0x7ff8229a2726 
_ZN15MenuBarInstance22EnsureAutoShowObserverEv + 102


2   HIToolbox   0x7ff8229a22b8
_ZN15MenuBarInstance14EnableAutoShowEv + 52

3   HIToolbox   0x7ff822946908
SetMenuBarObscured + 408

4   HIToolbox   0x7ff8229464ca
_ZN13HIApplication15HandleActivatedEP14OpaqueEventRefhP15OpaqueWindowPtrh
+ 164

5   HIToolbox   0x7ff822940996
_ZN13HIApplication13EventObserverEjP14OpaqueEventRefPv + 252

6   HIToolbox   0x7ff822908bd2
_NotifyEventLoopObservers + 153

7   HIToolbox   0x7ff8229403e6
AcquireEventFromQueue + 494

8   HIToolbox   0x7ff82292f3ec
ReceiveNextEventCommon + 285

9   HIToolbox   0x7ff82292f2b3
_BlockUntilNextEventMatchingListInModeWithFilter + 70

10  AppKit  0x7ff81c136f33 _DPSNextEvent + 909

11  AppKit  0x7ff81c135db4
-[NSApplication(NSEvent)
_nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1219

12  grDevices.so0x0001086f7a3b input_handler + 155

13  libR.dylib  0x000108b142cf
Rstd_ReadConsole + 2127

14  libR.dylib  0x000108a15b74
Rf_ReplIteration + 100

15  libR.dylib  0x000108a174b1 R_ReplConsole + 161

16  libR.dylib  0x000108a17402 run_Rmainloop + 82

17  libR.dylib  0x000108a1753e Rf_mainloop + 14

18  R   0x00010847af5b main + 27

19  dyld0x7ff818bde310 start + 2432

1   HIToolbox   0x7ff822aa952b
_ZN15MenuBarInstance21IsAutoShowHideAllowedEv + 259

2   HIToolbox   0x7ff8229a233e
_ZN15MenuBarInstance24UpdateAutoShowVisibilityE5Pointh + 34

3   HIToolbox   0x7ff8229117a4
_ZN15MenuBarInstance16ForEachMenuBarDoEU13block_pointerFvPS_E + 46

4   HIToolbox   0x7ff8229a293d
_ZN15MenuBarInstance20AutoShowHideObserverEjP14OpaqueEventRefPv + 165

5   HIToolbox   0x7ff822908bd2
_NotifyEventLoopObservers + 153

6   HIToolbox   0x7ff82293afb8
PostEventToQueueInternal + 700

7   HIToolbox   0x7ff82293c871

Re: [R-SIG-Mac] R installation issue

[Prof Brian Ripley]

On 27/01/2023 22:48, Peter West wrote:

Installation of R 4.2.2 on my M1 just succeeded.


Yes, that has been very widely tested.  We don't know what OS you or the 
OP are running, though.


Machines with M2 CPUs are very new (like 1-2 days old) and are 
presumably running 13.1 or 13.2.


I have just re-installed 4.2.2 on Macs running Ventura 13.2 with M1 Pro 
and M1 Mac CPUs.  If I had a failure my first step would be to look at 
the Console logs (the Console App is under Applications/Utilities).  And 
I would make sure my OS was up-to-date (13.2 is also new this week).



On 28 Jan 2023, at 3:29 am, Calboli Federico (LUKE)  
wrote:

What are your security settings?

BW

F


On 27. Jan 2023, at 17.49, Zhengyang Xiao  wrote:

Hi, Adrian:

Thank you for helping.
My computer has M2 chip. I don’t have other computers.

Travis


Get Outlook for iOS
From: Adrian Dușa 
Sent: Friday, January 27, 2023 8:23:24 AM
To: Zhengyang Xiao 
Cc: R list 
Subject: Re: [R-SIG-Mac] R installation issue   Hello Travis,

Just a quick suggestion, from the screenshot it can be seen the installer is 
intended for the ARM architecture of MacOS.
Do you have an M1 Apple or an Intel Apply computer? There are different 
installers for these two architectures.

Hope this helps,
Adrian


On Fri, 27 Jan 2023 at 15:20, Zhengyang Xiao  wrote:
Hi, officers,
I can't install R as the installer always shows 'The installation failed' as 
shown in the picture below. I have tried several times and restarted my 
computer, but it didn't work. The window says I should contact the software 
manufacturer for help, so I am here to ask for help. I am in a hurry to install 
it because I need it to finish my school assignment for the R-related course at 
my university. If you need any extra information, please email me, and I will 
respond as soon as possible.

I am looking forward to hearing from you.

Thanks!

Travis Xiao


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] another R crash issue

[Prof Brian Ripley]

On 01/12/2022 21:00, Simon Urbanek wrote:

This is a clear bug in gmp (the R package) - simply division by zero in

templateMatrix.h:126:return this->size() / nRows();

   * frame #0: 0x0001076e1b12 
gmp.so`math::Matrix::nCols(this=0x7ffeefbfc5d8) const at 
templateMatrix.h:126:25 [opt]
 frame #1: 0x0001076ea253 
gmp.so`matrixz::bigint_transpose(mat=0x7ffeefbfc5d8) at matrix.cc:484:23 
[opt]
 frame #2: 0x0001076eb3be 
gmp.so`::biginteger_rbind(args=0x000108a60848) at matrix.cc:459:12 [opt]

i.e., bigint_transpose() cannot deal with 0-row matrices. That may be just the 
tip of the ice berg, even biginteger_rbind itself should probably just skip 
zero-length objects.


My macOS build showed a different issue which also needs correcting:

> rbind(NULL, as.bigz(c(1,3)))
Big Integer ('bigz') Error in sprintf("%d x %d matrix", nr, n/nr) :
  invalid format '%d'; use format %f, %e, %g or %a for numeric objects

but I get a segfault on Linux.

There are two instances in gmp/R:

biginteger.R:sprintf("%d x %d matrix", nr, n/nr)
bigq.R:sprintf("%d x %d matrix", nr, n/nr)

Note too that n in

  if((n <- length(x)) > 0) {

need not be of integer type, and n/nr never will be.


Cheers,
Simon



On 17/11/2022, at 9:50 PM, Martin Maechler  wrote:


Carl Witthoft
on Wed, 16 Nov 2022 19:58:31 -0500 writes:



This may be the fault of the `gmp` library, but posting to r-sig as well
just in case.



Mac OS 11.6.8  , R 4.2.2


Yes, the gmp package Mac version gives immediate seg faults.

Prof Brian Ripley has already alerted the gmp package maintainer, me
(a gmp package co-author, not familiar with the C++ design in
there, and maintainer of dependent R package 'Rmpfr') and
the CRAN team.

He has debugged deeply and tediously until diagnosing the
problem happens in *assembler* (!) code of the libgmp.a library
(i.e, the 'gmp'  C library that has nothing to do with R).

Brian Ripley further found that when using the latest
*development* version of that gmp C library and building libgmp
and R packages gmp and Rmpfr himself from the sources he got no
more segfaults.

The problem is only seen on the Mac.

Martin



Consider the following work:


Rgames> foo <- NULL
Rgames> rbind(foo,c(1,3))

[,1] [,2]
[1,]13

Rgames> foo <- NULL
Rgames> # rbind(foo,as.bigz(c(1,3)))  ## instant crash



Further playing around suggests that , given that  as.bigz(NULL) returns
a  "bigz(0) " empty object,   gmp is really unhappy trying to do almost
anything with said object.




regards,
Carl




Crash log follows
Process:   R [11657]
Path:  /Applications/R.app/Contents/MacOS/R
Identifier:org.R-project.R
Version:   R 4.2.2 GUI 1.79 High Sierra build (8160)
Code Type: X86-64 (Native)
Parent Process:??? [1]
Responsible:   R [11657]
User ID:   502



Date/Time: 2022-11-16 19:42:41.462 -0500
OS Version:macOS 11.6.8 (20G730)
Report Version:12
Anonymous UUID:B755C094-C366-46AB-8EEA-9D3B8E7B388D



Sleep/Wake UUID:   D725679E-AF7A-4203-8EA3-B313AA2846F5



Time Awake Since Boot: 98000 seconds
Time Since Wake:   2100 seconds



System Integrity Protection: enabled



Crashed Thread:0  Dispatch queue: com.apple.main-thread



Exception Type:EXC_ARITHMETIC (SIGFPE)
Exception Codes:   EXC_I386_DIV (divide by zero)
Exception Note:EXC_CORPSE_NOTIFY



Termination Signal:Floating point exception: 8
Termination Reason:Namespace SIGNAL, Code 0x8
Terminating Process:   exc handler [11657]



Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   gmp.so  0x0001149159c2
math::Matrix::nCols() const + 34
1   gmp.so  0x00011491e5af
matrixz::bigint_transpose(bigvec&) + 47
2   gmp.so  0x00011491f8be biginteger_rbind + 
158
3   libR.dylib  0x000104b3f8dc R_doDotCall + 1420
(dotcode.c:601)
4   libR.dylib  0x000104b8b7ed bcEval + 104269
(eval.c:7692)
5   libR.dylib  0x000104b71a01 Rf_eval + 385
(eval.c:748)
6   libR.dylib  0x000104b91839 R_execClosure + 2169
7   libR.dylib  0x000104b90627 Rf_applyClosure +
471 (eval.c:1844)
8   libR.dylib  0x000104af61db do_bind + 1051
(bind.c:1118)
9   libR.dylib  0x000104bdbbfa do_internal + 362
(names.c:1399)
10  libR.dylib  0x000104b7920d bcEval + 29037
(eval.c:7156)
11  libR.dylib  0x000104b71a01 Rf_eval + 385
(eval.c:748)
12  libR.dylib  0x000104b91839 R_execClosure + 2169
13  libR.dylib 

Re: [R-SIG-Mac] R does not build out of the box on Ventura

[Prof Brian Ripley]

On 25/10/2022 10:13, Prof Brian Ripley wrote:
The problem being that devQuartz.c uses a deprecated and now removed 
interface (ATS).


Building with --without-aqua will work.

I am sure that Simon will fix this, but not in time for 4.2.2 which is 
in code freeze.


Note this only affects building: as the CRAN binary distributions are 
built on much older versions of macOS they should continue to build. 
This is purely a heads up for those building from source that they may 
want to delay upgrading to Ventura (but someone needed to to find the 
issue).


For the first time for quite a while, upgrading to Ventura removes the 
Command Line Tools which need reinstalling.


Having found the relevant release note:

https://developer.apple.com/documentation/macos-release-notes/macos-13-release-notes

I can add a bit more info.

1) The build failure is only seen if you are using the macOS 13 SDK.  It 
has been possible to build with the 12.3 SDK.  But if you don't yet have 
the macOS 13 SDK you are likely to get upgraded to it soon.  Look at


ls -l `xcrun -show-sdk-path`

to see what you have (it is a symlink, to MacOSX13.0.sdk on my system).

2) If you are, a workaround is to add something like

-mmacosx-version-min=12.0

to CFLAGS.

--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] macOS Ventura (13) Preview App Drops Support for PS/EPS File Rendering

[Prof Brian Ripley]

Somehow you sent HTML only, and that renders oddly in Thunderbird.

Have you considered GhostScript?  That used to be my viewer of choice 
for Postscript long ago.  I think TeXShop may be a wrapper.


My box has Photoshop as the default viewer for .eps and TeXShop for .ps. 
 I almost never use Photoshop: it comes as part of Adobe's 
Photographers Bundle.


Brian

On 26/10/2022 01:06, Marc Schwartz via R-SIG-Mac wrote:

Hi All,

Having updated to macOS Ventura, I just became aware that Ventura's 
Preview app has dropped support for rendering PS and EPS files after all 
these years.


Not clear on the rationale for this change, but there is an Apple 
Support article here on this:


   https://support.apple.com/en-us/HT213250

Apparently, one can still print these files by dragging and dropping 
them on to the printer queue, but you will need to find a different 
application, such as the TeXShop app, which is bundled in macTeX for 
free, or another option is the full Adobe Acrobat Pro application, if 
you have and pay for that.


If you are so inclined, you can provide product feedback to Apple here:

   https://www.apple.com/feedback/macos.html

Regards,

Marc Schwartz


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


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] R does not build out of the box on Ventura

[Prof Brian Ripley]

On 25/10/2022 10:53, peter dalgaard wrote:

Thanks for the heads-up, Brian.

Older binaries still install and run on Ventura, I hope?


They do, in so far as I have tested (which included some plotting).


I intend to hold off updating at least the office machine (which builds the 
tarballs) until 4.3.0, for platform stability. The push for Ventura doesn't 
seem to have arrived here yet, but probably will come in a few days.

By the way, I have been getting update requests for "Command Line Tools beta n for 
Xcode 14.1", even though I have no recollection of signing up for beta versions. I'm 
rather reluctant to install those.


That's an Apple trait. As you are on macOS 12.x, I would feel free to 
ignore them: even those for the released CLT 14 (although (I was using 
that on 12.6 for a month with no issues).




- Peter


On 25 Oct 2022, at 11:13 , Prof Brian Ripley  wrote:

The problem being that devQuartz.c uses a deprecated and now removed interface 
(ATS).

Building with --without-aqua will work.

I am sure that Simon will fix this, but not in time for 4.2.2 which is in code 
freeze.

Note this only affects building: as the CRAN binary distributions are built on 
much older versions of macOS they should continue to build. This is purely a 
heads up for those building from source that they may want to delay upgrading 
to Ventura (but someone needed to to find the issue).

For the first time for quite a while, upgrading to Ventura removes the Command 
Line Tools which need reinstalling.

--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford



--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

[R-SIG-Mac] R does not build out of the box on Ventura

[Prof Brian Ripley]

The problem being that devQuartz.c uses a deprecated and now removed 
interface (ATS).


Building with --without-aqua will work.

I am sure that Simon will fix this, but not in time for 4.2.2 which is 
in code freeze.


Note this only affects building: as the CRAN binary distributions are 
built on much older versions of macOS they should continue to build. 
This is purely a heads up for those building from source that they may 
want to delay upgrading to Ventura (but someone needed to to find the 
issue).


For the first time for quite a while, upgrading to Ventura removes the 
Command Line Tools which need reinstalling.


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] R CMD check "HTML version of manual" NOTE/Warnings

[Prof Brian Ripley]

On 25/04/2022 20:04, John Fox wrote:

Dear R-sig-mac list members,

When checking packages --as-cran with R 4.2.0 (and R 4.2.0 patched), I'm 
seeing multiple warnings (and a NOTE) concerning the HTML version of the 
package help-page manuals. The warning appears for every .Rd file in all 
of the packages that I've checked. I didn't see this problem before R 
4.2.0.


I'm writing to the r-sig-mac list rather than r-package-devel because I 


Unfortunately the authors of this are not on r-sig-mac.

don't encounter the same problem under Windows. Nor does it appear on 
the CRAN check pages for the packages.


This check is only done if you have 'tidy' on the path.  My Monterey M1 
MBP has


auk2% tidy --version
HTML Tidy for Mac OS X released on 31 October 2006 - Apple Inc. build 2649

I think that is far too old.  The short answer is to ignore these, or 
update tidy (from http://binaries.html-tidy.org/) which (5.8.0) finds 
different issues for car that I do not see on Fedora (with 5.7.16).


Probably your Windows machine does not have tidy installed.

I know that there's been discussion of adding an HTML manual, which 
seems a good idea, but I didn't realize that this has apparently already 
been implemented.


Has anyone else experienced this problem or does anyone understand its 
source? AFAIK, there's nothing unusual about the R installation on my 
Mac, but of course there may be some setting that inadvertently turned 
on checking the HTML manual.


--as-cran turned it on ((f tidy is available).




Here's an example (with many lines elided, . . .):

-- snip --

Johns-MacBook-Pro:car johnfox$ R CMD check --as-cran car_3.0-13.tar.gz
* using log directory 
'/Users/johnfox/Documents/R-package-sources/car/car.Rcheck'

* using R version 4.2.0 Patched (2022-04-24 r82246)
* using platform: aarch64-apple-darwin20 (64-bit)
* using session charset: UTF-8
* using option '--as-cran'
* checking for file 'car/DESCRIPTION' ... OK
* this is package 'car' version '3.0-13'
* checking CRAN incoming feasibility ... Note_to_CRAN_maintainers
Maintainer: 'John Fox '
* checking package namespace information ... OK

. . .

* checking PDF version of manual ... OK
* checking HTML version of manual ... NOTE
Found the following problems:
Anova.Rd:4:1: Warning:  inserting "type" attribute
Anova.Rd:12:1: Warning: 

Re: [R-SIG-Mac] Error identifying system version in sessionInfo()

[Prof Brian Ripley]

On 13/01/2022 18:32, Rohde, Maximilian D wrote:

Hello,

I have encountered a bug that I have documented here: 
https://stackoverflow.com/questions/70690684/wrong-session-info-in-when-knitting-in-r-markdown?noredirect=1#comment124971021_70690684

In brief, the issue is that running the `sessionInfo()` function in a terminal 
session of R gives the wrong operating system for my computer. I am running 
Monterey 12.1, but it returns Big Sur 10.16. However, running the same command 
in the RStudio console gives the correct operating system.

I have narrowed down the problem to this command giving different output depending 
on if it is run in RStudio or in the terminal: 
`readLines("/System/Library/CoreServices/SystemVersion.plist”)`

Any help is appreciated, thank you!


This is documented!  ?sessionInfo says

 Where R was compiled under macOS 10.x (as the CRAN Intel
 distributions have been) but running under ‘Big Sur’ or later,
 macOS reports itself as ‘10.16’ (which R recognizes as ‘Big
 Sur/Monterey’) and not ‘11.x’ or ‘12.x’.

This is a bug in macOS, not in R.





Best,
Max

[[alternative HTML version deleted]]


Please follow the posting guide, do your own homework and not send HTML.



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



--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] .Machine differences between Intel and M1

[Prof Brian Ripley]

On 21/12/2021 20:46, Simon Urbanek wrote:

Matt,

yes, arm64 does not support long doubles. In C the long double type is 64-bit 
there so has the same precision as doubles (this is allowed by the standard).


And documented in ?.Machine.

However, I see on my M1 Pro


capabilities("long.double")

long.double
  FALSE

on all the arm64 builds I have installed, including the current CRAN 
distribution (of 4.1.2) and that at mac.r-project.org (see below).  So I 
have no idea why TRUE is reported below (if this really was an arm64 
build run on the M1 Pro).


R version 4.1.2 Patched (2021-12-16 r81394) -- "Bird Hippie"
...
> capabilities('long.double')
long.double
  FALSE



Cheers,
Simon



On Dec 22, 2021, at 9:21 AM, Matthew Heun via R-SIG-Mac 
 wrote:

All:

I'm seeing some test failures on a new M1 Pro machine that I do not see on my 
Intel machine.  I'm investigating whether the test failures are caused by 
machine precision differences.  On my M1 Pro machine, differences of large 
numbers are greater than a specified tolerance.  (On my Intel machine, 
differences between the supposed same numbers are within tolerance.)


A small number of packages (and R itself) have needed tolerances 
increased for checks on arm64.




The output of .Machine shows some differences.  I have 2 questions below, each identified 
by "".

(1) For sizeof.longdouble, I see the following:

Intel machine:


$sizeof.longdouble
[1] 16


M1 Pro machine:


$sizeof.longdouble
[1] 8




?.Machine says:

sizeof.longdouble   
the number of bytes in a C long double type. Will be zero if there is no such 
type (or its use was disabled when R was built), otherwise possibly12 (most 
32-bit builds) or 16 (most 64-bit builds).

The M1 Pro uses a 64-bit architecture.  So this result is surprising to me.

Furthermore,


capabilities("long.double")

long.double
   TRUE


So somebody thinks that long doubles are supported.

 Is the difference in sizeof.longdouble between the Intel and M1 
architectures expected?


(2) Also, my M1 Pro machine is missing additional fields (that the Intel 
machine reports):


$longdouble.eps
[1] 1.084202e-19

$longdouble.neg.eps
[1] 5.421011e-20

$longdouble.digits
[1] 64

$longdouble.rounding
[1] 5

$longdouble.guard
[1] 0

$longdouble.ulp.digits
[1] -63

$longdouble.neg.ulp.digits
[1] -64

$longdouble.exponent
[1] 15

$longdouble.min.exp
[1] -16382

$longdouble.max.exp
[1] 16384


 Is there a reason why the above entries are missing from the output of 
.Machine on the M1 Pro machine?



My R installation is:  4.1.2 Patched (2021/12/16, r81394)



Any help will be appreciated.



Cheers,

Matt



--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] Strange C/C++ Compile Errors

[Prof Brian Ripley]

You have not shown us the compiler command line used, nor made a 
reproducible example available (and we might need both).


The suspicious line is

> In file included from ./include/stdlib.h:36:

It looks like you may have a file in the package which is masking a 
system header, but we don't have any information to go on.



On 14/12/2021 13:06, Wheeler, Matt (NIH/NIEHS) [E] via R-SIG-Mac wrote:

I hope someone can help me with my C++/Rcpp compile issue. I am building a 
package, which will eventually be on CRAN, but I am currently looking to have 
it available to collaborators who use macOS. I have successfully compiled it 
for Linux and Windows (it passes the CRAN checks), but I have had no such luck 
for macOS. Here, I get strange compile errors based upon namespaces. For 
example, the first two errors are below:



In file included from RcppExports.cpp:4:

In file included from 
/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/RcppGSL/include/RcppGSL.h:25:

In file included from 
/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/RcppGSL/include/RcppGSLForward.h:24:

In file included from 
/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/Rcpp/include/RcppCommon.h:30:

In file included from 
/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/Rcpp/include/Rcpp/r/headers.h:66:

In file included from 
/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/Rcpp/include/Rcpp/platform/compiler.h:100:

In file included from 
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/cmath:308:

In file included from 
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/math.h:308:

In file included from ./include/stdlib.h:36:

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/cstdlib:99:9:
 error: no member named 'size_t' in the global namespace

using ::size_t;



In file included from RcppExports.cpp:4:

In file included from 
/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/RcppGSL/include/RcppGSL.h:25:

In file included from 
/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/RcppGSL/include/RcppGSLForward.h:24:

In file included from 
/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/Rcpp/include/RcppCommon.h:30:

In file included from 
/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/Rcpp/include/Rcpp/r/headers.h:66:

In file included from 
/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/Rcpp/include/Rcpp/platform/compiler.h:153:

In file included from 
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/unordered_map:435:

In file included from 
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/__hash_table:15:

In file included from 
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/memory:673:

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/new:319:5:
 error: no member named 'posix_memalign' in the global namespace

  ::posix_memalign(&__result, __alignment, __size);

  ~~^

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/new:330:5:
 error: reference to unresolved using declaration

  ::free(__ptr);



Essentially, all of the errors are based upon namespace issues.

I have seen that having a ~/.R/Makevars file messes things up, so I emptied 
that directory. I further have no h files in '/usr/local/include,'

which will cause other build errors (i.e. I use NLOPT and GSL), but I want to 
get through this right now. Based upon other threads, I have the following for 
Xcode:



%xcode-select -p

/Library/Developer/CommandLineTools

%xcrun --show-sdk-path

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk

%which clang

/usr/bin/clang



Now, this is happening on two Macs. The first is an M1 with macOS Monterey 
12.01, and I got it with a clean IT build. The second is the one I use for 
work. It is an Intel using Catalina 10.15.7 (19H1519). I can understand why the 
second one may be messed up. When the issue occurred almost a year ago, I was 
in a research phase, couldn't figure out the solution, installed brew gcc and 
had R compile with this 'nonstandard' compiler with many no-no hacks. It was a 
hack, but it worked. Now, I need to distribute this to the masses, and it is 
still not working on a fresh machine and a newer version of macOS. Before I go 
further, I want to see if there is some setup issue on my machine(s), possibly 
something I need to talk about to IT.



Further, the file RcppExports.cpp is automatically generated in Rcpp, so I 
don't think it is a code issue, but it is a dependency issue with clang, but 
here I am not knowledgeable enough to fix. Quite honestly, Apple�s compiler 
setup is baffling, but I am used to /usr/include/ etc.   I can also compile 
Rcpp from source code, and I have compiled other packages on these machines.



Thanks 

Re: [R-SIG-Mac] Reverse search not working in ARM binary of R-4.1.2 (or 4.1.0) from CRAN

[Prof Brian Ripley]

On 09/12/2021 17:13, Ziv Wolkowicki wrote:

Team,

I have an unusual issue I am only observing on specific binaries of R. I used to have 
ARM build of R-4.1.0 from https://cran.r-project.org/bin/macosx/ 
, and updated to R-4.1.2 running on my 
M1 Mac. Hitting ‘Ctrl+R’ (reverse search of previously run commands) did nothing on 
either version. It does not react in any way. Though it reacts to Ctrl+C for example, 
so it is respond to some signals.


Hmm, what does extSoftversion() say? I see

readline
 "4.2 (EditLine wrapper)"

So it is not using readline, and it is that which supports Ctrl-R (which 
is not a signal).  This is all in the R-admin manual for you to read 



The unusual thing is, installing the ARM version for R-4.1.2 from homebrew, and also 
the x86 Mac build of R-4.1.2 from https://cran.r-project.org/bin/macosx/ 
, Ctrl+R works just fine.


Whereas the Intel (x86_64, sic) build is built with readline.  My guess 
is that Homebrew's R was too, but extSoftversion() would tell you -- 
OTOH last time I looked it was built without cairo support.  (But 
Homebrew is not supported here.)



I still have both homebrew and pre-packaged versions installed on my system if 
you need some additional information or experiments run.

Thanks,
Ziv


[[alternative HTML version deleted]]


Please do as the posting guide asked and not send HTNL (so we don't have 
to decipher doubled URLs).


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] Nightly build segfaults

[Prof Brian Ripley]

On 17/11/2021 19:32, Gábor Csárdi wrote:

On Wed, Nov 17, 2021 at 8:14 PM Prof Brian Ripley  wrote:
[...]

With the tarball I get a popup telling me

“R.framework” cannot be opened because the developer cannot be verified.


Interesting. I am on 12.0.1 and there is no popup, but there is a
crash report with

Exception Type:EXC_BAD_ACCESS (SIGKILL (Code Signature Invalid))

Possibly the popup was added in 12.1 beta.


I am running 12.0.1.


[...]

The .pkg I tried is unsigned/not notarized so cannot be installed, not
even with 'Open With'.  But packages are at least sometimes signed.


FWIW I did some local builds on a Big Sur machine with Xcode 12.x with
the same settings as the CRAN builds (for readline support primarily),
and those (https://files.r-hub.io/macos/readline/) work fine on
Monterey as well.


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] Nightly build segfaults

[Prof Brian Ripley]

On 17/11/2021 07:17, Prof Brian Ripley wrote:

On 16/11/2021 22:28, Gábor Csárdi wrote:

This is Monterey:
❯ uname -a
Darwin Gabors-MacBook-Pro-3.local 21.1.0 Darwin Kernel Version 21.1.0:
Wed Oct 13 17:33:01 PDT 2021; root:xnu-8019.41.5~1/RELEASE_ARM64_T6000
arm64

The R-devel build segfaults:

❯ curl -O https://mac.r-project.org/monterey/R-devel/arm64/R-devel.tar.gz
❯ sudo tar xzf R-devel.tar.gz -C /
❯ R -q --vanilla
zsh: killed R -q --vanilla


That is not a segfault, although they have been seen to cause this 
behaviour.  It more often indicates a security issue: arm64 macOS is 
prone to doing so with incremental rebuilds of R that it thinks have 
been tampered with.


With the tarball I get a popup telling me

“R.framework” cannot be opened because the developer cannot be verified.

Try installing the .pkg.  (Downloading from mac.r-project.org is far too 
slow at the moment for me to do so, but I recall past troubles with the 
tarballs not seen with Installer packages.)


And this evening downloads took a few seconds rather then the 2h 
predicted when I wrote that.


The .pkg I tried is unsigned/not notarized so cannot be installed, not 
even with 'Open With'.  But packages are at least sometimes signed.






So does the R-4.1 build:

❯ curl -O 
https://mac.r-project.org/monterey/R-4.1-branch/arm64/R-4.1-branch.tar.gz

❯ sudo tar xzf R-4.1-branch.tar.gz -C /
❯ R -q --vanilla
zsh: killed R -q --vanilla

The big-sur arm64 builds at
https://mac.r-project.org/big-sur/R-devel/arm64/R-devel.tar.gz
and 
https://mac.r-project.org/big-sur/R-4.1-branch/arm64/R-4.1-branch.tar.gz

also do the same.

I know that another user has seen this as well, so chances are that it
is not some issue on my machine. Can anyone reproduce this?

Gabor







--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] Nightly build segfaults

[Prof Brian Ripley]

On 16/11/2021 22:28, Gábor Csárdi wrote:

This is Monterey:
❯ uname -a
Darwin Gabors-MacBook-Pro-3.local 21.1.0 Darwin Kernel Version 21.1.0:
Wed Oct 13 17:33:01 PDT 2021; root:xnu-8019.41.5~1/RELEASE_ARM64_T6000
arm64

The R-devel build segfaults:

❯ curl -O https://mac.r-project.org/monterey/R-devel/arm64/R-devel.tar.gz
❯ sudo tar xzf R-devel.tar.gz -C /
❯ R -q --vanilla
zsh: killed R -q --vanilla


That is not a segfault, although they have been seen to cause this 
behaviour.  It more often indicates a security issue: arm64 macOS is 
prone to doing so with incremental rebuilds of R that it thinks have 
been tampered with.


Try installing the .pkg.  (Downloading from mac.r-project.org is far too 
slow at the moment for me to do so, but I recall past troubles with the 
tarballs not seen with Installer packages.)




So does the R-4.1 build:

❯ curl -O 
https://mac.r-project.org/monterey/R-4.1-branch/arm64/R-4.1-branch.tar.gz
❯ sudo tar xzf R-4.1-branch.tar.gz -C /
❯ R -q --vanilla
zsh: killed R -q --vanilla

The big-sur arm64 builds at
https://mac.r-project.org/big-sur/R-devel/arm64/R-devel.tar.gz
and https://mac.r-project.org/big-sur/R-4.1-branch/arm64/R-4.1-branch.tar.gz
also do the same.

I know that another user has seen this as well, so chances are that it
is not some issue on my machine. Can anyone reproduce this?

Gabor




--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] ANSI escape weirdness on M1 (libedit issue?)

[Prof Brian Ripley]

On 03/11/2021 12:21, Gábor Csárdi wrote:

Anyone else noticed some weirdness with the arm build when the prompt
has ANSI escape codes?

E.g. in a terminal run this
options(prompt = "\033[1m> \033[0m")

and then at the new prompt type in some longer word and press CTRL+A.


Longer than what?


The cursor does not go back to the beginning of the line, probably
because the width of the prompt is not calculated correctly by the
underlying system library.

readline is not listed at https://mac.r-project.org/libs-arm64/ while
it is listed among the intel libs. Does that mean that R uses libedit
on arm64? Is this an issue with libedit?


This is why we added extSoftversion(): please use it.

For my personal build of R-patched (which uses readline 8.1) this works 
as I expected.  With the CRAN build of 4.1.2 I do see some weirdness, e.g.


> options(prompt = "\033[1mR> \033[0m")
R> abcdef

where after the Ctrl-A the cursor moves forwards a couple of characters. 
 (That 'R>' is bold will not show up in an email.


All on Monterey 12.0.1.

AFAIK the reason for not distributing readline with binary distributions 
of R is perceived licence restrictions.


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

[R-SIG-Mac] Java 17 builds

[Prof Brian Ripley]

The current version of Java is 17: this has 'long term support' and is 
the first to officially support M1 macs.


Mac-friendly installers are now available from https://adoptium.net for 
Intel (which they call x64) and M1 (aarch64).  Unlike builds available 
from jdk.java.net and Zulu these install into Apple-standard locations 
and so are found by /usr/bin/java.


Not all CRAN packages work with Java 17: there are additional security 
measures and XLConnect excludes it.  The maintainers have been informed 
so hopefully this will change soon.


On Intel I would keep on using Java 11 (also available from Adoptium, 
formerly AdoptOpenJDK).  On M1, the Adoptium build of 17 makes things 
much cleaner.


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] Tcl/Tk issues in arm64 build of R 4.1.0

[Prof Brian Ripley]

On 09/09/2021 19:03, John Fox wrote:

Dear Simon, Philippe, and list members,

I've encountered some Tcl/Tk-related issues with the Apple silicon arm64 
build of R 4.1.0 for macOS. These issues affect the Rcmdr package, 
although they don't prevent it from working:


(1) Some fonts that are available for the Intel build appear to be 
missing from the arm64 build. Compare the screen shots of the Rcmdr main 
window at 
 
(Intel build) and 
 
(arm64 build). This problem is purely aesthetic.


(2) The Tcl/Tk Tktable package is apparently absent from the arm64 build 
but still present in the Intel build. The Rcmdr detects its absence and 
suppresses some features (i.e., those requiring the Rcmdr data editor). 
I understand that the Tktable package is problematic and it may have 
been removed intentionally.


The Tcl/Tk Tablelist package would be a reasonable substitute, and were 
it available, I could use it to restore the missing features in the 
Rcmdr. I'm aware that Philippe Grosjean planned to incorporate Tablelist 
in his tcltk2 package, but as far as I know, that plan hasn't yet 
materialized. If I knew how to supply a Tcl/Tk package in an R package, 
I could put Tablelist directly in the Rcmdr.


Any help would be greatly appreciated.

John


To close this circle, Simon has provided

https://mac.r-project.org/libs-arm64/tcltk-8.6.11-xft-darwin20.4-arm64.pkg

If you install that, it updates Tk and adds Tktable, solving both 
problems.  (As the Tcl/Tk installation is shared between R versions, 
this will fix 4.1.0 as well as 4.1.1.  It will be incorporated in future 
releases.)





--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] Tcl/Tk issues in arm64 build of R 4.1.0

[Prof Brian Ripley]

On 09/09/2021 19:59, Prof Brian Ripley wrote:

On 09/09/2021 19:03, John Fox wrote:

Dear Simon, Philippe, and list members,


...

(2) The Tcl/Tk Tktable package is apparently absent from the arm64 
build but still present in the Intel build. The Rcmdr detects its 
absence and suppresses some features (i.e., those requiring the Rcmdr 
data editor). I understand that the Tktable package is problematic and 
it may have been removed intentionally.


https://sourceforge.net/projects/tktable/files/tktable/2.10/Tktable2.10.tar.gz 
(apparently the latest version from 2008)
does not compile against recent Tcl/Tk (8.6.11 seems to be used): it 
uses 'panic' which should be 'Tcl_Panic'.    (The Intel build appears to 
be much older, 8.6.6.)


I have a patched version: AFAICS it installs entirely into 
/opt/R/arm64/lib I could tar it up and make it available.


I could also send the patch to Simon for future use, but note that 
https://mac.r-project.org/libs-arm64/ contains an aqua build of Tcl/Tk 
(not the X11 build in the CRAN build of R 4.1.[01]) and which does not 
support Tcl/Tk.


I have put the patch and the tarball at 
https://www.stats.ox.ac.uk/pub/bdr/Tktable/ .


There is a README.txt with installation instructions. But as I have only 
one M1 Mac, they are minimally tested.


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] Tcl/Tk issues in arm64 build of R 4.1.0

[Prof Brian Ripley]

On 09/09/2021 21:34, John Fox wrote:

Dear Brian,

Thank you for responding so quickly. Please see below:
On 2021-09-09 2:59 p.m., Prof Brian Ripley wrote:

On 09/09/2021 19:03, John Fox wrote:

Dear Simon, Philippe, and list members,

I've encountered some Tcl/Tk-related issues with the Apple silicon 
arm64 build of R 4.1.0 for macOS. These issues affect the Rcmdr 
package, although they don't prevent it from working:


(1) Some fonts that are available for the Intel build appear to be 
missing from the arm64 build. Compare the screen shots of the Rcmdr 
main window at 
<https://socialsciences.mcmaster.ca/jfox/.Pickup/x86_64-apple-darwin17.0.png> 
(Intel build) and 
<https://socialsciences.mcmaster.ca/jfox/.Pickup/aarch64-apple-darwin20.png> 
(arm64 build). This problem is purely aesthetic.


It would be helpful to know what those fonts are.  This is likely to 
be a fontconfig issue and needs to be debugged by name.


I query the Tk default and fixed-width fonts via

 tclvalue(.Tcl("font actual TkDefaultFont -family")
 tclvalue(.Tcl("font actual TkFixedFont -family"))

and use those -- in the past, that produced pleasing font choices on all 
platforms. In the macOS Intel build, the resulting font families are 
"Verdana" and "Andale Mono"; in the arm64 build, "helvetica" and 
"courier". Perhaps the Intel and arm64 builds were just configured 
differently.


Yes, I think fontconfig was, and that may help Simon dig into this.



(2) The Tcl/Tk Tktable package is apparently absent from the arm64 
build but still present in the Intel build. The Rcmdr detects its 
absence and suppresses some features (i.e., those requiring the Rcmdr 
data editor). I understand that the Tktable package is problematic 
and it may have been removed intentionally.


https://sourceforge.net/projects/tktable/files/tktable/2.10/Tktable2.10.tar.gz 
(apparently the latest version from 2008)
does not compile against recent Tcl/Tk (8.6.11 seems to be used): it 
uses 'panic' which should be 'Tcl_Panic'.    (The Intel build appears 
to be much older, 8.6.6.)


I have a patched version: AFAICS it installs entirely into 
/opt/R/arm64/lib I could tar it up and make it available.


I could also send the patch to Simon for future use, but note that 
https://mac.r-project.org/libs-arm64/ contains an aqua build of Tcl/Tk 
(not the X11 build in the CRAN build of R 4.1.[01]) and which does not 
support Tcl/Tk.


I'm sorry, but I don't quite understand that -- perhaps there's a typo 
here? Do you mean to say that an aqua build of Tcl/Tk will replace the 
X11 build after R 4.1.1, and that Tktable will be incompatible with it?


There was, so let me expand.

There are two Tk implementations on macOS,

- using aqua, which is included in https://mac.r-project.org/libs-arm64/
- using X11, included in the CRAN distributions of R 4.1.[01] on amd64, 
and always used for Intel. So I do not have access to the details of 
that build.


As I recall, TkTable does not install for the aqua implementation, but 
does (when patched) for the X11 implementation.  My recollection is that 
XQuartz became available for amd64 not long before R 4.0.0 and Simon 
switched to X11 Tk, although pre-releases had aqua Tk.


If so, first, I think that an aqua Tcl/Tk would be preferable to the 
current X11 version. If I understand correctly, for example, aqua would 
put Tk menus where Mac users expect them.


aqua Tk does not work correctly with R.app, and is not supported by 
package tkrplot (which lots of other packages depend on).  Personally I 
usually use aqua Tk in my own builds, but then I only use R.app if 
needed to debug something.


Second, given the problems that Tktable seems to be producing, wouldn't 
it be better to make Tablelist available as a substitute? I'm happy to 
rewrite the Rcmdr data editor using Tablelist (actually, it's mostly 
done), and, as I said, if I knew how to incorporate the Tcl/Tk Tablelist 
package in the Rcmdr package (if it's undesirable simply to make it 
available generally), I'd do it.


That's your choice.  The sources are at 
https://www.nemethi.de/tablelist/tablelist6.15.tar.gz and contain a 
README.txt with a 'How to Install It?'.  At least on a Unix-alike you 
just need to unpack that into somewhere on the Tcl path.  So to 
distribute with an R package, have the  tablelist6.15 dir in inst/ and 
arrange to add the installed location to the Tcl search path with 
tcltk::addTclPath() .  (I don't see why Windows would be different.)



--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] Tcl/Tk issues in arm64 build of R 4.1.0

[Prof Brian Ripley]

On 09/09/2021 19:03, John Fox wrote:

Dear Simon, Philippe, and list members,

I've encountered some Tcl/Tk-related issues with the Apple silicon arm64 
build of R 4.1.0 for macOS. These issues affect the Rcmdr package, 
although they don't prevent it from working:


(1) Some fonts that are available for the Intel build appear to be 
missing from the arm64 build. Compare the screen shots of the Rcmdr main 
window at 
 
(Intel build) and 
 
(arm64 build). This problem is purely aesthetic.


It would be helpful to know what those fonts are.  This is likely to be 
a fontconfig issue and needs to be debugged by name.


(2) The Tcl/Tk Tktable package is apparently absent from the arm64 build 
but still present in the Intel build. The Rcmdr detects its absence and 
suppresses some features (i.e., those requiring the Rcmdr data editor). 
I understand that the Tktable package is problematic and it may have 
been removed intentionally.


https://sourceforge.net/projects/tktable/files/tktable/2.10/Tktable2.10.tar.gz 
(apparently the latest version from 2008)
does not compile against recent Tcl/Tk (8.6.11 seems to be used): it 
uses 'panic' which should be 'Tcl_Panic'.(The Intel build appears to 
be much older, 8.6.6.)


I have a patched version: AFAICS it installs entirely into 
/opt/R/arm64/lib I could tar it up and make it available.


I could also send the patch to Simon for future use, but note that 
https://mac.r-project.org/libs-arm64/ contains an aqua build of Tcl/Tk 
(not the X11 build in the CRAN build of R 4.1.[01]) and which does not 
support Tcl/Tk.





--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] checking whether the C compiler works... no

[Prof Brian Ripley]

On 06/09/2021 08:43, Naresh Gurbuxani wrote:

When trying to install library reshape2, I get below messages.  But I do have 
some other packages which depend upon C compiler (e.g., Rcpp).  How can this 
problem be fixed?


You need to look in the config.log file.  The easiest way to make sure 
that is kept is to download the stringi source tarball, unpack it and 
run R CMD INSTALL stringi .




Thanks,
Naresh

Messages when trying to install reshape2:

install.packages("reshape2", repos = "https://cran.r-project.org;)

Installing package into ‘/usr/local/lib/R/4.1/site-library’
(as ‘lib’ is unspecified)
also installing the dependencies ‘stringi’, ‘stringr’

trying URL 'https://cran.r-project.org/src/contrib/stringi_1.7.4.tar.gz'
Content type 'application/x-gzip' length 7599762 bytes (7.2 MB)
==
downloaded 7.2 MB

trying URL 'https://cran.r-project.org/src/contrib/stringr_1.4.0.tar.gz'
Content type 'application/x-gzip' length 135777 bytes (132 KB)
==
downloaded 132 KB

trying URL 'https://cran.r-project.org/src/contrib/reshape2_1.4.4.tar.gz'
Content type 'application/x-gzip' length 37307 bytes (36 KB)
==
downloaded 36 KB

* installing *source* package ‘stringi’ ...
** package ‘stringi’ successfully unpacked and MD5 sums checked
** using staged installation
checking for R_HOME... /usr/local/Cellar/r/4.1.1/lib/R
checking for R... /usr/local/Cellar/r/4.1.1/lib/R/bin/R
checking for endianness... little
checking for R >= 3.1.0 for C++11 use... yes
checking for R < 3.4.0 for CXX1X flag use... no
checking for cat... /bin/cat
checking for local ICUDT_DIR... icu69/data
checking for gcc... /usr/local/opt/llvm/bin/clang -fopenmp
checking whether the C compiler works... no
configure: error: in 
`/private/var/folders/97/5377j5_d207fshvjz_pz7szwgn/T/RtmpCOKBRx/R.INSTALL64822d9c75a/stringi':
configure: error: C compiler cannot create executables
See `config.log' for more details
ERROR: configuration failed for package ‘stringi’
* removing ‘/usr/local/lib/R/4.1/site-library/stringi’
ERROR: dependency ‘stringi’ is not available for package ‘stringr’
* removing ‘/usr/local/lib/R/4.1/site-library/stringr’
ERROR: dependency ‘stringr’ is not available for package ‘reshape2’
* removing ‘/usr/local/lib/R/4.1/site-library/reshape2’

The downloaded source packages are in

‘/private/var/folders/97/5377j5_d207fshvjz_pz7szwgn/T/RtmpDOExfD/downloaded_packages’
Warning messages:
1: In install.packages("reshape2", repos = "https://cran.r-project.org;) :
   installation of package ‘stringi’ had non-zero exit status
2: In install.packages("reshape2", repos = "https://cran.r-project.org;) :
   installation of package ‘stringr’ had non-zero exit status
3: In install.packages("reshape2", repos = "https://cran.r-project.org;) :
   installation of package ‘reshape2’ had non-zero exit status

My session info:

sessionInfo()

R version 4.1.1 (2021-08-10)
Platform: x86_64-apple-darwin20.5.0 (64-bit)
Running under: macOS Big Sur 11.5.2

Matrix products: default
BLAS/LAPACK: /usr/local/Cellar/openblas/0.3.17/lib/libopenblasp-r0.3.17.dylib

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

loaded via a namespace (and not attached):
[1] compiler_4.1.1 tools_4.1.1


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




--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] R-SIG-Mac Digest, Vol 221, Issue 14

[Prof Brian Ripley]

On 27/08/2021 19:25, Jan de Leeuw wrote:

OS

System Version: macOS 12.0 (21A5304g)
Kernel Version: Darwin 21.0.0

sessionInfo (CRAN binary)

R version 4.1.1 (2021-08-10)
Platform: x86_64-apple-darwin17.0 (64-bit)
Running under: macOS Big Sur 10.16


Thanks.





On Aug 27, 2021, at 03:00, r-sig-mac-requ...@r-project.org wrote:

sessionInfo on Monterey (Prof Brian Ripley)


--
Jan de Leeuw, Distinguished Professor Emeritus, UCLA Statistics
https://jansweb.netlify.app  https://github.com/deleeuw
--
Remember, no matter where you go, there you are. (Buckaroo Banzai)












[[alternative HTML version deleted]]

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




--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

[R-SIG-Mac] sessionInfo on Monterey

[Prof Brian Ripley]

One oddity is that the CRAN Intel binary build of R (or any other built 
under 10.x) when run on Big Sur reports


> sessionInfo()
R version 4.1.1 (2021-08-10)
Platform: x86_64-apple-darwin17.0 (64-bit)
Running under: macOS Big Sur 10.16
...

because the system call used reports '10.16'.

If anyone running a beta of Monterey has the CRAN binary installed, for 
completeness I would appreciate seeing what is reported.


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] rgl in R version 4.1.1 Patched (2021-08-13 r80752)

[Prof Brian Ripley]

On 19/08/2021 04:56, Richard M. Heiberger wrote:

  R version 4.1.1 Patched (2021-08-13 r80752)
  aarch64-apple-darwin20


library(rgl)

Error in dyn.load(dynlib <- getDynlib(dir)) :
   unable to load shared object 
'/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/rgl/libs/rgl.so':
   
dlopen(/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/rgl/libs/rgl.so,
 6): Symbol not found: _hb_buffer_add_utf8
   Referenced from: 
/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/rgl/libs/rgl.so
   Expected in: flat namespace
  in 
/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/rgl/libs/rgl.so


This is short of details: where did you get that R from and how did you 
install rgl?


My best guess is that that the CRAN binary package needs rebuilding (and 
maybe others that use freetype2).  It seems that rgl does not itself 
link to libfreetype2, and in recent builds that depends on libharfbuzz 
(my guess being that 4.1.0 was not using such a build. 4.1.1 is).


A source-package install would probably work if you get the libs needed 
from https://mac.r-project.org/libs-arm64/.


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] sf installation problem under Mac OS 11 - Big Sur

[Prof Brian Ripley]

On 18/08/2021 23:52, Michal Ben-Nun wrote:

Hi,

I installed R 4.10 on my Mac OS 11.3.1


Presumably R 4.1.0.


I am trying to install 'sf' and 'rgdal'


From the mailing list I understood that this command should work:


install.packages(c("rgdal","sf"),,"https://mac.R-project.org
")

However I am still getting an error, see below.

Any suggestions would be welcome.

Thanks,
Michal

p.s. I am using macports NOT brew


Asking on R-sig-geo would be appropriate as macports/Homebrew are 
generic Unix-alike systems.


Hint: rgdal has

SystemRequirements: PROJ (>= 4.8.0, https://proj.org/download.html) and 
GDAL (>= 1.11.4, https://gdal.org/download.html), with versions either 
(A) PROJ < 6 and GDAL < 3 or (B) PROJ >= 6 and GDAL >= 3.


and it seems you have not installed PROJ






install.packages(c("rgdal","sf"),,"https://mac.R-project.org;)

Installing packages into ‘/Users/michal/Library/R/x86_64/4.1/library’
(as ‘lib’ is unspecified)
trying URL 'https://mac.R-project.org/src/contrib/rgdal_1.5-23.tar.gz'
Content type 'application/octet-stream' length 4393536 bytes (4.2 MB)
==
downloaded 4.2 MB

trying URL 'https://mac.R-project.org/src/contrib/sf_1.0-2.tar.gz'
Content type 'application/octet-stream' length 3645982 bytes (3.5 MB)
==
downloaded 3.5 MB

* installing *source* package ‘rgdal’ ...
** package ‘rgdal’ successfully unpacked and MD5 sums checked
** using staged installation
configure: R_HOME: /opt/local/Library/Frameworks/R.framework/Resources
configure: CC: /opt/local/bin/clang-mp-12
configure: CXX: /opt/local/bin/clang++-mp-12 -std=gnu++14
configure: CFLAGS: -pipe -Os
-isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk -arch x86_64
configure: CPPFLAGS: -I/opt/local/include
-isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk
configure: CXXFLAGS: -pipe -Os -stdlib=libc++
-isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk -arch x86_64
configure: LDFLAGS: -L/opt/local/lib -Wl,-headerpad_max_install_names
-Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk -arch
x86_64
configure: LDFLAGS: -L/opt/local/lib -Wl,-headerpad_max_install_names
-Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk -arch
x86_64
configure: CXX11 is: /opt/local/bin/clang++-mp-12, CXX11STD is: -std=gnu++11
configure: CXX is: /opt/local/bin/clang++-mp-12 -std=gnu++11
configure: C++11 support available
configure: rgdal: 1.5-23
checking for /usr/bin/svnversion... no
configure: svn revision: 1121
checking for gdal-config... /opt/local/bin/gdal-config
checking gdal-config usability... yes
configure: GDAL: 3.3.0
checking GDAL version >= 1.11.4... yes
checking GDAL version <= 2.5 or >= 3.0... yes
checking GDAL: linking with --libs only... yes
checking GDAL: gdal-config data directory readable... yes
checking GDAL: /opt/local/share/gdal/stateplane.csv readable... yes
configure: pkg-config proj not available
   set PKG_CONFIG_PATH to the directory containing proj.pc
configure: PROJ version not determined using pkg-config proj
configure: PROJ CPP flags:  -I/opt/local/include
configure: PROJ LIBS:  -lproj
checking PROJ header API:... yes
configure: API to be used as yet undetermined, searching ...
configure: error: API to be used not found
ERROR: configuration failed for package ‘rgdal’
* removing ‘/Users/michal/Library/R/x86_64/4.1/library/rgdal’
* installing *source* package ‘sf’ ...
** package ‘sf’ successfully unpacked and MD5 sums checked
** using staged installation
configure: CC: /opt/local/bin/clang-mp-12
configure: CXX: /opt/local/bin/clang++-mp-12 -std=gnu++11
checking for gdal-config... /opt/local/bin/gdal-config
checking gdal-config usability... yes
configure: GDAL: 3.3.0
checking GDAL version >= 2.0.1... yes
checking for gcc... /opt/local/bin/clang-mp-12
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether /opt/local/bin/clang-mp-12 accepts -g... yes
checking for /opt/local/bin/clang-mp-12 option to accept ISO C89... none
needed
checking how to run the C preprocessor... /opt/local/bin/clang-mp-12 -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking gdal.h usability... yes
checking gdal.h presence... yes
checking for gdal.h... yes
checking GDAL: linking with --libs only... yes
checking GDAL: /opt/local/share/gdal/pcs.csv 

Re: [R-SIG-Mac] R pkg 4.1.1 no longer accepted as notarized by Apple

[Prof Brian Ripley]

On 13/08/2021 14:42, Eirik Thorsnes wrote:

Hi,

The R-4.1.1.pkg is not notarized:


And that has been reported and Simon has fixed it (online, and an 
updated .pkg is on its way to the CRAN main site for those without 
Internet access).  I was able to install the original .pkg on Thursday 
(but not Weds) and now get


% spctl -a -vvv -t install R-4.1.1.pkg
R-4.1.1.pkg: accepted
source=Notarized Developer ID




% spctl -a -vvv -t install R-4.1.1.pkg

R-4.1.1.pkg: rejected

source=Unnotarized Developer ID

origin=Developer ID Installer: Simon Urbanek (VZLD955F6P)

Whereas 4.1.0 looks good:

% spctl -a -vvv -t install R-4.1.0.pkg

R-4.1.0.pkg: accepted

source=Notarized Developer ID

origin=Developer ID Installer: Simon Urbanek (VZLD955F6P)

Regards,

Eirik

NORCE Norwegian Research Centre AS
norceresearch.no 




--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] In svg("tst.svg") : failed to load cairo DLL

[Prof Brian Ripley]

Install (or re-install) XQuartz.  As the R-admin manual §4 says

Various parts of the build require XQuartz to be installed: see 
https://www.xquartz.org/releases.  These include the tcltk package and 
the X11 device: attempting to use these without XQuartz will if possible 
remind you. This is also needed for some builds of the 
cairographics-based devices (which are not often used on macOS) such as 
png(type = "cairo").


svg() is a cairographics-based device .



On 06/08/2021 22:12, Spencer Graves wrote:

Hello:


   In R 4.1.0 under macOS 11.4, 'svg("tst.svg")' says, "failed to 
load cairo DLL".



   This works fine under Windows 10.  (I tested under RStudio 
1.4.1106, R terminal and R Console all with the same results.)



   The first time I try "svg('tst.svg')" in a new R session, I get a 
longer message;  see below for that and for sessionInfo().  When I 
repeat "svg('tst.svg')", I get only "failed to load cairo DLL".



   Suggestions?
   Thanks,
   Spencer Graves


svg('tst.svg')
Warning messages:
1: In grSoftVersion() :
   unable to load shared object 
'/Library/Frameworks/R.framework/Resources/modules//R_X11.so':
   dlopen(/Library/Frameworks/R.framework/Resources/modules//R_X11.so, 
6): Library not loaded: /opt/X11/lib/libSM.6.dylib
   Referenced from: 
/Library/Frameworks/R.framework/Versions/4.1/Resources/modules/R_X11.so

   Reason: image not found
2: In cairoVersion() :
   unable to load shared object 
'/Library/Frameworks/R.framework/Resources/library/grDevices/libs//cairo.so': 



dlopen(/Library/Frameworks/R.framework/Resources/library/grDevices/libs//cairo.so, 
6): Library not loaded: /opt/X11/lib/libXrender.1.dylib
   Referenced from: 
/Library/Frameworks/R.framework/Versions/4.1/Resources/library/grDevices/libs/cairo.so 


   Reason: image not found
3: In svg("tst.svg") : failed to load cairo DLL
 > sessionInfo()
R version 4.1.0 (2021-05-18)
Platform: x86_64-apple-darwin17.0 (64-bit)
Running under: macOS Big Sur 10.16

Matrix products: default
LAPACK: 
/Library/Frameworks/R.framework/Versions/4.1/Resources/lib/libRlapack.dylib


locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

loaded via a namespace (and not attached):
[1] compiler_4.1.0 tools_4.1.0
 >

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



--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] r-sig-mac@r-project.org - "You can’t open the application “R” because this application is not supported on this Mac"

[Prof Brian Ripley]

On 17/07/2021 21:38, Duncan Murdoch wrote:

On 17/07/2021 3:39 a.m., Lindsay Foreman wrote:

To whom it may concern,

I am so sorry for being such a dunce.  I have been trying and trying 
to get the R App to work on my MacBook Air running Big Sur V11.4, and 
am just not making any progress.  It says that the package I have 
downloaded below should have all the elements I need including the R 
app GUI.  I get this error message "You can’t open the application “R” 
because this application is not supported on this Mac"., are you able 
to help please?


Is that an Intel or M1 MacBook?  If it's an Intel one, you don't want 
the arm64 download, you want


https://cran.r-project.org/bin/macosx/base/R-4.1.0.pkg

It is listed on the web site as "High Sierra and higher", so it should 
work on Big Sur, but only if you have an Intel chip.


Yes, it works on Intel Big Sur.  Actually it works perfectly well on 
arm64 (aka M1) cpus, as documented in the R-admin manual and on 
https://cran.r-project.org/bin/macosx/ .


For those with arm64 Macs, the current pros and cons of the arm64 build are

Pro:
- It is usually faster, median 1.4x on CRAN packages but in some cases 
much more so.


- There have been very occasional Intel binary packages where Rosetta 
emulation does not work (and the arm64 binary package did).


Cons:
- Less accuracy as there are no long doubles.  That has surprisingly 
little impact, in part because CRAN packages have long been checked 
without long doubles.  But people who test sum(p) == 1 are more likely 
to be caught out 


- Fewer binary packages available, notably not from Bioconductor and 
hence CRAN packages requiring those from Bioconductor.


- In the vast majority of cases compiling packages from source will work 
(if sometimes a little trickier), but a handful of packages require 
Intel CPUs.  I have about 30 more CRAN packages failing their checks 
that for Intel builds, and about 40 than on Linux.


- Less stable.  This is as much the OS as R, with resource (e.g. RAM) 
shortages leading to hangs (of R or the whole machine) much more often 
than on an Intel Mac.  In fairly limited testing this happens more with 
the arm64 build than using the Intel build on my M1 Mac.


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] [External] Re: [External] Re: Mac M1 emacs

[Prof Brian Ripley]

On 08/03/2021 17:59, Richard M. Heiberger wrote:

I updated the OS to 11.2.2, again redownloaded the app
https://mac.r-project.org/libs-arm64/emacs-27.1-app-arm64-darwin20.dmg
and still get the damaged app message.


How did you download it?  That page and R-admin recommend using curl and 
when I did that it works for me, both running from the image and copying 
somewhere other than /Applications (as I have another Emacs there).


OTOH, I've not seen any problems with Vincent Goulet's Intel build on my 
M1 Mac.  The posting guide for this list does ask you not to use 'crash' 





I attempted Ctrl-Click Open (hoping to get past the app from untrusted source 
issue) and that also gave me the Damaged App message.

The next option they offer is
"
4: Use xattr on the App Throwing the Damaged Error
This is sort of a last resort and is only recommended for advanced Mac users. 
Generally speaking if the app is still throwing a ‘damaged’ error message you 
might want to not use it. Use this at your own risk.

With the command line you can use xattr to view and remove extended attributes 
from a file on the Mac including the application throwing the “Appname.app is 
damaged and can’t be opened. You should move it to the Trash.” error message.

Launch Terminal and then issue the following command:

xattr -cr /path/to/application.app
"
and I am not willing to do that.

Perhaps if I compile on my machine from your recipe, it might work.
I am a git novice, so I will need an explicit statement and instructions to try 
that.

Rich


From: R-SIG-Mac  on behalf of Richard M. Heiberger 

Sent: Monday, March 8, 2021 11:55
To: Simon Urbanek
Cc: r-sig-mac@r-project.org
Subject: Re: [R-SIG-Mac] [External] Re:  [External] Re:  Mac M1 emacs

I tried the all-purpose computer repair and rebooted the machine.  It still 
reports a damaged app.

I am now ooking at 
https://osxdaily.com/2019/02/13/fix-app-damaged-cant-be-opened-trash-error-mac/
and wi report back.


From: Richard M. Heiberger 
Sent: Monday, March 8, 2021 00:29
To: Simon Urbanek
Cc: r-sig-mac@r-project.org
Subject: Re: [External] Re: [R-SIG-Mac] [External] Re:  Mac M1 emacs

yes, I did.  that also gave the same message.

Also, the ~/Downloads and ~/Desktop directories are no longer available from 
the original intel Emacs (I changed
its name to Emacs-21.7-intel.app).
it says "access-files" are available.
This is familiar.  I had it before.  the answer is here, and it works.
https://emacs.stackexchange.com/questions/53904/why-cant-i-list-the-contents-of-desktop-on-macos-using-dired

I don't this this is the damage problem.
I have downloaded it three times from R-project and I get the same "damaged" 
problem each time.


From: Simon Urbanek 
Sent: Sunday, March 7, 2021 23:52
To: Richard M. Heiberger
Cc: r-sig-mac@r-project.org
Subject: Re: [External] Re: [R-SIG-Mac] [External] Re:  Mac M1 emacs

Did you try running it from the image? At which point does it complain? It 
works for me.
Note that macOS may not be happy if you mangle the content due to code signing, 
so you may want to move aside the old version first if you are putting it in 
/Applications.
Unfortunately I have only one M1 system, so I can't try it on another "clean" 
one to see if there are issues.

Cheers,
Simon



On Mar 8, 2021, at 5:43 PM, Richard M. Heiberger  wrote:

it claims to be damaged.

I looked it and the filenames and directory structure look ok.


From: Simon Urbanek 
Sent: Sunday, March 7, 2021 21:42
To: Richard M. Heiberger
Cc: r-sig-mac@r-project.org
Subject: [External] Re: [R-SIG-Mac] [External] Re:  Mac M1 emacs

Richard,

please note the binary supports mouse integration if you enable it (see Emacs 
documentation - ad-hoc: M-x xterm-mouse-mode).

Like I said, it is trivial to build the GUI version of you care - I have very 
explicitly disabled the GUI since I hate it personally (I want emacs to run in 
the terminal, not have it pop-up random windows). But you seem to think 
otherwise ;) so I have added the app build as well:
https://mac.r-project.org/libs-arm64/emacs-27.1-app-arm64-darwin20.dmg

Cheers,
Simon



On Mar 8, 2021, at 1:53 PM, Richard M. Heiberger  wrote:

Simon's binary works.  As he noted, it is missing mouse support.

I copied the entirety of
/Applications/Emacs.app/Contents/Resources/site-lisp
into
/opt/R/arm64/share/emacs/27.1/site-lisp

I turned off the request for mouse support in
site-lisp/site-start.el
by changing the first mouse line (line 47) to
(if (equal 'system-configuration "x86_64-apple-darwin18.7.0") (mouse-wheel-mode 
t)); activate mouse scrolling on intel


I opened Terminal and started emacs with
/opt/R/arm64/bin/emacs
It gives an ERROR:ess-etc-directory which I can ignore (it looks to me like the 
../etc is there).
it gives a warning about server which I am ignoring for now.

M-x R works.

Re: [R-SIG-Mac] BWidget (external software)

[Prof Brian Ripley]

On 09/02/2021 23:59, Manuel Spínola wrote:

Dear list members,

How can I install  the external package BWidget in R for macOS?


I believe you are asking about a Tcl/Tk package (not an R package): that 
is discussed in the R manuals and


https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Non_002dR-scripts-in-packages

gives installation instructions.

--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] [External] Behaviour or Quartz windows

[Prof Brian Ripley]

The quartz() device has nothing to so with XQuartz.  Quartz is part of 
macOS: https://en.wikipedia.org/wiki/Quartz_(graphics_layer)


Using XQuartz betas is not supported: it is very unfortunate that they 
are persuading users to install a beta version.


You have not followed the posting guide and posted the sessionInfo(). 
We are left to guess that you are using an Intel build of R under 
emulation, but homebrew does have (a rather broken) arm64 build of R 
4.0.3: we do not support arm64 builds on R < 4.1.0.  My understanding is 
that in the CRAN release of R 4.0.3 only the X11() device and parts of 
Tk interact with XQuartz, although other parts may in other builds.


On 09/02/2021 17:33, Richard M. Heiberger wrote:

Is R on M1 really talking to the REAL XQuartz?  After I opened XQuartz from the 
spotlignt, it acknowledged the xterm window, but not the R graphics window.  
When I closed the XQuartz
app, the R graphics window was still open and functioning.  dev.cur() says 
"quartz".

just checked on my older intel mac.  same behavior.  the Xquartz.app menu 
doesn't list
the R graphics window, and the R graphics shows "...", not "XQuartz" in the 
menu bar.


From: R-SIG-Mac  on behalf of Richard M. Heiberger 

Sent: Tuesday, February 9, 2021 11:56 AM
To: Peter West; r-sig-mac@r-project.org
Subject: Re: [R-SIG-Mac] [External]  Behaviour or Quartz windows

When I draw a 9x7 panel lattice it displays 12 panels, then sits there until I 
resize the window. then the rest appears.  When I display another 9x7, it too 
sits at 12 panels.
When I Cmd-left for the previous display, the current one vanishes entirely.
When I send the command again, after it sits I resize the window.  Now the full 
second display
is visible.  When I Cmd-left followed by Cmd-right, the second display is lost.

I am using R version 4.0.3 (2020-10-10) on Silicon Mac Big Sur 11.1 from inside 
ESS.

XQuartz doesn't report correctly.  On the MenuBar it doesn't say "XQuartz".  
Instead it shows a
small Apple Icon which has no information when clicked.  When I search using 
the MenuBar Spotlight icon, it tells me Xquartz 2.8.0_beta1 and offers to 
update to beta3.  Clicking on XQuartz.app in the Spotlight menu gives proper 
XQuartz information in the upper left corner
of the MenuBar.

Rich

Get Outlook for iOS

From: R-SIG-Mac  on behalf of Peter West 

Sent: Tuesday, February 9, 2021 10:35:59 AM
To: r-sig-mac@r-project.org 
Subject: [External] [R-SIG-Mac] Behaviour or Quartz windows

Hi,

I�ll just confirm the odd behaviour of the Quartz window in Big Sur 11.2 R 4.0.3 
GUI 1.73 on M1 silicon. I have installed the beta3 version of Quartz. In my case I 
have to CMD <- twice, then go forward to get the next to last plot.

Are these Quartz windows constructed using native MacOS graphics or XQuartz?

Peter

�
Peter West
peter.b.w...@ehealth.id.au
�that they might touch even the fringe of his garment. And as many as touched 
it were made well.

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

 [[alternative HTML version deleted]]

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




--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] XQuartz now supports Apple Silicon

[Prof Brian Ripley]

On 30/01/2021 09:46, Bob Rudis wrote:

Announcement and d/l links:

— https://www.mail-archive.com/xquartz-dev@lists.macosforge.org/msg01027.html
— https://www.xquartz.org/releases/XQuartz-2.8.0_beta1.html

Folks who use it should get prompted to install it next time you open it.


And now beta3 which I did get nagged to install (even though it is a 
beta and I have not selected beta updates, and unlike beta1).


There is a problem with these betas - they do not contain cairo.  The 
R-admin instructions assumed that XQuartz did (as it has ever since R 
started making use of cairo) and I have just revised them to take that 
into account.  AFAICS the binary distribution of R is statically linked 
to cairo, but it is dynamically linked to X11 libs, which look 
compatible enough.  Nevertheless, using XQuartz betas with binary R 
4.0.x distributions is uncharted territory.


As the betas install into /opt/X11 on top of version 2.7.11, only people 
installing from scratch will notice that cairo is missing.


I have managed to build R with full cairo support on arm64, but only by 
building cairo from source (neither mac.r-project.org/libs-arm64 nor 
homebrew have cairo-xlib) and using fontconfig 2.13.93 not 2.13.1.


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] Missing R and RScript on /usr/bin/ on Big Sur

[Prof Brian Ripley]

On 17/01/2021 23:01, Luis Puerto wrote:

Hey!

I was and I realized after sending the email. But that path doesn't have also 
any R symbolic link either.

Can anyone tell me how many symbolic links to R binaries are there?


From the manual

'The installer puts links to R and Rscript in /usr/local/bin. If these 
are missing (as they may be under ‘Big Sur’), you can run directly the 
copies in /Library/Frameworks/R.framework/Resources/.'


(Footnote 25 in R-admin).

We don't know the exact circumstances when the installer fails (it 
worked for both my Big Sur machines, one upgraded and one new), but you 
can probably for link yourself.




Thanks!

Cheers!
Luis


On 17 Jan 2021, at 23:34, Duncan Murdoch  wrote:

On 17/01/2021 5:15 p.m., Luis Puerto wrote:

Hey!
I just installed the binary from cran for R-4.0.3 and for some reason I'm 
missing the R and RScript commands on terminal. I'm on Big Sur 11.1 and when I 
check if there are symbol links on /usr/bin/ related to R I find none.
I'm not the only one https://stackoverflow.com/a/64920581/6888648 

Does anyone experience this behavior too? If you have updated perhaps you still 
have those from previous releases, but in case this was a clean install since I 
decided to change from homebrew to the binary form cran.


I'm not on Big Sur, but I see this:


$ which R
/usr/local/bin/R


So maybe you're looking in the wrong place?

Duncan Murdoch


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




--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] M1 mid-January update

[Prof Brian Ripley]

On 14/01/2021 11:32, Jean Thioulouse wrote:


Is there a large speed difference for linear algebra operations between the 
Rosetta x86_64 builds and the native arm64 builds ?
On a Mac mini M1 8/256 I get only a slight speed increase (15% faster) with the 
arm version (experimental R-devel build).


Speed differences were covered in an earlier report so please look in 
the list archive.  Speeds are really dependent (for both Intel and ARM) 
on the load on the machine and the size of the task: typically the ARM 
version is 40% faster, with a very wide range.




Thanks
Jean


Le 14 janv. 2021 à 08:41, Prof Brian Ripley  a écrit :

For native builds - nothing to report for x86_64 builds running under Rosetta 
which almost all the time 'just work' (and work fast).

The goal remains to release a native binary distribution with R 4.1.0 ca April: 
all but the intrepid are advised to use x86_64 until then.

- There is an experimental R-devel build of the R framework at 
https://mac.r-project.org/ .  That page reports 'failed' but usually the 
framework is complete.

- R.app will need to be partially re-written as it uses Objective C features 
which are no longer supported in Xcode 12.  (I guess this is why the page is 
reporting a failure.)

- There are most parts of a toolchain and a Fortran compiler at 
https://mac.r-project.org/libs-arm64/ (not the earlier versions at libs-arm).  
These install into /opt/R/arm64, and the R-admin manual has been re-written to 
reflect that and point out some pitfalls.

- Binary packages are planned but the vast majority of packages install from 
source.  I currently have 240 CRAN check failures with 35 failing to install 
and 98 others requiring those (or BioC ones).  If you are interested in a 
particular package, https://www.stats.ox.ac.uk/pub/bdr/M1mac/ has recent logs 
for those failing directly, listed as 'additional issues' on their CRAN check 
pages.

--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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





--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

[R-SIG-Mac] M1 mid-January update

[Prof Brian Ripley]

For native builds - nothing to report for x86_64 builds running under 
Rosetta which almost all the time 'just work' (and work fast).


The goal remains to release a native binary distribution with R 4.1.0 ca 
April: all but the intrepid are advised to use x86_64 until then.


- There is an experimental R-devel build of the R framework at 
https://mac.r-project.org/ .  That page reports 'failed' but usually the 
framework is complete.


- R.app will need to be partially re-written as it uses Objective C 
features which are no longer supported in Xcode 12.  (I guess this is 
why the page is reporting a failure.)


- There are most parts of a toolchain and a Fortran compiler at 
https://mac.r-project.org/libs-arm64/ (not the earlier versions at 
libs-arm).  These install into /opt/R/arm64, and the R-admin manual has 
been re-written to reflect that and point out some pitfalls.


- Binary packages are planned but the vast majority of packages install 
from source.  I currently have 240 CRAN check failures with 35 failing 
to install and 98 others requiring those (or BioC ones).  If you are 
interested in a particular package, 
https://www.stats.ox.ac.uk/pub/bdr/M1mac/ has recent logs for those 
failing directly, listed as 'additional issues' on their CRAN check pages.


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

[R-SIG-Mac] CRAN package checks on M1 Mac

[Prof Brian Ripley]

We have managed a fairly complete check run with natively-compiled R and 
packages, and a full one with x86_64 R and packages running under 
Rosetta (mainly using CRAN binary distributions).


The bottom line is that running under Rosetta works really well. 
Although relative speeds vary widely, using the native build was 
1.3-1.5x faster for the central 50% of the distribution.  And a MacBook 
Air is remarkably capable for a lightweight laptop.



x86_64 tests


I compared the check output to that from my 2012 iMac: typically this 
was 1.7x faster than the iMac (and benchmarks have current iMac/MacMini 
about that much faster than mine).


A couple of packages ran much slower than on the iMac and hit their 
check limits, and one fails because it checks elapsed time (and was 
slower than on the iMac).


10 packages segfaulted in their checks (but most of those are known to 
segfault intermittently on other platforms).


There were issues with packages attempting to work with Python, which 
may be Big Sur differences.


Given that I have 58 packages failing their checks on the iMac under 
High Sierra this was a very small amount of degradation.



native tests


Currently I have 57 CRAN packages failing to install, but 650 others 
require those or BioC packages which fail to install (the most commonly 
required being rgl and V8 [*]).  And ca 120 packages are not using 
conditionally Suggests packages which fail to install.


There are segfaults from ca 150 packages using minpack.lm::nls.lm, 
deSolve::lsoda, rootSolve::stode ... all of which use Fortran.


That platform does not have long doubles nor extended precision but the 
CRAN checking on Linux and Sparc with --disable-long-doubles has paid 
off: only a handful of check results show numerical differences.


Quite a lot of external software and several packages have had to be 
patched, and it is early days for the former (and the Fortran compiler) 
- for example I was able to build v8, but V8 segfaulted in its checks.


Currently ca 400 packages which install fail their checks.


Note that all these checks were done with enough parallelism to have the 
machine 80-90% loaded, which it managed for days at a time without even 
getting warm.  However (not just on this machine) running multiple tasks 
in parallel takes more CPU time for each.  To illustrate that, I re-ran 
the native Matrix check on its own: the CPU time decreased from 185s to 
120s.



[*] But many of the packages requiring them to install do not actually 
use them in their checks so fake installs would do.  The results 
reported here were without fake installs.


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] vecLib BLAS and LAPACK on Mac OS 11.01 and Xcode 12.2

[Prof Brian Ripley]

On 26/11/2020 21:19, Anirban Mukherjee wrote:

Dear Prof Ripley,

1. Ok. I will not use LAPACK from the Accelerate library.

2. Ok. It would be great, when the CRAN team has the time, to update the FAQ.]


Which FAQ?  The CRAN team is not responsible for the 'MacOSX FAQ' (nor 
any of the others): 'from CRAN' in that doc means 'mirrored by CRAN from 
Simon Urbanek'.



3. I need to pass -Wno-implicit-function-declaration to have the compiled R use 
the Accelerate BLAS. Without the flag (even without --with-lapack) R compiles 
fine but uses the included stock BLAS.


I believe that had already changed (in R-devel and R-patched): your R 
was not current.  (Please do re-read the R lists' posting guide and 
update before posting.)




Best,
Anirban


On 26 Nov 2020, at 4:22 AM, Prof Brian Ripley  wrote:

A few comments:

1) Do you really want to be using an old and buggy LAPACK?  For that is what 
--with-lapack gives you, and the manual does warn you.

2) With Xcode 12.2 you will not see the .dylibs you are used to seeing: linking 
to system resources is done using .tbd files and although the dylibs are there, 
they (and much else) are hidden from casual view.

3) The instructions in the manual work for me with macOS 11.0.1 and CLT 12.2, 
both on x86_64 and on arm64.  And Accelerate is being used, as the check output 
is slightly different and I have (without --with-lapack)


sessionInfo()

R Under development (unstable) (2020-11-25 r79505)
Platform: x86_64-apple-darwin20.1.0 (64-bit)
Running under: macOS Big Sur 11.0.1

Matrix products: default
LAPACK: /Users/ripley/R/R-accelerate/lib/libRlapack.dylib

with

otool -L .../libRlapack.dylib
libRlapack.dylib (compatibility version 4.1.0, current version 4.1.0)
/System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate 
(compatibility version 1.0.0, current version 4.0.0)
...

as against a default build:


sessionInfo()

R Under development (unstable) (2020-11-25 r79505)
Platform: x86_64-apple-darwin20.1.0 (64-bit)
Running under: macOS Big Sur 11.0.1

Matrix products: default
BLAS:   /Users/ripley/R/R-devel/lib/libRblas.dylib
LAPACK: /Users/ripley/R/R-devel/lib/libRlapack.dylib



On 22/11/2020 09:15, Anirban Mukherjee wrote:

Hi,
I am having trouble using vecLib BLAS and LAPACK libraries in R 4.0.3 Patched 
(2020-11-20 r79454) on Mac OS 11.0.1 and Xcode 12.2.
For several years, I have been compiling R from source on the same computer. 
Most recently, I compiled R from source on Mac OS 10.15.7 and Xcode 11.5. As 
given in the R installation and administration manual, I specified the 
following configuration options:
1. --with-blas="-framework Accelerate”
2. --with-lapack
As expected, those two configurations options led to R using the vecLib 
libraries.
After upgrading from Mac OS 10.15.7 to Mac OS 11.01, I find that my new 
compilations of R no longer use vecLib BLAS and LAPACK libraries (sessionInfo 
below message). I poked around in 
/System/Library/Frameworks/Accelerate.framework/Frameworks/vecLib.framework/Versions/Current/.
 I do not see libBLAS.dylib and libLAPACK.dylib.
May I enquire:
a. Should I see libBLAS.dylib and libLAPACK.dylib in the vecLib framework 
folder (on Mac OS 11.01 and Xcode 12.2). As I remember it, that is where those 
libraries were located in prior versions of Mac OS and Xcode. Is the fact that 
they are missing unique to my machine? If so, then they likely were deleted in 
the upgrade as they must have been present when I compiled R a few weeks ago.
b. Has anyone compiled R from source on Mac OS 11.0.1 and Xcode 12.2? Does your 
R use the vecLib libaries (if that is what you prefer)?
Any help would be very welcome.
Thanks,
Anirban

sessionInfo()

R version 4.0.3 Patched (2020-11-20 r79454)
Platform: x86_64-apple-darwin20.1.0 (64-bit)
Running under: macOS Big Sur 10.16
Matrix products: default
LAPACK: 
/Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRlapack.dylib
locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base
loaded via a namespace (and not attached):
[1] compiler_4.0.3 tools_4.0.3
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac



--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford





--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] vecLib BLAS and LAPACK on Mac OS 11.01 and Xcode 12.2

[Prof Brian Ripley]

A few comments:

1) Do you really want to be using an old and buggy LAPACK?  For that is 
what --with-lapack gives you, and the manual does warn you.


2) With Xcode 12.2 you will not see the .dylibs you are used to seeing: 
linking to system resources is done using .tbd files and although the 
dylibs are there, they (and much else) are hidden from casual view.


3) The instructions in the manual work for me with macOS 11.0.1 and CLT 
12.2, both on x86_64 and on arm64.  And Accelerate is being used, as the 
check output is slightly different and I have (without --with-lapack)


> sessionInfo()
R Under development (unstable) (2020-11-25 r79505)
Platform: x86_64-apple-darwin20.1.0 (64-bit)
Running under: macOS Big Sur 11.0.1

Matrix products: default
LAPACK: /Users/ripley/R/R-accelerate/lib/libRlapack.dylib

with

otool -L .../libRlapack.dylib
libRlapack.dylib (compatibility version 4.1.0, current version 4.1.0)
	/System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate 
(compatibility version 1.0.0, current version 4.0.0)

...

as against a default build:

> sessionInfo()
R Under development (unstable) (2020-11-25 r79505)
Platform: x86_64-apple-darwin20.1.0 (64-bit)
Running under: macOS Big Sur 11.0.1

Matrix products: default
BLAS:   /Users/ripley/R/R-devel/lib/libRblas.dylib
LAPACK: /Users/ripley/R/R-devel/lib/libRlapack.dylib



On 22/11/2020 09:15, Anirban Mukherjee wrote:

Hi,

I am having trouble using vecLib BLAS and LAPACK libraries in R 4.0.3 Patched 
(2020-11-20 r79454) on Mac OS 11.0.1 and Xcode 12.2.

For several years, I have been compiling R from source on the same computer. 
Most recently, I compiled R from source on Mac OS 10.15.7 and Xcode 11.5. As 
given in the R installation and administration manual, I specified the 
following configuration options:

1. --with-blas="-framework Accelerate”
2. --with-lapack

As expected, those two configurations options led to R using the vecLib 
libraries.

After upgrading from Mac OS 10.15.7 to Mac OS 11.01, I find that my new 
compilations of R no longer use vecLib BLAS and LAPACK libraries (sessionInfo 
below message). I poked around in 
/System/Library/Frameworks/Accelerate.framework/Frameworks/vecLib.framework/Versions/Current/.
 I do not see libBLAS.dylib and libLAPACK.dylib.

May I enquire:

a. Should I see libBLAS.dylib and libLAPACK.dylib in the vecLib framework 
folder (on Mac OS 11.01 and Xcode 12.2). As I remember it, that is where those 
libraries were located in prior versions of Mac OS and Xcode. Is the fact that 
they are missing unique to my machine? If so, then they likely were deleted in 
the upgrade as they must have been present when I compiled R a few weeks ago.

b. Has anyone compiled R from source on Mac OS 11.0.1 and Xcode 12.2? Does your 
R use the vecLib libaries (if that is what you prefer)?

Any help would be very welcome.

Thanks,
Anirban


sessionInfo()

R version 4.0.3 Patched (2020-11-20 r79454)
Platform: x86_64-apple-darwin20.1.0 (64-bit)
Running under: macOS Big Sur 10.16

Matrix products: default
LAPACK: 
/Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRlapack.dylib

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

loaded via a namespace (and not attached):
[1] compiler_4.0.3 tools_4.0.3
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac




--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] Apple Silicon aka M1 Macs

[Prof Brian Ripley]

As a follow-up, I now have a preliminary native build of R (using a 
gfortran compiled from sources forked from GCC and using minor 
modifications of Tomas Kalibera's instructions).


The check timing was 148s, with Aqua (not X11) Tcl/Tk built from the 
sources and no X11 support, so not quite 100% comparable.


Building the compiler took 45m elapsed with 100% CPU most of the time: 
the machine (which has no fan) remained cool (unlike my MBP which has a 
fan but rarely runs it and does get warm to the touch).


There is a preliminary write-up on 'arm64' Macs in R-devel's R-admin 
manual (the version on CRAN is as usual a few days behind).


On 17/11/2020 14:57, Prof Brian Ripley wrote:

Mine (a 8GB MBA) arrived today, so I have started doing some comparisons.

For the CRAN build of R 4.0.3, §2.8 of R-admin recommends checking the 
installation with


pdf("tests.pdf") ## optional, but prevents flashing graphics windows
Sys.setenv(LC_COLLATE = "C", LC_TIME = "C", LANGUAGE = "en")
tools::testInstalledBasic("both")
tools::testInstalledPackages(scope = "base")
tools::testInstalledPackages(scope = "recommended")

That took 454s (using Rosetta) against 895s for my late-2016 MBP (2.9GHz 
i5): happily nothing untoward was reported (some recommended packages 
give differences from reference output on both systems).


You need to install XQuartz to provide the X11() devices and support for 
package Tcl/Tk: everything I tried using that worked as expected.


Having done that post-installation check I would happily use the Intel R 
on an M1 machine.


We plan to check many of the Intel-compiled packages under Rosetta.

There are many hours of work ahead to build/test a native toolchain: our 
goal is to have a native distribution for R 4.1.0 ca April 2021.





--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] Unable to use vecLib BLAS and LAPACK in Mac OS 11.0.1

[Prof Brian Ripley]

Which version of Xcode/Command Line Tools are you using?  If >= 12 (and 
perhaps earlier) Apple have set default C options which violate the 
C99/C11 standard, so you need -Wno-implicit-function-declaration.


If you have a configure issue, do read and report the relevant parts of 
config.log file: it probably told you what the problem was (it did for me):


conftest.c:227:1: error: implicit declaration of function 'dgemm_' is 
invalid in

 C99 [-Werror,-Wimplicit-function-declaration]

We will add a further comment to the R-admin manual, but Big Sur has 
been released for less than a week and a hint was already there 



On 22/11/2020 17:33, Anirban Mukherjee wrote:

Hi,

I am having trouble configuring R to use the vecLib BLAS and LAPACK libraries. 
I am on Mac OS 11.0.1 and Xcode 12.2. I tried the following options:

1. I downloaded the R binary from CRAN. I tried to follow the instructions at 
https://cran.r-project.org/bin/macosx/RMacOSX-FAQ.html#Which-BLAS-is-used-and-how-can-it-be-changed_003f
 to switch the BLAS library. I do not see libRblas.vecLib.dylib in the folder 
so I cannot switch the BLAS library as given in the FAQ. I also cannot locate 
libRblas.vecLib.dylib on my system.

2. I tried to compile R from source. I used the following configuration options: 
--with-blas="-framework Accelerate”  and --with-lapack. I should have all 
requisite libraries. The compiled R does not use the vecLib BLAS and LAPACK 
(sessionInfo below signature). During configure, I noticed configure outputted:

checking for dgemm_ in -framework Accelerate… no

Is that perhaps why configure does not configure the compiled R to use the 
Accelerate (vecLib) framework? Any suggestions would be very welcome.

Thanks,
Anirban

sessionInfo()
R version 4.0.3 Patched (2020-11-20 r79454)
Platform: x86_64-apple-darwin20.1.0 (64-bit)
Running under: macOS Big Sur 10.16

Matrix products: default
LAPACK: 
/Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRlapack.dylib

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

loaded via a namespace (and not attached):
[1] compiler_4.0.3 tools_4.0.3
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac




--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] sf installation problem under Mac OS 11 - Big Sur

[Prof Brian Ripley]

On 19/11/2020 11:22, GilbertoCamara wrote:

Dear all,

Mac users that have upgraded to Mac OS 11 BigSur have reported having problems 
with “rgdal” and “sf”. The same happened to me when I upgraded my Mac.


What problems are those?  You report nothing, and make reference to no 
reports here nor on R-sig-geo.


I tried the binary package of sf on my Intel 'Big Sur' machine and got

> library(sf)
Error: package or namespace load failed for ‘sf’ in dyn.load(file, 
DLLpath = DLLpath, ...):

 unable to load shared object '/Users/ripley/R/Library/sf/libs/sf.so':
  dlopen(/Users/ripley/R/Library/sf/libs/sf.so, 6): Library not loaded: 
/usr/lib/libpq.5.dylib

  Referenced from: /Users/ripley/R/Library/sf/libs/sf.so
  Reason: image not found

so it seem Apple has removed the PostgreSQL library.


I managed to get "sf" to run on MacOS 11.0.1 by recompiling most of the 
required packages. Here's the recipe:

1. Remove all spatial software from brew (if you installed it). Rgdal does not like "brewed" stuff 
(I believe Roger prefers wine). Seriously, it appears that rgdal looks for libraries in their default places 
and not in the "Cellar" libraries used by "brew".

2. Install Xcode 12.3beta (downloaded from Apple Developers). This is the 
latest version of XCode which is compatible with MacOS BigSur.

3. Install "wget" using brew:

"brew install wget".

4. Download the libraries below from their sources:

(a) sqlite-autoconf-333.tar.gz from "https://www.sqlite.org/download.html 
".
(b) tiff-4.1.0.tar.gz from "https://download.osgeo.org/libtiff/ 
"
(c) proj-7.2.0.tar.gz from "https://proj.org/download.html#current-release 
"
(d) libgeotiff-1.6.0.tar.gz from "https://download.osgeo.org/geotiff/libgeotiff/ 
"
(e) geos-3.8.1.tar.bz2 from "https://trac.osgeo.org/geos 
"
(f) gdal-3.2.0.tar.gz from "https://gdal.org/download.html 
"


At the bottom of https://mac.r-project.org/libs-4/ you will see a 
reference to 'recipes': you could simply have followed those to rebuild 
for macOS 11, probably only gdal.  You probably want to ensure that the 
libpq that libgdal links against is the one in the libpq recipe (or 
build without PostgreSQL support).  Please ask Simon to rebuild his gdal 
accordingly.



5. In the order given above, unpack each library and then execute the following 
commands:
% ./configure
% make
% sudo make install

6. Now you are ready to compile "rgdal" and "sf" from source. Using the R 
console,do:


install.packages("rgdal", type = "source”)
install.packages("sf", type = "source")


7. After those steps, both "rgdal" and "sf" are working on MacOS BigSur.

Hope this helps Mac users.

Best
Gilberto
[[alternative HTML version deleted]]


Please don't send HTML.

--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

[R-SIG-Mac] Apple Silicon aka M1 Macs

[Prof Brian Ripley]

Mine (a 8GB MBA) arrived today, so I have started doing some comparisons.

For the CRAN build of R 4.0.3, §2.8 of R-admin recommends checking the 
installation with


pdf("tests.pdf") ## optional, but prevents flashing graphics windows
Sys.setenv(LC_COLLATE = "C", LC_TIME = "C", LANGUAGE = "en")
tools::testInstalledBasic("both")
tools::testInstalledPackages(scope = "base")
tools::testInstalledPackages(scope = "recommended")

That took 454s (using Rosetta) against 895s for my late-2016 MBP (2.9GHz 
i5): happily nothing untoward was reported (some recommended packages 
give differences from reference output on both systems).


You need to install XQuartz to provide the X11() devices and support for 
package Tcl/Tk: everything I tried using that worked as expected.


Having done that post-installation check I would happily use the Intel R 
on an M1 machine.


We plan to check many of the Intel-compiled packages under Rosetta.

There are many hours of work ahead to build/test a native toolchain: our 
goal is to have a native distribution for R 4.1.0 ca April 2021.


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] Building R 4.0.2 from source via clang/xcode for MKL on macOS

[Prof Brian Ripley]

On 29/09/2020 12:27, Kasper Daniel Hansen wrote:

To use veclib you need
--with-blas="-framework Accelerate"


Details are in the R-admin manual, including that R fails one of its checks.

Simon's calling this vecLib is a bit misleading.  'vecLib' was a 
vectorized library for PPC Macs, and the name lives on for a small part 
of the Accelerate framework.  The part that supplies an enhanced BLAS is 
different, and is based on ATLAS for x86_64 CPUs.


Incidentally, on the configuration issue -- had you followed the posting 
guide and either read the current manual or tried R-patched you would 
not have encountered the problem (which AFAWK is very recent, from the 
Command Line Tools for Xcode 12, released only for rather recent 
versions of Catalina and pre-Big Sur about 10 days ago).  Now documented at


https://developer.apple.com/documentation/xcode-release-notes/xcode-12-release-notes


On Tue, Sep 29, 2020 at 9:53 AM roy  wrote:


Hi Simon,
Thanks for the info.  I was totally unaware of ABI, vecLib, etc and that
Apple has blas, lapack, etc.  But after reading up on this and re-reading
your email, I'm beginning to understand more about this.

So, I would like to first checkout vecLib.  From what you say, would I have
to do something like the following?

./configure --enable-BLAS-shlib --with-blas="-lBLAS"  ...

Is this also possible with LAPACK?

tx again.
cheers, roy


On Mon, Sep 28, 2020 at 3:01 PM Simon Urbanek 


wrote:


Rollin,

it has been several years since I last tested MKL, so take it with a

grain

of salt, but in general you don't necessarily have to build R with MKL in
order to use it - you only need to use --enable-BLAS-shlib and link to

any

ABI-compatible BLAS which can be vecLib as well. Then you can change the
link from vecLib to MKL in the BLAS stub. Note that we only need the C

ABI,

there are wrappers vecLibg95f.* which re-map the F entry points to C

entry

points as to avoid Fortran ABI issues thus you don't care about the
Fortran. However, historically, MKL has not been much more performant

than

vecLib so it's unclear if it is worth the hassle. As with any accelerated
BLAS, note that this may have effects on results in R.

Cheers,
Simon




On 28/09/2020, at 7:07 PM, rollin  wrote:

I wanted to build R from source on macos (10.15.5) so I could include
Intel's MKL.  So I first looked at building R from source without MKL.

 From the installation doc, I modified config.site to have the

following:


CC=clang
OBJC=$CC
FC=/usr/local/bin/gfortran
CXX=clang++


I then ran configuration via the command:

./configure -C --enable-R-shlib --enable-memory-profiling
--x-includes=/opt/X11/include --x-libraries=/opt/X11/lib




PKG_CONFIG_PATH=/opt/X11/lib/pkgconfig:/usr/local/lib/pkgconfig:/usr/lib/pkgconfig



And received the following information and error:

checking if bzip2 version >= 1.0.6... no
checking whether bzip2 support suffices... configure: error: bzip2

library

and headers are required


By looking at the log, I saw a compiler error due to an implicit

function.

I then made the following change in config.site:

CFLAGS='-Wno-implicit-function-declaration -g -O2''


And configure now ran without errors.

However, when I looked at configuring to use MKL, I discovered that MKL

on

macos does not support gnu fortran so, unless I purchase Intel's

Fortran

compiler, it looks like I'm sol.

Has anyone built R with MKL on macos (10.15)?  In any event, I wanted

to

at

least note the issue and work around I encountered when building R on
macos with clang/xcode.

   [[alternative HTML version deleted]]

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





 [[alternative HTML version deleted]]

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







--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] svn location

[Prof Brian Ripley]

A couple more points on this

1) Apple's svn is 1.10.4, Simon's is 1.14.0 so you probably should not 
mix checkouts done with the different versions.


2) Digging amongst the versions available on developer.apple.com, CLT 
11.3.1 contained svn etc, 11.5 did not (but did not remove existing 
tools, and neither did betas of 12).



On 28/08/2020 22:45, Simon Urbanek wrote:

Carl,

the one in /usr/bin is just a stub from Apple that re-directs to real svn. 
Where that one is depends on your installed tools (Xcode/CLT,...), for CLT it 
is in

$ ls -lh /Library/Developer/CommandLineTools/usr/bin/svn
-rwxr-xr-x  1 root  admin   321K Jul 13  2019 
/Library/Developer/CommandLineTools/usr/bin/svn

And it is a dynamic build so it needs all the dependent libraries (see otool 
-L). The build I'm providing is single-file so all (non-system) libraries are 
included in the binary hence it is bigger.

As to where to put it, I'd probably use /usr/local/bin, but if you don't have 
access there you can run it from your home or anywhere else.

Cheers,
Simon



On Aug 29, 2020, at 05:11, Carl Witthoft  wrote:

Well, I put this new svn in /usr/local, then checked around my Catalina system:


iMac:~ cgw$ which svn
/usr/bin/svn
iMac:local cgw$ cd /usr/bin
iMac:bin cgw$ ls -l svn
-rwxr-xr-x  1 root  wheel  31488 Aug 10 16:55 svn
iMac:bin cgw$ cd /usr/local
iMac:local cgw$ ls -l svn
-rwxr-xr-x@ 1 cgw  wheel  8767792 Aug 25 18:04 svn
iMac:local cgw$ what svn
svn
1.14.0 (r1876290)

That's a huge difference in file size!  Any idea what the /usr/bin one is?

Carl

On 8/26/20 1:00 PM, peter dalgaard wrote:

Not dumb.
Simon's usual style is that tarballs are installed at / and things end up under 
/usr/local, using the procedure outlined at the bottom of
https://mac.r-project.org/libs/
but you should probably check with "tar tvfz" first.
-pd
  

On 26 Aug 2020, at 18:43 , Carl Witthoft  wrote:

Dumb question from someone who hasn't done any building in quite a while: 
recommended director to place the svn executable?
thanks
Carl

On 8/26/20 6:00 AM, r-sig-mac-requ...@r-project.org wrote:


1.  svn now available from the tools (Simon Urbanek)
ntent-Type: text/plain; charset="us-ascii"
If you want to build R from the svn repository you need svn (subversion). Xcode 
10 has removed svn so it is no loner available from Apple, we are providing a 
binary (cmopatible with OS X 10.11 and higher) in
https://mac.r-project.org/tools/
(in "optional tools and libraries" at the bottom), direct link:
https://mac.r-project.org/tools/subversion-1.14.0-darwin15.6.tar.gz
It is a single-file signed, static build so has no dependencies and can be run 
from anywhere.



--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] bzip2 configure error

[Prof Brian Ripley]

On 29/08/2020 19:38, Duncan Murdoch wrote:
I seem to have got past this error by reinstalling Xcode.  I'm not sure 
what went wrong with the old install; I'm pretty sure I did an R-devel 
build since installing Catalina.


This seems to come from a CLT update: my Catalina box updated to 12.0 
beta 5 overnight.  And that has defaulted the SDK to 11.0.


I wish they would not do that -- it is not the first time they have 
installed a beta CLT without asking and set the SDK for a future OS.


I have tweaked configure for R-devel and R-patched so they install, but 
likely the better answer for me is to downgrade the CLT to 11.5 or set 
an SDK.




Duncan Murdoch

On 28/08/2020 10:41 a.m., Duncan Murdoch wrote:

I'm trying to build R-devel in Catalina for the first time in a few
weeks, and configure is dying with this error:

   checking whether bzip2 support suffices... configure: error: bzip2
library and headers are required

I tried a Homebrew install of bzip2, and it didn't help.

When I look in config.log, I see this:


configure:45424: checking if bzip2 version >= 1.0.6
configure:45452: gcc -o conftest  -g -O2 -I/usr/local/opt/libffi/include
   -L/usr/local/opt/libffi/lib conftest.c -lbz2 -lz -licucore -ldl -lm
-liconv >&5
conftest.c:250:11: warning: initializing 'char *' with an expression of
type 'const char *' discards qualifiers
[-Wincompatible-pointer-types-discards-qualifiers]
  char *ver = BZ2_bzlibVersion();
    ^ ~~
conftest.c:251:5: error: implicitly declaring library function 'exit'
with type 'void (int) __attribute__((noreturn))'
[-Werror,-Wimplicit-function-declaration]
  exit(strcmp(ver, "1.0.6") < 0);
  ^
conftest.c:251:5: note: include the header  or explicitly
provide a declaration for 'exit'
conftest.c:251:10: error: implicitly declaring library function 'strcmp'
with type 'int (const char *, const char *)'
[-Werror,-Wimplicit-function-declaration]
  exit(strcmp(ver, "1.0.6") < 0);
   ^
conftest.c:251:10: note: include the header  or explicitly
provide a declaration for 'strcmp'
1 warning and 2 errors generated.


Suggestions for fixing this?

Duncan Murdoch



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



--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] Running R with lldb

[Prof Brian Ripley]

One of the suggestions in

https://cran.r-project.org/doc/manuals/r-devel/R-exts.html#Debugging-on-macOS

should help.  Both worked for my build of R-devel yesterday 


On 05/08/2020 14:25, Duncan Murdoch wrote:
I'm now successfully building R-devel in /Users/murdoch/R/R-devel.  If I 
run it from that directory using


  bin/R -d lldb

it starts, but "run" gives this error:

Process 11165 launched: '/Users/murdoch/R/R-devel/bin/exec/R' (x86_64)
dyld: Library not loaded: libRblas.dylib
   Referenced from: /Users/murdoch/R/R-devel/bin/exec/R
   Reason: image not found
Process 11165 stopped
* thread #1, stop reason = signal SIGABRT
     frame #0: 0x0001004c7ede dyld`__abort_with_payload + 10
dyld`__abort_with_payload:
->  0x1004c7ede <+10>: jae    0x1004c7ee8   ; <+20>
     0x1004c7ee0 <+12>: movq   %rax, %rdi
     0x1004c7ee3 <+15>: jmp    0x1004c6408   ; cerror_nocancel
     0x1004c7ee8 <+20>: retq
Target 0: (R) stopped.

I can start it from the /Users/murdoch/R/R-devel/lib directory where 
libRblas.dylib lives.  Setting DYLD_LIBRARY_PATH or LD_LIBRARY_PATH to 
point there doesn't help (either on the bin/R command line or exported). 
  Is there some other way to run it from whatever directory I happen to 
be in?


Duncan Murdoch

On 02/05/2020 11:26 p.m., Simon Urbanek wrote:

Vince,

Apple no longer allows debugging of distributed apps - see R for Mac 
FAQ 10.17:
http://mac.r-project.org/bin/macosx/RMacOSX-FAQ.html#I-cannot-attach-debugger-to-R 



Another (not recommended) work-around is to disable SIP.

Cheers,
Simon



On 3/05/2020, at 10:42 AM, Vincent Carey  
wrote:


I'd like to make use of material in

https://kevinushey.github.io/blog/2015/04/13/debugging-with-lldb/

But with R 4.0 I get

%vjcair> R -d lldb

(lldb) target create 
"/Library/Frameworks/R.framework/Resources/bin/exec/R"


Current executable set to
'/Library/Frameworks/R.framework/Resources/bin/exec/R' (x86_64).

(lldb) run

error: process exited with status -1 (Error 1)

(lldb) quit

%vjcair> which lldb

/usr/bin/lldb

%vjcair> lldb --version

lldb-1100.0.30.12

Apple Swift version 5.1.3 (swiftlang-1100.0.282.1 clang-1100.0.33.15)


with gdb, there is a little more info -- and a peculiar warning that
mentions /Volumes/Builds/Simon/R4/h ...


%vjcair> R -d gdb

GNU gdb (GDB) 8.1

Copyright (C) 2018 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later 
.

Find the GDB manual and other documentation resources online at:

.

For help, type "help".

Type "apropos word" to search for commands related to "word"...

Reading symbols from 
/Library/Frameworks/R.framework/Resources/bin/exec/R...


warning:
`/Volumes/Builds/Simon/R4/high-sierra-x86_64/R-4.0-branch/src/main/Rmain.o': 


can't open to read symbols: No such file or directory.

(no debugging symbols found)...done.

(gdb) run

Starting program:
/Library/Frameworks/R.framework/Versions/4.0/Resources/bin/exec/R

Unable to find Mach task port for process-id 59032: (os/kern) failure 
(0x5).


(please check gdb is codesigned - see taskgated(8))


sessionInfo()


R version 4.0.0 Patched (2020-04-27 r78309)

Platform: x86_64-apple-darwin17.0 (64-bit)

Running under: macOS Mojave 10.14.6


Matrix products: default

BLAS:
/Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRblas.dylib 



LAPACK:
/Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRlapack.dylib 



--
The information in this e-mail is intended only for t...{{dropped:8}}


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



--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] Link-Time Optimization (LTO)

[Prof Brian Ripley]

On 15/07/2020 09:50, Jeroen Ooms wrote:

On Tue, Jul 14, 2020 at 4:22 PM Prof Brian Ripley  wrote:


This is a rather technical post about how libraries of compiled code can
be further optimized.  LTO generally produces smaller[*] and faster code
(typically by a few percent) at the expense of increased installation
time and is being used for large projects such as browsers and soon for
some Linux distributions.

I have committed a series of enhancements to LTO support in R-devel and
will shortly port the more important of these to R-patched.


Would it be worthwhile looking into this for Windows? We did enable
support for LTO in the rtools40 toolchains*, but those are gcc-8.3.0
and some of the benefits require gcc-9.

* 
https://github.com/r-windows/rtools-packages/blob/master/mingw-w64-gcc/PKGBUILD#L166


Way off topic for R-sig-mac, but it is under discussion for Windows once 
all the planned LTO changes are in.


A minor point which is relevant here: the recommended gfortran 
distribution for macOS (which is from GCC 8.2) contains gcc and g++.  So 
Mac users could try that to get C/Fortran consistency checks.  However, 
only much later versions are compatible with Catalina's SDK 
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835), and from trying on 
High Sierra it looks like Apple's linker does not understand GCC's LTO 
format.


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

[R-SIG-Mac] Link-Time Optimization (LTO)

[Prof Brian Ripley]

This is a rather technical post about how libraries of compiled code can 
be further optimized.  LTO generally produces smaller[*] and faster code 
(typically by a few percent) at the expense of increased installation 
time and is being used for large projects such as browsers and soon for 
some Linux distributions.


I have committed a series of enhancements to LTO support in R-devel and 
will shortly port the more important of these to R-patched.


This includes pretty comprehensive LTO support for clang, mainly to make 
LTO usable on macOS.  (LLVM/clang has diverged considerably from GCC in 
how LTO is implemented - in particular with 'Thin LTO'.)


Full details (including example settings for macOS) are in the R-admin 
manual.


I would not use LTO on macOS routinely (I do on Linux), but for some 
applications the performance gains[+] maybe valuable enough.  By the 
time R 4.1.0 is released it may be worth using it for the distributed R 
and binary packages


LTO can be used to find inconsistencies between C/C++ compilation units 
as reported in the CRAN LTO 'Additional issues'.  Unfortunately it 
cannot help with the more common C/Fortran inconsistencies as the 
intermediate representation used by gfortran is different and ignored by 
the macOS linker.  An LLVM-based Fortran compiler (variously called 
flang and f18) has been promised for years but is being re-implemented 
and is far from usable.


[*] although probably due to inlining, sometimes larger as it is for 
libR.dylib.


[+] some R test scripts show negligible change in performance, several a 
gain of 5% and a couple a gain of 10-15%.  Installation times depend 
rather a lot on how much one can make use of multithreading: on my 
dual-core MBP total R build elapsed time increased from 7:13 to 8:04 (m:s).


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] Advise on building R on OSX without optimization for debugging

[Prof Brian Ripley]

On 13/07/2020 11:14, Simon Urbanek wrote:




On Jul 13, 2020, at 7:59 PM, Prof Brian Ripley  wrote:

On 08/07/2020 21:38, Simon Urbanek wrote:

Dmitriy,
due to permissions and the various limitations on passing environment variables 
across processes it is often easier to simply run R and attach the debugger to 
it:
$ R
[...]

Sys.getpid()

[1] 89955



$ sudo lldb
Password:
(lldb) attach 89955
[...]
(lldb) c
Process 89955 resuming


On Catalina I can do that for a version of R I compiled, but not for a 
notarized binary distribution (which also refuses to be run under a debugger).  
The lldb error message is maximally uninformative:

(lldb) attach 16682
error: attach failed: Error 1

or

(lldb) run
error: process exited with status -1 (Error 1)

I presume that is intentional on Apple's part and there is no way round it 
other than weakening security (e.g. disable SIP)?




Correct. It is annoying enough that it made to to the FAQ:

https://cran.r-project.org/bin/macosx/RMacOSX-FAQ.html#I-cannot-attach-debugger-to-R

So the recommended way is to use the non-notarised builds (you can also disable 
SIP but that is not recommended). And, yes, it would be nice if lldb provided a 
more useful error...

I suspect that it would be actually sufficient to provide just a exec/R binary 
that doesn't use hardened run-time, but it couldn't be distributed in the Apple 
Installer ... unless we create it with the post install script ... something to 
test I suppose...


Thanks.  My issues have been when my own build works but yours does not 
but while I am still checking on High Sierra I have workarounds.  AFAIR 
the issues have all been array overruns which only sometimes cause 
segfaults.



Best,
Simon





My memory was that it did work on High Sierra (I sometimes use it to 
investigate packages which segfault under your distribution but not with my 
builds) and I have just re-checked there with the CRAN distribution of 4.0.2.

Brian Ripley

--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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





--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] Advise on building R on OSX without optimization for debugging

[Prof Brian Ripley]

On 08/07/2020 21:38, Simon Urbanek wrote:

Dmitriy,

due to permissions and the various limitations on passing environment variables 
across processes it is often easier to simply run R and attach the debugger to 
it:

$ R
[...]

Sys.getpid()

[1] 89955




$ sudo lldb
Password:
(lldb) attach 89955
[...]
(lldb) c
Process 89955 resuming


On Catalina I can do that for a version of R I compiled, but not for a 
notarized binary distribution (which also refuses to be run under a 
debugger).  The lldb error message is maximally uninformative:


(lldb) attach 16682
error: attach failed: Error 1

or

(lldb) run
error: process exited with status -1 (Error 1)

I presume that is intentional on Apple's part and there is no way round 
it other than weakening security (e.g. disable SIP)?


My memory was that it did work on High Sierra (I sometimes use it to 
investigate packages which segfault under your distribution but not with 
my builds) and I have just re-checked there with the CRAN distribution 
of 4.0.2.


Brian Ripley

--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

[R-SIG-Mac] Timezone databases on macOS

[Prof Brian Ripley]

I have tweaked the selection of this in R-devel.

For a long time the handling of timedates in macOS was 32-bit, and that 
included the zoneinfo compiler (/usr/sbin/zic) and hence the shipped 
timezone database. The latter is now 64-bit on High Sierra (the earliest 
we support) but there must still be 32-bit aspects to the system code as 
it fails sanity checks outside 1902-2037.


This means we now have the choice of using the system database or the 
one installed into R and the R-devel now uses whichever version is later.


IANA update the database a few times a year (5x in 2018, 3x in 2019, 
once so far in 2020).  We update the R sources fairly quickly, but 
released versions and installed R do not get updated.  AFAICS Apple 
updates the system version as part of security updates, so a few times a 
year for still-supported versions -- High Sierra is up-to-date at 
April's version 2020a.


For most people this hardly matters as time zone changes get a lot of 
notice -- but not e.g. for Morocco over Ramadan (a reason for the 2020a 
update).  However, that may well change as the EU has agreed to outlaw 
DST transitions from 2021 and leave to the states whether they stay on 
summer time or make one last change in Oct 2021. (Some neighbouring 
states are likely to follow suit, but not the UK which matters on the 
island of Ireland.)  Which means we do not currently know what timezones 
in Europe will be in 2021.  We can be pretty sure Apple will update the 
macOS databases once this is decided, but users of R 4.0.last will not 
get updates from us.


There should be no change in behaviour until there is a macOS system 
database later than that installed in R, which for up-to-date R-devel is 
unlikely.


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

[R-SIG-Mac] Packages with updated spatial libraries.

[Prof Brian Ripley]

I have put binary packages on CRANextras for lwgeom rgdal rgeos sf built 
with GEOS 3.8.1, GDAL 3.1.0, PROJ 6.3.2.


Install with (e.g.)

options(repos="https://www.stats.ox.ac.uk/pub/RWin;)
install.packages('rgdal', type = 'binary')

(This needed a development version of the rgdal sources.)

This is just to allow early access: it is planned to use these versions 
of the libs on the CRAN builders soon (but they do need package updates, 
e.g. for rgdal and proj4).


These are all using static libraries to make these self-contained.

(In case anyone is wondering why not PROJ 7 -- that would need 
unreleased changes to the PROJ and GDAL sources and changes to many CRAN 
packages.)


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] R CMD check warning in 4.0.0 RC

[Prof Brian Ripley]

On 20/04/2020 16:51, Duncan Murdoch wrote:
I've just installed R version 4.0.0 RC (2020-04-18 r78249) and am 
checking a package on MacOS High Sierra (10.13.6).  I can't install the 
recommended version of Xcode on this MacOS version.  I'm currently using 
Xcode 9.2.  (I think Xcode 10.x is supposed to work on High Sierra, but 
it isn't obvious how to update.)


My package has a small amount of C code, and R CMD check is clean, but R 
CMD check --as-cran gives this NOTE:


* checking compilation flags used ... NOTE
Compilation used the following non-portable flag(s):
   ‘-mmacosx-version-min=10.13’

I didn't supply that, it's the default, so probably this note should not 
appear (even though the message is true).


The customizations for R CMD check are in the 'R Internals' manual. 
That would have shown that you needed


setenv _R_CHECK_COMPILATION_FLAGS_KNOWN_ "-mmacosx-version-min=10.13"

It is too late for 4.0.0 but in any case I would be reluctant to include 
that in the 'known good' flags.  What is not at all clear is which 
compilers support it (even on macOS) -- it seems to be in the LLVM 
version of clang but undocumented (like so many clang flags).


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] GTK+ support (or rather lack thereof)

[Prof Brian Ripley]

On 04/04/2020 05:15, Tom Elliott wrote:

Simon,


Hence this is a call to the R community to see if anyone actually cares.

I (and Chris Wild and quite a few of our mac users) care and would greatly 
appreciate working GTK+ CRAN packages!

I don't have any knowledge re source etc, but just to remind you that the 
current RGtk2 package on CRAN for 3.3 doesn't work (or at least wasn't when I 
last tried):

library(RGtk2)
gtkHScaleNewWithRange(0, 5, 1)  # segfault


Did you really mean '3.3'?  If so, R versions that old are long unsupported.

FWIW, your example worked for me with 4.0.0 alpha and RGtk2 built from 
source against Simon's (old) build of GTK+ 2.24.17.  Have you tried 
that?   RGtk2 and some of the packages using it pass their checks but 
some (e.g. gWidgets2RGtk2 and a few of those using it including MixSIAR, 
Ricetl, fit4NM, plfMA) segfault.  And this has been the case for several 
years.


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] Installing CRAN binary packages with R 4.0 installed from source crashes R

[Prof Brian Ripley]

On 02/04/2020 09:34, Simon Urbanek wrote:

Hervé,

"both" is a fairly recent addition and my guess would be that it has been guarded specifically 
since it is the default and installing binaries only works for the CRAN version. I didn't look at the new 
"both" code to see how it knows that it's the CRAN version - there is really no special 
"CRAN" flag. At some point we were guarding binary installs in general by checking the OS and R, 
but it was fragile - you could be building using the same system as we do and yet use a different compiler, 
so I think it's in general impossible unless we introduce some extra identification of the binaries. So, yes, 
if you compile R from sources yourself it is not guaranteed to be compatible with CRAN package binaries. 
Those are only built and tested with the CRAN R binary.


It is simple: type = 'both' has to know what the two types are.  Only 
the CRAN binaries have the default type set to "mac.binary": building 
from the sources gives you a default type of "source".  See ?.Platform.




Cheers,
Simon



On 2/04/2020, at 7:47 PM, Hervé Pagès  wrote:

Hi Simon,

After installing R 4.0 alpha from source on a macOS Mojave system, R won't let me use 
type="both" to install CRAN packages. I get:

  Error in install.packages("rJava", type = "both", repos = 
"https://cran.r-project.org;) :
type == "both" can only be used on Windows or a CRAN build for macOS

OK so this suggests that the CRAN binary packages for R 4.0 are not compatible with my R. 
Surprisingly though using type="mac.binary" doesn't complain and lets me 
install these binaries. But then trying to load them causes segfaults. I've tried this 
with rJava, Rcpp, ggplot2, and doing library() on any of them crashes my session. Note 
that installing all these packages from source works without any problem.

So my questions are: is it the case that CRAN binary packages are not meant to be used with an R 
4.0 installed from source? If yes then why isn't type="mac.binary" blocking this like 
type="both" does?

Thanks,
H.


sessionInfo()

R version 4.0.0 alpha (2020-04-01 r78132)
Platform: x86_64-apple-darwin18.7.0 (64-bit)
Running under: macOS Mojave 10.14.6

Matrix products: default
BLAS:   /Users/biocbuild/bbs-3.11-bioc/R/lib/libRblas.dylib
LAPACK: /Users/biocbuild/bbs-3.11-bioc/R/lib/libRlapack.dylib

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

loaded via a namespace (and not attached):
[1] compiler_4.0.0


--
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org
Phone:  (206) 667-5791
Fax:(206) 667-1319

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



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




--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] PCRE JIT compilation error

[Prof Brian Ripley]

It seems to depend on the OS version: there are known issues with PCRE 
JIT and macOS 10.15 not just with R, but not for everyone.


Similarly, installation issues of some Rcpp-using packages is only known 
to occur under 10.15 and not with 10.13 (which is what will be used for 
building binary packages and has been extensively tested there).  These 
should go away with the next Rcpp update, available pro tem via


install.packages("Rcpp", repos="https://rcppcore.github.io/drat;)

So it really is necessary to remind people to follow the posting guide 
and include the output from sessionInfo() or at the very least


> osVersion
[1] "macOS Catalina 10.15.4"


On 01/04/2020 14:37, peter dalgaard wrote:

Yes, this has been happening to a number of people, including Simon Urbanek...

Oddly enough, I'm seeing nothing of the sort on my slightly different build 
setup:

clang8 + gfortran6.1 as per https://cran.r-project.org/bin/macosx/tools
PCRE2 from http://mac.r-project.org/libs/

$ cat config.site
prefix=$HOME/tmp
CC=clang
CXX=clang++
with_blas="-framework vecLib"
with_lapack=yes
x_includes=/opt/X11/include
x_libraries=/opt/X11/lib
CURL_CONFIG=/usr/bin/curl-config

(And no, it is not because JIT is off:


options("PCRE_use_JIT")

$PCRE_use_JIT
[1] TRUE

)


-pd


On 1 Apr 2020, at 13:30 , Bryan Hanson  wrote:

On a fresh install of the binary from mac.r-project.org, if I simply do:

library()

I see:

R > library()
There were 30 warnings (use warnings() to see them)
R > warnings()
Warning messages:
1: In strsplit(x, "\n[ \t\n]*\n", perl = TRUE) : PCRE JIT compilation error
'no more memory'
2: In FUN(X[[i]], ...) : PCRE JIT compilation error
'no more memory'

etc.  The usual window with installed packages does open.

Starting the conversation here on the Mac list, though it may be a bigger 
problem.

Thanks, Bryan

Prof. Bryan Hanson (emeritus)
Dept of Chemistry & Biochemistry
DePauw University
Greencastle IN 46135 USA
Web: academic.depauw.edu/~hanson/index.html
Repo: github.com/bryanhanson
Nerdy Blog: ChemoSpec.org
The Twit: @ProfBryanHanson
I’m usually @ -4 GMT/UTC

R > sessionInfo()
R version 4.0.0 alpha (2020-03-29 r78109)
Platform: x86_64-apple-darwin17.0 (64-bit)
Running under: macOS Mojave 10.14.6

Matrix products: default
BLAS:   
/Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRblas.dylib
LAPACK: 
/Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRlapack.dylib

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats graphics  grDevices utils datasets  methods
[7] base

loaded via a namespace (and not attached):
[1] compiler_4.0.0












[[alternative HTML version deleted]]

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





--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

[R-SIG-Mac] Xcode/CLT 11

[Prof Brian Ripley]

As a test (I would not recommend it), I installed Command Line Tools 11 
on my Mojave machine.


1) As expected, it does not contain any macOS_SDK_headers_for_macOS 
package, so the second approach in

https://cran.r-project.org/doc/manuals/r-devel/R-admin.html#Recommended-C_002fC_002b_002b-compilers
is needed to use the non-Apple builds of clang.  If you do not need 
OpenMP support, one can simple use the CLT's compilers.


2) This contains the SDK for 10.15 (as did CLT 10.2.1).  However, it 
conditionally declares timespec_get, a C11 function that is finally 
added in 10.15.  autoconf does not understand the conditioning, so R's 
configure defined HAVE_TIMESPEC_GET in src/include/config.h.  I have 
worked around this in R-patched and R-devel, but for earlier versions of 
R simply comment out that line in src/include/config.h after running 
configure and before make.


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] Building R-devel from source (solved)

[Prof Brian Ripley]

On 19/08/2019 15:00, peter dalgaard wrote:

OK, I now got a clang7 build running on a machine here too.

Simon, if you are listening: The alternative instructions to installing SDK to 
/usr/include seems to be incomplete. With

CPPFLAGS="-isysroot 
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include"

I got a succesful compile, but the link phase dies looking for -lSystem or 
somesuch. I.e., I think something needs to happen with LDFLAGS as well. This of 
course only shows up if you do not install the SDK to /usr/include.


The trick seems to be to include -isysroot as part of CC:

CC="/usr/local/clang8/bin/clang -isysroot 
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk"


and similarly for CXX.

Otherwise you are going to need something like

LDFLAGS="-L/usr/local/clang8/lib -L/usr/local/lib 
-L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib"


I also had to set

CXXCPP="$CXX -E"

[There are quite a few places in configure which run ${CC} ${CFLAGS} -o 
foo.o -c foo.c


and so do not notice CPPFLAGS.]

I did not find this documented for clang (except for making pre-compiled 
headers), but gcc has at 
https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html


-isysroot dir

This option is like the --sysroot option, but applies only to 
header files (except for Darwin targets, where it applies to both header 
files and libraries). See the --sysroot option for more information.


and clang usually blindly copies gcc (I found a Q from a clang developer 
asking why it was like that in gcc).


I am revising the R-admin manual: will have a new version up in a few days.




-pd


On 19 Aug 2019, at 11:54 , Göran Broström  wrote:

Here is the report I promised. I followed the path below:

1. Got source from CRAN.

2. Read instructions under "Download R for (Mac) OS X"
(shouldn't that read "Download R for macOS" nowadays?). Especially the note Important: 
"If you wish to compile R packages ..., see the tools directory."

3. In the tools directory: Download and install clang-7.0.0.pkg (I see now that I should 
have chosen clang-8.0.0 for R 3.7.0, which is R-devel?). Also download and install 
gfortran-6.1.pkg (It says: "To be used with El Capitan builds of R.", which 
worried me a little, since I am on High Sierra, but there were no alternatives.)

With this setup I got my first reported error. Thanks to Peter, I went on to

https://cran.r-project.org/doc/manuals/r-release/Radmin.html#macOS,

where I read

--
One way to use these builds with a binary distribution of R is to have a 
~/.R/Makevars file similar to (El Capitan)

FC = /usr/local/gfortran/bin/gfortran
FLIBS = -L/usr/local/gfortran/lib/gcc/x86_64-apple-darwin15/6.1.0
  -L/usr/local/gfortran/lib -lgfortran -lquadmath -lm

or (Sierra or High Sierra)

FC = /usr/local/gfortran/bin/gfortran
FLIBS = -L/usr/local/gfortran/lib/gcc/x86_64-apple-darwin16/6.3.0
  -L/usr/local/gfortran/lib -lgfortran -lquadmath -lm
--

I naively chose the "Sierra or High Sierra" alternative, but that was wrong as you can 
see: It apparently refers to gfortran 6.3, so I switched to the the "El Capitan" 
alternative.

The final error message was then something about 'unable to compile mixed C and 
Fortran code', and that was fixed by changing

LDFLAGS="-L/usr/local/clang7/lib -L/usr/local/lib"

to

LDFLAGS="-L/usr/local/clang7/lib -L/usr/local/gfortran/lib
-L/usr/local/gfortran/lib/gcc/x86_64-apple-darwin15/6.1.0"

and voila, ./configure run without complaints!

The later build also went smoothly (but I had to install java).

So, to sum up, there seems to be some discrepancy between the two
instruction sets I tried to follow.

Göran




Den 2019-08-19 kl. 00:06, skrev Göran Broström:

Den 2019-08-18 kl. 22:16, skrev peter dalgaard:

/usr/local/clang7 is likely a better place to look. Check out Appendix C.3 of the R 
Inst. manual:

https://cran.r-project.org/doc/manuals/r-release/R-admin.html#macOS

That's better! After correcting some obvious(?) errors(?) in that page, 
./configure run without errors! (Had only read mac.r-procject.org/tools/ so 
far).
After a night's sleep I will 'make'. I'll report back to r-sig-mac.
Thanks, Göran


-pd


On 18 Aug 2019, at 21:35 , Göran Broström  wrote:

Update: There is a libgcc_s.1.dylib in /usr/lib, as a symlink to 
/usr/lib/libSystem.B.dylib. Is that one useful?

Göran

Den 2019-08-18 kl. 18:54, skrev Göran Broström:

Thanks Peter,
The tripping lines are here
configure:24611: checking size of size_t
configure:24616: gcc -o conftest -g -O2 -I/usr/local/include -L/usr/local/lib 
conftest.c -ldl -lm  >\
&5
configure:24616: $? = 0
configure:24616: ./conftest
dyld: Library not loaded: /usr/local/lib/libgcc_s.1.dylib
Referenced from: /Users/gb/R/src/R-devel/./conftest
Reason: image not found
so it seems as if my installation of tools is lacking an essential part 
(/usr/local/lib/libgcc_s.1.dylib). I'll look around, but any suggestion is 
welcome!
Göran
Den 2019-08-18 kl. 17:56, skrev peter dalgaard:

I 

Re: [R-SIG-Mac] RGtk2 segfaulting on macOS

[Prof Brian Ripley]

On 22/07/2019 03:47, Tom Elliott wrote:

Hi,


The macOS binaries were recently built for macOS, however they're still not 
quite right. Runing the following ...


It is likely that the segfault is in the Gtk2 libraries: which OS 
version and which Gtk2 installation?


I have not managed to get Gtk2 to work cleanly on macOS for a long time: 
the Gtk2 libs at https://mac.r-project.org/libs/ are > 6.5 years old. 
Some of the packages pass their tests some of the time: currently 
MixSIAR, Ricetl, fit4NM, gWidgets2RGtk2 and plfMA segfault on my High 
Sierra box.



library(RGtk2)

gtkHScaleNewWithRange(0, 5, 1)


... leads to a segfault ...


  *** caught segfault ***
address 0x0, cause 'memory not mapped'

Traceback:
  1: .RGtkCall("S_gtk_hscale_new_with_range", min, max, step, PACKAGE = "RGtk2")
  2: gtkHScaleNewWithRange(0, 5, 1)


It's preventing some other packages (notably gWidgets2RGtk2) from building on 
CRAN, since it's tests are running into the same segfault when running tests 
(gslider calls gtkHScaleNewWithRange):
https://cran.r-project.org/web/checks/check_results_gWidgets2RGtk2.html



--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] Apple Clang does support OpenMP (if libomp is available)

[Prof Brian Ripley]

On 06/06/2019 16:39, Simon Urbanek wrote:

Jon,

some time ago Apple's clang has silently dropped -fopenmp so we were able to at 
least keep it in the flags even if it wasn't actually using it. Still, it was 
only dropping it, it wasn't actually generating any parallel code, so there was 
real point in using it. That's when we decided to use non-Apple clang since it 
has proper support for parallel code generation.

What you're pointing out is that more recent clang builds from Apple now do 
include the OMP generation pieces (in particular the pre-processor), they just 
don't ship any OpenMP-related headers or libraries. The problem is that it's 
hard to rely on something that is unsupported and works only on some systems. 
We could ship libomp (we already do - no need to get it from homebrew), but, 
for example, the omp.h headers from clang7 don't work with Apple's clang (you 
do need explicit -I.. and -lomp in addition to -Wp,-fopenmp because it's not 
only the pre-processor that needs to know about it).

Also note that "-Wp,-fopenmp" is a hack - just because Apple has not patched 
the pre-processor and only the front-end/linker to refuse it, it doesn't mean that it 
actually works properly. There is no guarantee that they made changes to the 
code-generation which break something in OpenMP since it's not not even included in any 
of their tests. Hence I'd say it's a quick hack if you don't want to to install clang7 
that may or may not work depending on your code, but not something I'd trust in a release.


There is another issue: libomp is not explicitly versioned, but there 
are differences between LLVM-project releases (and there are other 
sources, and even projects which symlink other implementations to 
libomp).  So putting -lomp in LIBS is unsafe, and part of the job of a 
-fopenmp flag when a compiler is used to link is to arrange to link to 
the correct libomp (also at runtime).


clang has not always done a good job in finding the right libomp, and it 
has a couple of times recently adding OpenMP features which need support 
in libomp.  So whereas this may 'work OK' for one user's limited 
testing, it may not work for all R packages (and in my experience it has 
been just a handful which failed).




Cheers,
Simon




On Jun 6, 2019, at 6:42 AM, Jon Clayden  wrote:

Dear all,

Lack of OpenMP support in Apple’s build of Clang is cited as one
reason for not using it in CRAN builds, but this is only partly true:
after installing libomp from Homebrew, I have been adding
“-Wp,-fopenmp” to CXXFLAGS and CFLAGS (and “-lomp” to LIBS) to my
builds for a while, and everything seems to work OK.

I’m not sure how far back this support goes (and I haven’t tried the
Xcode 11 tools yet), but is there any known reason not to take this
approach, and if not, would it make sense for R’s configure script to
try “-Wp,-fopenmp” when testing for OpenMP support?

All the best,
Jon




--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] Warning on XCode / Command Line Tools 11

[Prof Brian Ripley]

On 06/06/2019 09:31, peter dalgaard wrote:

FWIW, no updates are suggested for the source-building machine in my office, 
also running Mojave. (June 5 was Constitution Day and Election Day, so I have 
been away from the machine until now.)


It stopping nagging me yesterday afternoon, so likely it was an Apple 
snafu.  (I heard from others who had been caught by this, and of course 
Apple allows for 'automatic' updating so this could happen in the 
background.)



We do need to keep an eye on the tools though. My current setup is an  -um- 
eclectic mix (*) of old and new tools, some of which are 32 bit, and this is 
going to be a problem in 10.15 Catalina. I did try getting the tools better in 
line with Simon's setup at some point, but there were hiccups and then I ran 
out of time and couldn't risk collateral damage.


You have a few months yet.  The residual 32-bit applications I have are 
from Adobe, e.g. old uninstallers.




-pd


(*) ="dogs dinner"


On 4 Jun 2019, at 17:10 , Prof Brian Ripley  wrote:

My Mojave machine today prompted me to update to version 11 of Command Line 
Tools (apparently 'beta 1', but I am not a Beta tester).

In short: don't do that (you can revert to 10.2.1 from the URL above, at least 
if your Apple ID has (free) developer privileges).

CoreFoundation.framework has been removed (and its headers are used in a couple 
of spots compiling R).

Further its seems that 
/Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg
 is no longer included and setting CPPFLAGS did not suffice.

Hopefully we will have solutions in due course, but that version is really for 
10.15 Catalina which is months away ('in the Fall', whenever that is).

--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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





--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

[R-SIG-Mac] Warning on XCode / Command Line Tools 11

[Prof Brian Ripley]

My Mojave machine today prompted me to update to version 11 of Command 
Line Tools (apparently 'beta 1', but I am not a Beta tester).


In short: don't do that (you can revert to 10.2.1 from the URL above, at 
least if your Apple ID has (free) developer privileges).


CoreFoundation.framework has been removed (and its headers are used in a 
couple of spots compiling R).


Further its seems that 
/Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg 
is no longer included and setting CPPFLAGS did not suffice.


Hopefully we will have solutions in due course, but that version is 
really for 10.15 Catalina which is months away ('in the Fall', whenever 
that is).


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] Issues with rj (requirement for StatET) since Mojave/3.5.1 update

[Prof Brian Ripley]

BTW, reading the manual (in this case 'R Installation and 
Administration') often helps, and would have here.


On 16/11/2018 19:10, Jonathan Greenberg wrote:

I'm hoping to get some insight into seeing if I can get "rj" working again in Mojave/R 
3.5.1 -- this is a requirements for the Eclipse interface to R "Stat-ET") -- I'm seeing 
similar issues when trying to get rJava working also from source, e.g.:

Rscript -e 'install.packages("rJava", repos="http://rforge.net;, type="source")'


Why are you not installing from CRAN?  Discussing off-CRAN versions here 
is frowned on, not least as we know the CRAN version works.



and

install.packages(c("rj", "rj.gd"), 
repos="http://download.walware.de/rj-2.1",type="source;)

All issues lead to:

"clang: error: unsupported option '-fopenmp'"

I've installed clang6 and gfortran61 from CRAN, but that doesn't seem to work.  
I've tried tweaking the ~/.R/Makevars, e.g.:

FLIBS=-L/usr/local/gfortran/lib -lgfortran -lquadmath -lm
CC=/usr/local/clang6/bin/clang
CXX=/usr/local/clang6/bin/clang++
CXX1X=/usr/local/clang6/bin/clang++
CXX98=/usr/local/clang6/bin/clang++
CXX11=/usr/local/clang6/bin/clang++
CXX14=/usr/local/clang6/bin/clang++
CXX17=/usr/local/clang6/bin/clang++
LDFLAGS=-L/usr/local/clang6/lib

Which only results in a different error:
ld: warning: text-based stub file 
/System/Library/Frameworks//JavaVM.framework/JavaVM.tbd and library file 
/System/Library/Frameworks//JavaVM.framework/JavaVM are out of sync. Falling 
back to library file for linking.
ld: library not found for -lomp

Any ideas?


That is not an *error*!  It is a warning from the OS (ld is part of the 
OS) about parts of the OS being out of step, and has been going on for 
some time (AFAIR with High Sierra too).  You have not shown us the 
complete output, but on my systems installation of CRAN rJava proceeds.



--
--
Jonathan A. Greenberg, PhD
Randall Endowed Professor and Associate Professor of Remote Sensing
Global Environmental Analysis and Remote Sensing (GEARS) Laboratory
Natural Resources & Environmental Science
University of Nevada, Reno
1664 N Virginia St MS/0186
Reno, NV 89557
Phone: 415-763-5476
http://www.unr.edu/nres
Gchat: jgrn...@gmail.com, Skype: jgrn3007



--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

[R-SIG-Mac] Installing R on 10.14 (Mojave)

[Prof Brian Ripley]

A heads up:

The Mojave update removes /usr/include and (re)installing the Command 
Line Tools does not put the standard system headers there.  Workarounds 
are now described in the R-admin manual for R-devel and R-patched.


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] disabling threads when using Accelerate BLAS

[Prof Brian Ripley]

On 08/09/2018 22:01, Kasper Daniel Hansen wrote:

For timing purposes, is it possible to control the number of threads /
cores when I have compiled R to use the BLAS in the Accelerate framework
(by building R using
   ./configure --with-blas="-framework Accelerate" --with-lapack
)

? (The alternative is of course to build R using the supplied
single-threaded BLAS)


This is a question about Accelerate not R.  But the R-admin manual does say

'In recent versions of macOS, threading in Accelerate is controlled by 
‘Grand Central Dispatch’ and is said not to need user control.'


It has quite a few other caveats about Accelerate, not least that it 
uses an LAPACK which is missing many bug fixes, some serious.


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] R and Java 10 ➜ rJava not able to build

[Prof Brian Ripley]

On 27/03/2018 20:25, Luis Puerto wrote:
...

rJava is not yet compatible with Java 10


Is the correct answer.  How to work around this is in the current 
manual, specifically R-admin for R 3.5.0 alpha or R-devel.


Java 10 has been out for 8 days, and the rJava maintainer was made aware 
of the issues early this month, several other package maintainers only 
today.  The advice is to stick to an LTS release of Java (currently 8) 
unless you know what you are doing.


And don't post to multiple lists!

--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] package building

[Prof Brian Ripley]

On 12/03/2018 23:01, Julia Silge wrote:

Hello there! I maintain the tidytext package:
https://cran.r-project.org/web/checks/check_results_tidytext.html

Recently I have been working to get tidytext to build on R-oldrel, and I
believe that v0.1.7 should do so. The check page above shows that v0.1.6 is
what is being checked for OSX on R-oldrel, though. (I do not expect v0.1.6
to pass on R-oldrel.)

Does anyone know why the most recent version isn't being tested?


My understanding is that packages for r-oldrel-osx-x86_64 will not be 
updated as the build machine has died.  Simon Urbanek has asked CRAN to 
remove those results, and doing so is in progress.


If you look at

https://cran.r-project.org/bin/macosx/mavericks/contrib/r-oldrel/?C=M;O=D

you will see the last package built was on 2018-01-11 .

In any case, package support for R-oldrel (3.3.x) officially finishes 
once the following series (3.4.x) is signed off, which is on Thursday 
this week.




Thanks,
Julia



--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] Update of RcppParallel failed

[Prof Brian Ripley]

On 14/02/2018 14:01, Keith O'Hara wrote:

This looks like an issue to bring up with the Rcpp guys, not R… but can you 
provide a full printout of the error? I’m guessing this failed when compiling a 
C file, not C++.


RcppParalllel is not part of Rcpp, and orphaned.  It seems to be a 
mac-specific issue (it is not happening on other platforms with clang).


There is a bug in src/Makevars.  The line

PKG_CPPFLAGS += $(CXX1XSTD) -I../inst/include/

should refer to PKG_CXXFLAGS.  I'll fix that after testing as version 
4.3.20.2.






On Feb 14, 2018, at 8:43 AM, Marc Girondot via R-SIG-Mac 
 wrote:

This morning I had an update to apply for RcppParallel but it failed

Here are some information:


update.packages()

RcppParallel :
  Version 4.3.20 installed in 
/Library/Frameworks/R.framework/Versions/3.5/Resources/library
  Version 4.3.20.1 available at https://cran.r-project.org

During instal, I had this error

error: invalid argument '-std=gnu++11' not allowed with 'C'

It failed with the two versions of clang that I have installed:

clang++ --version
clang version 5.0.1 (tags/RELEASE_501/final)
Target: x86_64-apple-darwin17.4.0
Thread model: posix
InstalledDir: /usr/local/opt/llvm/bin

or

clang++ --version
Apple LLVM version 9.0.0 (clang-900.0.39.2)
Target: x86_64-apple-darwin17.4.0
Thread model: posix
InstalledDir: 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Do you have some idea about what's happened and how to solve this problem ?

Thanks

Marc

_

Information on my R version:


R.Version()

$platform
[1] "x86_64-apple-darwin15.6.0"

$arch
[1] "x86_64"

$os
[1] "darwin15.6.0"

$system
[1] "x86_64, darwin15.6.0"

$status
[1] "Under development (unstable)"

$major
[1] "3"

$minor
[1] "5.0"

$year
[1] "2018"

$month
[1] "02"

$day
[1] "13"

$`svn rev`
[1] "74247"

$language
[1] "R"

$version.string
[1] "R Under development (unstable) (2018-02-13 r74247)"

$nickname
[1] "Unsuffered Consequences"

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


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




--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] trying to compile packages from source, but lacking /opt/local/bin/gcc-mp-5

[Prof Brian Ripley]

On 21/11/2017 04:03, Vincent Carey wrote:

%vjcair> R CMD config CC

/opt/local/bin/gcc-mp-5


I don't seem to be able to override this using environment variable CC.  And


When all else fails, read the manual (but, see the posting guide, before 
posting here)!  This is covered in, e.g.,


https://cran.r-project.org/doc/manuals/r-release/R-admin.html#macOS-packages

https://cran.r-project.org/doc/manuals/r-release/R-admin.html#Customizing-package-compilation



I cannot see how to install gcc-mp-5.  This version of R was obtained from

r.research.att.com, R-3.4-branch-el-capitan.pkg.


I would have expected clang to be the c compiler for this build.  I will


It was for the released version of 3.4.2.  Problems with off-CRAN builds 
are best addressed to the builder, here Simon Urbanek.  But that is a 
month-old snapshot build ... I don't understand why you did not simply 
update it, and I see 'clang' in the current snapshot.





appreciate any suggestions.  As it stands, any installation from source
requiring

compilation throws errors like

/bin/sh: /opt/local/bin/g++-mp-5: No such file or directory


R version 3.4.2 Patched (2017-10-20 r73567) -- "Short Summer"

Copyright (C) 2017 The R Foundation for Statistical Computing

Platform: x86_64-apple-darwin15.6.0 (64-bit)


R is free software and comes with ABSOLUTELY NO WARRANTY.

You are welcome to redistribute it under certain conditions.

Type 'license()' or 'licence()' for distribution details.


   Natural language support but running in an English locale


R is a collaborative project with many contributors.

Type 'contributors()' for more information and

'citation()' on how to cite R or R packages in publications.


Type 'demo()' for some demos, 'help()' for on-line help, or

'help.start()' for an HTML browser interface to help.

Type 'q()' to quit R.



sessionInfo()


R version 3.4.2 Patched (2017-10-20 r73567)

Platform: x86_64-apple-darwin15.6.0 (64-bit)

Running under: macOS Sierra 10.12.6


Matrix products: default

BLAS:
/Library/Frameworks/R.framework/Versions/3.4/Resources/lib/libRblas.0.dylib

LAPACK: /Library/Frameworks/R.framework/Versions/3.4

[[alternative HTML version deleted]]

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




--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

[R-SIG-Mac] R 3.4.2 on High Sierra (10.13)

[Prof Brian Ripley]

[Repeating for convenient reference a comment in an earlier thread.]

R 3.4.2 was in code freeze when High Sierra as released, and so there 
was no opportunity to make and test workarounds for undocumented changes 
to the latter.


R will be unable to find the system timezone on High Sierra (confirmed 
with the CRAN 3.4.2 release):


> Sys.timezone()
[1] NA
> .leap.seconds
 [1] "1972-07-01 GMT" "1973-01-01 GMT" "1974-01-01 GMT" "1975-01-01 GMT"
 [5] "1976-01-01 GMT" "1977-01-01 GMT" "1978-01-01 GMT" "1979-01-01 GMT"
 [9] "1980-01-01 GMT" "1981-07-01 GMT" "1982-07-01 GMT" "1983-07-01 GMT"
[13] "1985-07-01 GMT" "1988-01-01 GMT" "1990-01-01 GMT" "1991-01-01 GMT"
[17] "1992-07-01 GMT" "1993-07-01 GMT" "1994-07-01 GMT" "1996-01-01 GMT"
[21] "1997-07-01 GMT" "1999-01-01 GMT" "2006-01-01 GMT" "2009-01-01 GMT"
[25] "2012-07-01 GMT" "2015-07-01 GMT" "2017-01-01 GMT"
Warning message:
In as.POSIXlt.POSIXct(x, tz) : unknown timezone 'default/Europe/London'


Perhaps the best workaround is to use R-patched from 
http://r.research.att.com/ .  However, in almost all cases a workaround 
is to set TZ, either outside the session (not so easy for R.app) or at 
the beginning of the session by e.g.


Sys.setenv(TZ = "Europe/London")

(where the correct value will be obvious from running the code above).

--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] Xcode 9

[Prof Brian Ripley]

On 27/09/2017 03:28, Kasper Daniel Hansen wrote:

I don't see this with
   Xcode 9
   OS X Sierra (10.12.6)

and either

R Under development (unstable) (2017-09-26 r73351) -- "Unsuffered
Consequences"
Copyright (C) 2017 The R Foundation for Statistical Computing
Platform: x86_64-apple-darwin16.7.0 (64-bit)

or

R version 3.4.2 RC (2017-09-26 r73351) -- "Short Summer"
Copyright (C) 2017 The R Foundation for Statistical Computing
Platform: x86_64-apple-darwin16.7.0 (64-bit)

Specifically I can compile R and it passes make check.  Perhaps it got
fixed since the post.


It did (look at the logs for r73347 and r73351), but also we have 
discovered that not all upgrades to Xcode 9 had the problem.


While we are at it, there is a problem with finding the default time 
zone on High Sierra.  This is worked around already in R-devel and will 
be in 3.4.2 patched: until then setting TZ is a good workaround (and 
that is in the R-admin manual for 3.4.2 RC).




On Fri, Sep 22, 2017 at 4:47 AM, peter dalgaard  wrote:


Just a quick note: Xcode 9 will not presently create a working R on Sierra
or earlier.


(I don't believe Xcode 9 is available for '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



[[alternative HTML version deleted]]

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




--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

Re: [R-SIG-Mac] R3.4.0 Upgrade from R3.3.3

[Prof Brian Ripley]

Note that at the moment there are many missing binary packages for 
3.4.0, and BioC will update all their versions when BioC 3.5 is released 
this coming week.  So I would wait a few days before updating, 
especially if you prefer to use binary packages.


> nrow(available.packages(, type="source"))
[1] 10477
> nrow(available.packages(, type="binary"))
[1] 9779

whereas for 3.3.3 10356 are available.

On 23/04/2017 09:35, peter dalgaard wrote:

Yes, especially this time, since the toolchain has been updated.

My favourite procedure for this goes like

(pkgs <- .libPaths())
(pkgs.old <- sub("3.4", "3.3", pkgs, fixed=TRUE))
(pkgs.new <- setdiff(list.files(pkgs.old), list.files(pkgs)))

Check for sanity(!), then install.packages(pkgs.new). Things may need 
modification if yor setup involves personalized libraries, multiple repos, etc.

Just copying the entire directory followed by update.packages(checkBuilt=TRUE) 
will overwrite packages from the installation of 3.4 and not all of those are 
CRAN based.

[To tell the truth, I don't usually practice what I preach. I just install the 
missing packages when it turns out that I need them...]

-pd


On 23 Apr 2017, at 05:49 , Roy Mendelssohn - NOAA Federal 
 wrote:

I keep forgetting.  So if I jump from R3.3.3 to R3.4.0 is it necessary (or at 
least advisable) to re-install packages?

Thanks,

-Roy



--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] pcre on OS X

[Prof Brian Ripley]

On 10/03/2017 20:38, de Leeuw, Jan wrote:

Not sure of this has already been discussed. There is now a libpcre
sitting in /usr/lib (OS X 10.12.4) and R-devel does not like


OS X / macOS has had pcre 8.02 for years, and R has required at least 
8.12 for years.  (opensource.apple.com is currently broken, so I cannot 
check how many years.)



that version. So I had to use LDFLAGS to link with the pcre from
homebrew if I wanted the build to finish.


If all else fails, read the manual (§C.3):

'Those and other binary components are available from 
https://r.research.att.com/libs: you will need pcre and xz (for libzma) 
as recent macOS versions provide libraries but not headers for these 
(and the system pcre is too old at version 8.02).'


That build of pcre 8.36 is static, and so avoids any problems with 
dynamic load paths.  It is trivial to build later versions (statically) 
from the PCRE sources for yourself.




=
Jan de Leeuw, Distinguished Professor Emeritus, UCLA Statistics
http://gifi.stat.ucla.edu — https://www.facebook.com/jan.deleeuw1
=



--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] Fwd: Mac binaries for R devel

[Prof Brian Ripley]

On 27/02/2017 19:41, Obenchain, Valerie wrote:

Re-sending ... this went out before I joined the r-sig-mac list so the
original is being held for moderation.


In the absence of a quick response from Simon (and you wrote to a list, 
not a person):


Note that 3.4.0 does not have a release date yet (except not before Apr 15).

Discussion on the minimal supported macOS version and supported 
toolchains has started, but I don't expect decisions until the 
month-long run-in period for 3.4.0.  I am sure once that is in place, 
binary packages will be produced when possible.




Valerie



 Forwarded Message 
Subject:Mac binaries for R devel
Date:   02/27/2017 07:47 AM
From:   Obenchain, Valerie 
To: r-sig-mac@r-project.org 



Hi Simon,

We're trying to clean up the Bioconductor builds for the upcoming April
release. I see we don't have mac binaries on CRAN for R devel (3.4). Are
you planning to build those before the next release?

Another question is what OS X will be used in the next R devel after the
April release. Is it safe to assume it will also be Mavericks or should
we prepare for one of the others - Yosemite, El Capitan or Sierra?

Thanks.

Valerie


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] Feature request: install R in ~/Library/Frameworks

[Prof Brian Ripley]

On 07/02/2017 15:26, Gábor Csárdi wrote:

On Tue, Feb 7, 2017 at 10:54 AM, Gábor Csárdi <csardi.ga...@gmail.com
<mailto:csardi.ga...@gmail.com>> wrote:

On Tue, Feb 7, 2017 at 10:22 AM, Prof Brian Ripley
<rip...@stats.ox.ac.uk <mailto:rip...@stats.ox.ac.uk>> wrote:
[...]

Well, you have missed the point.  R itself allows you to do
that: do read 'R Installation and Administration'.


[...]

For use as 'R' from a terminal, multiple CRAN distributions (of
3.x.y for different 'x') can easily be installed and used
together: that is §4.3 of the manual.


Yes, I indeed missed this. Thanks much for the explanation!


One more question. I suppose if I install the various minor versions on
different disks (e.g. I want 3.3.2 and 3.3.3 as well), that would work
fine as well, and I don't even need pkgutil --forget? Or am I missing
something?


You can install in different locations.  I have never tried using 
different 'volumes' (in Apple parlance), but AFAIK Apple treats them 
separately (with separate records of packages installed).



--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] Feature request: install R in ~/Library/Frameworks

[Prof Brian Ripley]

On 07/02/2017 09:02, 美彦 馬場 wrote:

Hi,


On Feb 7, 2017, at 17:46, Gábor Csárdi  wrote:

Hi all,

I realize that this is not the typical use case on macOS, but for my work,
it would be great to be able to install R into ~/Library/Frameworks.

This would allow having different R versions for different users.

I am not sure how difficult this would be to implement. I can see that some
paths in scripts and makefiles are hardwired to /Library/Frameworks. Is
there anything more, perhaps in the binaries as well?



I install R with Fink, which allows you to install R-3.3, R-3.2 and R-3.1.  
Each of them looks for files in 
/sw/Library/Frameworks/R.framework/Versions/3.3, 3.2 and 3.1 respectively.  
Also, CRAN packages for different R versions are installed separately.


Well, you have missed the point.  R itself allows you to do that: do 
read 'R Installation and Administration'.


The reason to install R as a framework is to use R.app (and it is no 
longer the default for a source build).  And it is R.app which is tied 
to /Library/Frameworks/R.framework (and the 'Current' version).  Even 
though there is a Rswitch utility to switch the version R.app invokes, 
it is unreliable as R.app is built against a particular R version and 
may well crash if used with another.  R.app is not itself versioned, and 
there is no way to install it telling it to link to a particular version 
of the R framework.


For use as 'R' from a terminal, multiple CRAN distributions (of 3.x.y 
for different 'x') can easily be installed and used together: that is 
§4.3 of the manual.


Quite a lot of trouble has been taken to avoid the 'R' front-end script 
on macOS, and that does involve hard-coding the installation path in 
many places in the binary distribution.  For example


otool -L 
/Library/Frameworks/R.framework/Resources/library/Matrix/libs/Matrix.so

/Library/Frameworks/R.framework/Resources/library/Matrix/libs/Matrix.so:
Matrix.so (compatibility version 0.0.0, current version 0.0.0)

/Library/Frameworks/R.framework/Versions/3.3/Resources/lib/libRlapack.dylib 
(compatibility version 3.3.0, current version 3.3.2)

/Library/Frameworks/R.framework/Versions/3.3/Resources/lib/libRblas.dylib 
(compatibility version 0.0.0, current version 0.0.0)

/Library/Frameworks/R.framework/Versions/3.3/Resources/lib/libgfortran.3.dylib 
(compatibility version 4.0.0, current version 4.0.0)

/Library/Frameworks/R.framework/Versions/3.3/Resources/lib/libquadmath.0.dylib 
(compatibility version 1.0.0, current version 1.0.0)

I do not recall how much of this is done by the R scripts for installing 
to a framework and how much by the scripts used to build the installer 
(although AFAIR libgfortran.3.dylib is part of the latter).


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] R patched version for Mac

[Prof Brian Ripley]

On 27/12/2016 19:19, Watson, David W. (MSFC-ES62) wrote:

I have been trying to download the “patched” version of 3.3.2 for Mac from CRAN,


What makes you think there is a patched version on CRAN?  Did you follow 
the link on https://cran.r-project.org/bin/macosx/
to 
http://r.research.att.com/mavericks/R-3.3-branch/R-3.3-branch-mavericks.pkg? 
 That is Simon Urbanek's site, so you need to ask him.


 but the version that gets delivered is actually the October Release 
Candidate version,

(R version 3.3.2 RC (2016-10-26 r71594). It has been doing this since 3.3.2 has 
been released. Is there a real patched version somewhere?

David Watson
NASA - MSFC
Mail Code ES62
Phone 256-544-1300
FAX   256-544-2964
david.w.wat...@nasa.gov



--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] Does R CMD check create invisible files?

[Prof Brian Ripley]

On 16/12/2016 11:44, cstrato wrote:

Dear all,

On my Mac running Yosemite I zip my package:

   $ tar czf xps_1.35.1.tar.gz xps

The directoy 'xps' does not contain any hidden files!

However, when I run:

   $ R CMD check xps_1.35.1.tar.gz

I get:
...
* checking for hidden files and directories ... NOTE
Found the following hidden files and directories:
  .BBSoptions
  ._.BBSoptions
  ._ACKNOWLEDGMENT
  ._DESCRIPTION
...
etc

When I unzip my package using:

   $ tar xvfz xps_1.35.1.tar.gz xps

there are still no hidden files!


However, the src directory created by R CMD check, i.e.

CS-iMac:CRAN cstrato$ cd xps.Rcheck/00_pkg_src/xps/
CS-iMac:xps cstrato$ ls -al
total 504
drwxr-xr-x   40 cstrato  staff   1360 Dec 16 10:30 .
drwxr-xr-x4 cstrato  staff136 Dec 16 10:29 ..
-rw-r--r--1 cstrato  staff 26 Sep 30 23:33 .BBSoptions
-rw-r--r--1 cstrato  staff181 Sep 30 23:33 ._.BBSoptions
-rw-r--r--1 cstrato  staff181 Sep 30 23:33 ._ACKNOWLEDGMENT
-rw-r--r--1 cstrato  staff181 Dec 16 10:20 ._DESCRIPTION
-rw-r--r--1 cstrato  staff181 Dec 16 10:26 ._NAMESPACE

does indeed contain hidden files from all my files!


Can anybody explain this behavior and tell me how to avoid this behavior?


Those are fork files: the OS X tar differs from POSIX by treating Apple 
forks in a non-POSIX-standard way, and *by default* R CMD check does not 
use the OS's tar command (as ?check explains).


Do read and follow the documentation: use R CMD build not your OS's tar 
to 'zip' (your incorrect terminology) a package. (Or read the source 
code for tar() and note that it sets various environment variables on OS X.)


fortunes::fortune(14) really does apply.



Here are my infos:


Sys.info()

sysname
"Darwin"
release
"14.5.0"
version
"Darwin Kernel Version 14.5.0: Sun Sep 25 22:07:15 PDT 2016;
root:xnu-2782.50.9~1/RELEASE_X86_64"
nodename
"CS-iMac.local"
machine
"x86_64"
login
"_spotlight"
user
"cstrato"
effective_user
"cstrato"


sessionInfo()

R version 3.3.2 (2016-10-31)
Platform: x86_64-apple-darwin13.4.0 (64-bit)
Running under: OS X Yosemite 10.10.5

locale:
[1] C

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base


Thank you in advance
Best regards,
Christian
_._._._._._._._._._._._._._._._._._
C.h.r.i.s.t.i.a.n   S.t.r.a.t.o.w.a
V.i.e.n.n.a   A.u.s.t.r.i.a
e.m.a.i.l:cstrato at aon.at
_._._._._._._._._._._._._._._._._._



--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-SIG-Mac] Fortran on MacOS Sierra

[Prof Brian Ripley]

This seems to be Sierra, which has 'tidied up' system libraries.

The recommendation for El Capitan at http://coudert.name/software.html 
also works correctly on Sierra. (See the manual, preferably before posting.)


There are good reasons why the posting guide asks for 'at a minimum' the 
output of sessionInfo() 


On 30/09/2016 09:31, Ken Beath wrote:

I tried to build frailtypack from source using R 3.3.1 and it failed with the 
following message (after a ridiculous amount of warnings)

gfortran-4.8 -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup 
-single_module -multiply_defined suppress 
-L/Library/Frameworks/R.framework/Resources/lib -L/usr/local/lib -o frailtypack.so 
Adonnees.o AparamMultive.o Aparameters.o aGhermite.o aaOptim.o aaOptimres.o 
aaUseFunction.o aaUseFunctionG.o aamarq98o.o additive.o afuncpasres.o ahrmsym.o 
aresidusMartingale.o atestWald.o distance.o epoce.o epoce_log.o epoce_long.o 
frailtypack.o funcpaG_tps.o funcpaGcpm.o funcpaGcpm_intcens.o funcpaGcpm_log.o 
funcpaGsplines.o funcpaGsplines_intcens.o funcpaGsplines_log.o funcpaGweib.o 
funcpaGweib_intcens.o funcpaGweib_log.o funcpaMultivCpm.o funcpaMultivSplines.o 
funcpaMultivWeib.o funcpaacpm.o funcpaasplines.o funcpaaweib.o funcpaj_tps.o 
funcpajcpm.o funcpajcpm_log.o funcpajgeneral.o funcpajlongisplines.o 
funcpajlongiweib.o funcpajsplines.o funcpajsplines_fam.o funcpajsplines_intcens.o 
funcpajsplines_log.o funcpajweib.o funcpajweib_fam.o funcpajweib_intcens.o 
funcpajweib_log.o f... 
gfortran-4.8: warning: couldn’t understand kern.osversion ‘16.0.0
ld: library not found for -ldylib1.o
collect2: error: ld returned 1 exit status
make: *** [frailtypack.so] Error 1
ERROR: compilation failed for package ‘frailtypack’

I was going to attempt the build with gfortran 4.2 but haven’t been able to 
revert back from 4.8

So does it happen with 4.2 and if not, how can I revert back?

If not is this an R problem or the package?


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

Re: [R-SIG-Mac] Experiences with macOS Sierra

[Prof Brian Ripley]

On 22/09/2016 14:01, Kasper Daniel Hansen wrote:

Thanks for the work on this, especially the comment on xml2.  I had
noticed problems with xml2 while compiling Emacs 25.1 using the new
Xcode on El Capitan, but I have not had time to track it down.


I had found a workaround for Xcode 8 on El Capitan: copy 
/usr/bin/xml2-config to somewhere earlier on your path (~/bin in my 
case) and edit line 3 from


prefix=$(xcrun -show-sdk-path)/usr

to

prefix=/usr




Best,
Kasper

On Thu, Sep 22, 2016 at 2:39 AM, Prof Brian Ripley
<rip...@stats.ox.ac.uk <mailto:rip...@stats.ox.ac.uk>> wrote:

So far I have encountered few problems.  R.app runs but I do not
normally use it so my tests were minimal.

My observations are about installing packages from source.

- It seems Apple has been tidying up, and I had ca 20GB more free
space after upgrading (which is worthwhile on my MBA with a 128GB
SSD).  It seems that includes removing some headers, including those
for openssl (used by packages PKI and RSclient - package opensssl
uses its own). This is but the latest instance in a long-term trend,
e.g. iodbc, pcre and liblzma have libraries but no headers.

- Finally the POSIX 2008 function clock_gettime is supported (and
will be used by R): but package scrypt calls it incorrectly.

Xcode 8 is available for EL Capitan but I would caution against
using it there (despite it being pushed as an update from the
AppStore).  AFAICS (and googling will find other reports) it
defaults to the macOS 10.12 SDK and that declares functions such as
clock_gettime not available in El Capitan.  (I believe that R checks
thoroughly enough not to be caught by this.)

There is a further problem with Xcode 8, also seen on Sierra.
Packages using xml2-config (such as XML) fail to install.  Apple
modified xml2-config to look on the SDK path, which means packages
using it attempt to link to .tbd files rather than .dylibs.  Which
should be OK but the supplied .tbd attempt to link to libraries
removed in Sierra and so linking fails. (This is not a problem with
the version 8 of the Command Line Tools, only available for Sierra.)

--
Brian D. Ripley,  rip...@stats.ox.ac.uk
<mailto:rip...@stats.ox.ac.uk>
Emeritus Professor of Applied Statistics, University of Oxford

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





--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

[R-SIG-Mac] Experiences with macOS Sierra

[Prof Brian Ripley]

So far I have encountered few problems.  R.app runs but I do not 
normally use it so my tests were minimal.


My observations are about installing packages from source.

- It seems Apple has been tidying up, and I had ca 20GB more free space 
after upgrading (which is worthwhile on my MBA with a 128GB SSD).  It 
seems that includes removing some headers, including those for openssl 
(used by packages PKI and RSclient - package opensssl uses its own). 
This is but the latest instance in a long-term trend, e.g. iodbc, pcre 
and liblzma have libraries but no headers.


- Finally the POSIX 2008 function clock_gettime is supported (and will 
be used by R): but package scrypt calls it incorrectly.


Xcode 8 is available for EL Capitan but I would caution against using it 
there (despite it being pushed as an update from the AppStore).  AFAICS 
(and googling will find other reports) it defaults to the macOS 10.12 
SDK and that declares functions such as clock_gettime not available in 
El Capitan.  (I believe that R checks thoroughly enough not to be caught 
by this.)


There is a further problem with Xcode 8, also seen on Sierra.  Packages 
using xml2-config (such as XML) fail to install.  Apple modified 
xml2-config to look on the SDK path, which means packages using it 
attempt to link to .tbd files rather than .dylibs.  Which should be OK 
but the supplied .tbd attempt to link to libraries removed in Sierra and 
so linking fails. (This is not a problem with the version 8 of the 
Command Line Tools, only available for Sierra.)


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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