Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DLL 'dplyr' not found: maybe not installed for this architecture? #162

Closed
adamrobinson361 opened this issue Aug 22, 2019 · 11 comments
Closed

Comments

@adamrobinson361
Copy link
Contributor

5.txt
Hi @kevinushey,

Some further findings from the pipeline I've got set up. I seem to be having problems with a number of packages that have been migrated from the packrat cache to the renv cache.

The migrate works fine in the it makes the correct lock file but then when it is trying to restore it seems to fail due to DLL's not found. From reading online this is usually due to a corrupt install and the suggestion is to delete and reinstall. Problem packages started at rlang but as I deleted those I had to delete Rcpp, processx, glue and so on.

My initial thought was were these compiled with a different version of R but that wouldn't be the case as our packrat pipeline set a version specific cache.

I wonder what the problem going on here is and if there is a more elegant solution. I.e. rather than saying DLL not found could it not try and reinstall it?

Wider would be good to understand whats going on here as i'm pretty sure other projects with these packages have worked. Potentially the linking isn't working as expected when installing from source?

Log file attached,

Regards,

Adam

@kevinushey
Copy link
Collaborator

kevinushey commented Aug 22, 2019

Thanks for the bug report. Copying the relevant output:

2019-08-22T09:00:05.6617113Z Error: install of package 'dbplyr' failed
2019-08-22T09:00:05.6617385Z ==================================
2019-08-22T09:00:05.6617430Z 
2019-08-22T09:00:05.6618996Z * installing *source* package 'dbplyr' ...
2019-08-22T09:00:05.6619430Z ** package 'dbplyr' successfully unpacked and MD5 sums checked
2019-08-22T09:00:05.6620273Z ** R
2019-08-22T09:00:05.6620513Z ** inst
2019-08-22T09:00:05.6620575Z ** preparing package for lazy loading
2019-08-22T09:00:05.6621529Z ** help
2019-08-22T09:00:05.6621793Z *** installing help indices
2019-08-22T09:00:05.6621894Z *** copying figures
2019-08-22T09:00:05.6622595Z ** building package indices
2019-08-22T09:00:05.6622851Z ** installing vignettes
2019-08-22T09:00:05.6623908Z ** testing if installed package can be loaded
2019-08-22T09:00:05.6623966Z *** arch - i386
2019-08-22T09:00:05.6624034Z Error: package or namespace load failed for 'dbplyr' in library.dynam(lib, package, package.lib):
2019-08-22T09:00:05.6624101Z  DLL 'dplyr' not found: maybe not installed for this architecture?
2019-08-22T09:00:05.6624160Z Error: loading failed
2019-08-22T09:00:05.6624263Z Execution halted
2019-08-22T09:00:05.6624316Z *** arch - x64
2019-08-22T09:00:05.6624398Z ERROR: loading failed for 'i386'
2019-08-22T09:00:05.6624480Z * removing 'C:/Users/svc-VSTSBldAge-EFABL/AppData/Local/Temp/RtmpMvynPT/renv-tempdir-1f64280b1f7e/renv-templib-1f6474fb6412/dbplyr'

Here's likely what happened:

  1. Some packages were installed only for one specific architecture; that is, x64. dplyr appears to be one such package on your machine.

  2. That version of the package was copied to the cache.

  3. During restore, R CMD INSTALL is attempting to do a multiarch build, rather than a single-arch build (in particular, for dbplyr).

  4. When R attempts to test the package in i386, that attempt fails as the 32-bit version of dplyr was never compiled / installed.

I think the fix here is to just ensure --no-multiarch is passed when renv builds packages, since separate caches and libraries are used for separate architectures anyhow.

@adamrobinson361
Copy link
Contributor Author

Ah id not realised this was the case. I always use 64 bit but recall during building from source with packrat that both the i386 and x64 variants are built.

Does that mean that the i386 build was really redundant as I’d always be using x64.

Further, does this mean that only one build will be done now for each package in effect halving restore time?

@kevinushey
Copy link
Collaborator

Yes indeed! (Not quite half, but it should be substantially faster)

@kevinushey
Copy link
Collaborator

This should be fixed now, so I'll close this issue -- please feel free to re-open if you bump into this again.

@KyriakisDimitrios
Copy link

KyriakisDimitrios commented Feb 3, 2020

This should be fixed now, so I'll close this issue -- please feel free to re-open if you bump into this again.

Hi, I didnt get the solution. I initialized renv. Then I opened the activate.R file which created and add ("--preclean", "--no-multiarch")

 bin <- R.home("bin")
    exe <- if (Sys.info()[["sysname"]] == "Windows") "R.exe" else "R"
    r <- file.path(bin, exe)
    args <- c("--vanilla", "CMD", "INSTALL","--preclean", "--no-multiarch", "-l", shQuote(libpath), shQuote(destfile))
    output <- system2(r, args, stdout = TRUE, stderr = TRUE)
    message("Done!")

Then I opened again R and try to install a package but again the same:

*** arch - i386                                                                                                                                                             Warning: package 'IRanges' was built under R version 3.6.2
Warning: package 'S4Vectors' was built under R version 3.6.2
Error: package or namespace load failed for 'AnnotationDbi' in library.dynam(lib, package, package.lib):                                                                     DLL 'rlang' not found: maybe not installed for this architecture?
Error : package 'AnnotationDbi' could not be loaded
Error: loading failed
Execution halted
*** arch - x64
Warning: package 'IRanges' was built under R version 3.6.2
Warning: package 'S4Vectors' was built under R version 3.6.2
ERROR: loading failed for 'i386'

@kevinushey
Copy link
Collaborator

The activate script is used only for installing renv itself -- it does not affect installation of other packages.

A reproducible example would be helpful.

@KyriakisDimitrios
Copy link

The activate script is used only for installing renv itself -- it does not affect installation of other packages.

A reproducible example would be helpful.

if (!requireNamespace("remotes"))
  install.packages("remotes")

remotes::install_github("rstudio/renv")

renv::init( bare=TRUE)
install.packages("BiocManager")
BiocManager::install('org.Hs.eg.db')

So where I should add the "--no-multiarch" in order to avoid installing the packages in multiple arch?
thanks

@kevinushey
Copy link
Collaborator

It would have to happen in your call to BiocManager::install().

E.g. for install.packages():

install.packages("BiocManager", INSTALL_opts = c("--no-multiarch"))

I'm assuming something similar would work for BiocManager::install(), but I'm not sure. Ultimately though, isn't this issue independent of renv?

@KyriakisDimitrios
Copy link

It would have to happen in your call to BiocManager::install().

E.g. for install.packages():

install.packages("BiocManager", INSTALL_opts = c("--no-multiarch"))

--> I'm assuming something similar would work for BiocManager::install(), but I'm not sure.

Thanks it worked.

--> Ultimately though, isn't this issue independent of renv?
When I tried with conda env it worked without ("--no-multiarch"), I had other issues with conda so i decided to work with renv. I did not know if it was associated with renv. When I read this post and I saw the same error, when adamrobinson tried to migrate packages from the packrat cache to the renv cache.

Thank you again,

@CorradoLanera
Copy link

Just to let you know: I have the same issue installing a package from github

Issue

Calling:

remotes::install_github("CorradoLanera/depigner")

It produced:

Using github PAT from envvar GITHUB_PAT
Downloading GitHub repo CorradoLanera/depigner@masterchecking for file 'C:\Users\corra\AppData\Local\Temp\RtmpKMO9tr\remotes28e0197a2ceb\CorradoLanera-depigner-cc06d2f/DESCRIPTION' (394ms)
-  preparing 'depigner': (340ms)
√  checking DESCRIPTION meta-information ... 
-  checking for LF line-endings in source and make files and shell scripts (347ms)
-  checking for empty or unneeded directories
-  looking to see if a 'data/datalist' file should be added
-  building 'depigner_0.5.1.tar.gz'
   
Installing package intoC:/Users/corra/Documents/<path_to_my_project>/renv/library/R-3.6/x86_64-w64-mingw32’
(aslibis unspecified)
* installing *source* package 'depigner' ...
** using staged installation
** R
** data
*** moving datasets to lazyload DB
** inst
** byte-compile and prepare package for lazy loading
** help
*** installing help indices
  converting help for package 'depigner'
    finding HTML links ... done
    Arthritis                               html  
    adjust_p                                html  
    check_for_bot_options                   html  
    check_pkg                               html  
    ci2p                                    html  
    depigner-package                        html  
    errors_to_telegram                      html  
    gdp                                     html  
    paired_test_categorical                 html  
    paired_test_continuous                  html  
    pb_len                                  html  
    pipe                                    html  
Rd warning: C:/Users/corra/AppData/Local/Temp/Rtmp61AlWg/R.INSTALL44a0737b9d9/depigner/man/pipe.Rd:10: file link '%>%' in package 'magrittr' does not exist and so has been treated as a topic
    please_install                          html  
    send_to_telegram                        html  
    start_bot_for_chat                      html  
    finding level-2 HTML links ... done

Rd warning: C:/Users/corra/AppData/Local/Temp/Rtmp61AlWg/R.INSTALL44a0737b9d9/depigner/man/start_bot_for_chat.Rd:49: file link 'edit_r_environ' in package 'usethis' does not exist and so has been treated as a topic
    summary_interact                        html  
    tidy_summary                            html  
    ubesp_pkg                               html  
    use_ui                                  html  
** building package indices
** testing if installed package can be loaded from temporary location
*** arch - i386
Error: package or namespace load failed for 'depigner' in library.dynam(lib, package, package.lib):
 DLL 'glue' not found: maybe not installed for this architecture?
Error: loading failed
Execution halted
*** arch - x64
Welcome to depigner: we are here to un-stress you!
ERROR: loading failed for 'i386'
* removing 'C:/Users/corra/Documents/<path_to_my_project>/renv/library/R-3.6/x86_64-w64-mingw32/depigner'
Error: Failed to install 'depigner' from GitHub:
  (converted from warning) installation of packageC:/Users/corra/AppData/Local/Temp/RtmpKMO9tr/file28e016e26e87/depigner_0.5.1.tar.gzhad non-zero exit status

Solution

Solved by your strategy:

remotes::install_github("CorradoLanera/depigner",
  INSTALL_opts = c("--no-multiarch")
)

Thanks!

@brshallo
Copy link

I had an identical issue with not being able to install an internal git repo from Azure repos to local renv projects but with rlang, i.e.:
DLL 'rlang' not found: maybe not installed for this architecture?

The rlang install for my renv library specifically had not contained "renv\library\R-3.5\x86_64-w64-mingw32\rlang\libs\i386" -- r-lib/rlang#966 may be relevant.

The INSTALL_opts = c("--no-multiarch") to remotes::install_github() fixed my issue as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants