Re: [R-SIG-Mac] How to correct tcltk path?
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] How to correct tcltk path?
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)
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
>
--
Best,
Kasper
[[alternative HTML version deleted]]
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
[R-SIG-Mac] How to correct tcltk path?
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
Re: [R-SIG-Mac] Debugging Symbols
On Thu, Apr 4, 2024 at 9:47 AM Hannes Mühleisen wrote: > > Hello List, > > we would like to bring up the topic of debug symbols in the CRAN OSX > binaries again. I realize this has been discussed before [1] and > realize the symbols are there for a reason, but in the duckdb package > their inclusion is particularly problematic. > > Currently, the CRAN binary for OSX Arm64 weighs in at a whopping 97 MB > [2]. Inside it lives a 311 MB (uncompressed) folder with the debugging > symbols. When I remove the debugging symbols and re-create the > compressed tarball, its compressed size goes down to 11 MB, a pretty > drastic difference. > > We are getting feedback from users that the package is too large for > them to be useful, so we would really like to improve this situation. FWIW, the binaries on https://duckdb.r-universe.dev/duckdb are built with _R_SHLIB_STRIP_: TRUE and those are indeed around 10M (both for Linux and MacOS). For similar reasons p3m (formerly rspm) also strips debugging symbols these days, e.g: https://p3m.dev/cran/latest/bin/macosx/big-sur-x86_64/contrib/4.3/duckdb_0.10.1.tgz See also this comment: https://github.com/rocker-org/rocker-versioned2/issues/340#issuecomment-1301157428 I agree it would be nice for a package to be able to opt-out altogether, including on CRAN. I don't think that is possible right now. ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
[R-SIG-Mac] Debugging Symbols
Hello List, we would like to bring up the topic of debug symbols in the CRAN OSX binaries again. I realize this has been discussed before [1] and realize the symbols are there for a reason, but in the duckdb package their inclusion is particularly problematic. Currently, the CRAN binary for OSX Arm64 weighs in at a whopping 97 MB [2]. Inside it lives a 311 MB (uncompressed) folder with the debugging symbols. When I remove the debugging symbols and re-create the compressed tarball, its compressed size goes down to 11 MB, a pretty drastic difference. We are getting feedback from users that the package is too large for them to be useful, so we would really like to improve this situation. Would it perhaps be possible to exclude the duckdb from the inclusion of the debug symbols? Is there anything we as package authors can do here? There also may be other packages where this is relevant, e.g. arrow would go down from 82 MB to 12 MB. Best and thanks Hannes [1] https://stat.ethz.ch/pipermail/r-sig-mac/2022-June/014500.html [2] curl -I https://cran.r-project.org/bin/macosx/big-sur-arm64/contrib/4.3/duckdb_0.10.1.tgz ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
