[R-SIG-Mac] Problems in install some packages in R 4.2

[José Carlos Guerrero Antúnez]

Hi,

When I upgraded to R version 4.2 (Platform: x86_64-apple-darwin17.0
(64-bit)), I was having problems installing certain packages (e.g. ggplot2,
Hmisc, devtools) and their dependencies.

I got this error message "installation of package ‘package’ had non-zero
exit status.

I have tried several ways to install (e.g. Package Archive file (.tgz).

Any ideas on how to solve this problem, thank you very much.


--
José Carlos Guerrero

[[alternative HTML version deleted]]

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

[Simon Urbanek]

José,

can you be more specific as of what you did and exact output? I would recommend using a simple

install.packages("ggplot2",type="binary")

in R.

Cheers,
Simon

[peter dalgaard]

Marginally related:

The "binary" bit trips up my students from time to time (with tseries recently).

They get the option to install from source because it's marginally newer, answer "yes" because that'w what they always do, and then installation bombs because they don't have the compilers.

Yes, they should know better, but no...

We might want to consider implementing something like capabilities("compilers") so that we can condition the source installs more carefully.


-pd

--
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

[José Carlos Guerrero Antúnez]

Thanks, I was able to install the binary packages.

El mar, 10 may 2022 a las 6:18, peter dalgaard (<pda...@gmail.com>)
escribió:

[Simon Urbanek]

Peter,

I agree that the current behavior is not very helpful for the majority of users. Personally, I'd change the default "no" so that users that don't know or care what it entails can still get the package installed. Note that having a compiler may not be enough, since there are often library dependencies, so compiling from sources should really be attempted only by developers that do it deliberately. The only argument I see for using the "both" default is for cases where the package binary doesn't exist, but that is another story as the user has no choice there.

Cheers,
Simon

PS: version mismatches are in principle expected due to package sources being released before binaries, but should be generally rare. However, there is currently an unusual back-log of package builds for R 4.2.0 on the high-sierra x86_64 system which should hopefully clear by tomorrow.

[peter dalgaard]

We might want to circulate this in R Core, but offhand, I'd say that since the package ecosystem is somewhat platform dependent, it could be in the platform maintainers' domain to set defaults like

options(pkgType="binary")

in the default installation's start-up files. This would make sense on Mac & Windows, but probably not on Linux variants. Users can always override it if needed.

(There's also an issue with pure R packages, which can be source-installed if the source is newer, but the byte-compile may still take a while and not be worth it for an incremental update.)

- Peter

[José Carlos Guerrero Antúnez]

Hi Simon,

Although I was able to install ggplot2 when activating I get this error
message.

What can I do now to solve this problem?

Thank you very much.

> library(ggplot2)
Error: package or namespace load failed for ‘ggplot2’ in dyn.load(file,
DLLpath = DLLpath, ...):
unable to load shared object
'/Library/Frameworks/R.framework/Versions/4.2/Resources/library/tibble/libs/tibble.so':

dlopen(/Library/Frameworks/R.framework/Versions/4.2/Resources/library/tibble/libs/tibble.so,
6): no suitable image found. Did find:
/Library/Frameworks/R.framework/Versions/4.2/Resources/library/tibble/libs/tibble.so:
mach-o, but wrong architecture
/Library/Frameworks/R.framework/Versions/4.2/Resources/library/tibble/libs/tibble.so:
mach-o, but wrong architecture



El lun, 9 may 2022 a las 23:47, Simon Urbanek (<simon....@r-project.org>)
escribió:

[Simon Urbanek]

José,

given your earlier attempts I suspect you may have broken your library by installing the incorrect .tgz package binaries by hand. There are two different Mac architectures now so the package must match your R so it appears you may have installed tibble for the wrong Mac architecture.

You can fix your library by letting R re-install all packages automatically via

install.packages(rownames(installed.packages()), type='binary')

FWIW there was a big back-log that has now cleared, but may take a bit to propagate through the CRAN mirrors, so if your mirror is behind you may want to use the master Mac repository:

install.packages(rownames(installed.packages()), type='binary', repo="https://mac.R-project.org")

Cheers,
Simon

[José Carlos Guerrero Antúnez]

Simon,

I was able to install the packages correctly using the master Mac
repository.

Again, thank you for your work that allows people like me who do not
program to use R.

El mié, 11 may 2022 a las 21:08, Simon Urbanek (<simon....@r-project.org>)