Skip to content

Conversation

@jmcphers
Copy link
Contributor

@jmcphers jmcphers commented Dec 2, 2025

Ark's default DLL search strategy doesn't work for Conda R since it depends on libraries shipped with Conda that are not placed in either of the locations Ark currently looks (alongside the R binary and in the same path as R.dll itself).

This change adds a --dll-search-path option (only for Windows) that searches PATH for DLLs, or (more accurately) it enables Windows' default DLL search behavior, which includes checking PATH.

The change shouldn't affect DLL resolution for other R installations; for those, we continue to use the same strategy we do today.

Part of posit-dev/positron#4398.

@jmcphers jmcphers requested a review from DavisVaughan December 2, 2025 00:19
Copy link
Contributor

@DavisVaughan DavisVaughan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems fine if this "just works" for conda, I don't really see a better way.

Make sure to merge #973 into this first if you agree with that change

Comment on lines 11 to 14
#[cfg(windows)]
use std::sync::atomic::AtomicBool;
#[cfg(windows)]
use std::sync::atomic::Ordering;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We've tried hard to contain OS specific stuff in sys/windows/ or sys/unix/ so we can avoid the cfgs everywhere

See #973 for an alternate approach that you can merge into this

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks, that's better!


// Windows-specific options
#[cfg(target_os = "windows")]
print!(r#"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When I save in this file, rust-analyzer reformats this a little. Can you please check the formatting first before merging?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like rustfmt was failing silently on my Windows machine. 😭 Fixed.

@DavisVaughan
Copy link
Contributor

Adding some extra context to this for future us

R's DLL is located in /path/to/dlls/R.dll on Windows. This /path/to/dlls/ folder also holds other R dlls, like Rblas.dll. When "normal" R loads, it needs to be able to find these DLLs, but they are not found via Window's standard search order for DLLs: https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order#standard-search-order-for-unpackaged-apps

In particular, /path/to/dlls/ is not on the PATH for Windows, so it is not checked, and none of the other search locations would find it either.

To work around this, we instead use:

  • LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR to ensure /path/to/dlls/ is searched to find things like Rblas.dll
  • LOAD_LIBRARY_SEARCH_SYSTEM32 to ensure the system32 directory is searched, which R seems to need for some other DLLs (I think it was iconv, but I'm not sure)

This was enough for regular R, but conda R is different.

In Conda R, the R.dll and Rblas.dll are located in something like:

c:\\Users\\jmcph\\miniconda3\\envs\\r_env\\Lib\\R\\bin\\x64

Conda will put this location on the PATH for you, so if we do the standard Windows search order, it will find all the required R dlls.

Conda will also put these locations on the PATH

[Environment] libgcc_s_seh-1.dll : c:\Users\jmcph\miniconda3\envs\r_env\Library\bin\libgcc_s_seh-1.dll      
[Environment] deflate.dll : c:\Users\jmcph\miniconda3\envs\r_env\Library\bin\deflate.dll
[Environment] icuin75.dll : c:\Users\jmcph\miniconda3\envs\r_env\Library\bin\icuin75.dll
[Environment] icuuc75.dll : c:\Users\jmcph\miniconda3\envs\r_env\Library\bin\icuuc75.dll
[Environment] libbz2.dll : c:\Users\jmcph\miniconda3\envs\r_env\Library\bin\libbz2.dll
[Environment] liblzma.dll : c:\Users\jmcph\miniconda3\envs\r_env\Library\bin\liblzma.dll
[Environment] pcre2-8.dll : c:\Users\jmcph\miniconda3\envs\r_env\Library\bin\pcre2-8.dll
[Environment] zlib.dll : c:\Users\jmcph\miniconda3\envs\r_env\zlib.dll
[Environment] zstd.dll : c:\Users\jmcph\miniconda3\envs\r_env\Library\bin\zstd.dll

These are DLLs that Conda's version of R specially links to, note that these are not found by LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR or LOAD_LIBRARY_SEARCH_SYSTEM32. That caused Conda R to fail.

But note how these are found by Window's standard dll search ordering.

So, here's the summary:

Regular R:

  • R.dll found by us giving an absolute path to it
  • Rblas.dll found by LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR
  • "Extra" DLLs required by R found by LOAD_LIBRARY_SEARCH_SYSTEM32

Conda R:

  • R.dll found by us giving an absolute path to it
  • Rblas.dll found by standard dll search order
  • "Extra" DLLs found by standard dll search order

Since there is no easy way to detect when we need to switch between these approaches, adding a CLI option seemed like the best option

@jmcphers jmcphers merged commit fe1b397 into main Dec 2, 2025
8 checks passed
@jmcphers jmcphers deleted the feature/windows-dll-search-path branch December 2, 2025 16:52
@github-actions github-actions bot locked and limited conversation to collaborators Dec 2, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants