Why does BLAS Switcher needs Admin Rights?

I’ve to deploy GNU Octave 6.2 in a Windows-Domain Network.
So far it looks good. But what’s about “BLAS Switcher”.
It needs admin rights. Why, and what can I do for a nonadmin User?

Is this related to use-of-nvblas-with-octave-on-windows-10?


OS: Windows 10
Gnu Octave 6.2.0

I believe it’s more related to this:

The BLAS Switcher requires a file change and the change in v6 from default installing in C:\Octave to C:\Program Files puts the files in a location users do not normally have write access to.

You could try changing the install folder back to C:\Octave and try again as a user, but reading the bug report it may still prompt to runas admin?

@lostbard Even if they changed install location back to something accessible in users space, if I’m reading that bug report right the shortcut would still produce the runas prompt, correct? Is there a workaround? How easy would it be as part of deployment for them to turn off that runas switch? Or maybe have the last deployment action be to delete that shortcut and recreate one without that switch?

Like @nrjank already wrote, “BLAS Switcher” copies files in Octave’s installation directory.
Specifically, it copies either “librefblas.dll” or “libopenblas.dll” in the “bin” directory to “libblas.dll”.
You can select which version to use in the installer. Maybe you could also manually copy the respective file in your deployment rule.

Edit: If the user needs to frequently switch between different BLAS implementations, consider a local installation.

Thanks for your quick reply :heart_eyes:
I understand the problem, and try to grant access to this folder.
I think it better could go to the users app folder?!

What’s about the installer, it’s a NSIS-Installer with the only option /S, right?

The short answer for why it is like it is: Windows is a bit different from Unix-like systems when it comes to dynamically loaded libraries.
On Linux or BSD, one would probably use LD_PRELOAD to select a particular BLAS implementation. I don’t know of an equivalent mechanism on Windows. So, we copy the libraries forth and back instead.
I haven’t yet experimented with manipulating the PATH variable to achieve something similar on Windows. Maybe, we could have the two libraries (with the same name) in two different directories and set the PATH to include the one or the other. If that works, we wouldn’t need to copy those libraries around any longer…

I don’t think there are any restrictions on where you install Octave. Older versions on windows had issues with paths that included spaces, so it defaulted to C:\Octave instead of the Program Files folder. If this is a deployment, unless I misunderstand your meaning, installing in an individual user’s folder would render it only available to that one user, which would be an issue if you have multiuser systems. Something like reverting back to C:\Octave might get around that problem.

I would still suggest trying that location and having your deployment replace the BLAS Switcher shortcut with a version lacking the RunAs switch. That would seem most likely to work with current versions of the software.

It should set the run as option only on a non local install. On a local install it runs normally. It doesnt look at whether the destination has write access or not, just on install type

by local / non local install is that an option that is presented during install (thinking of the python installer that gives you a ‘for everyone’ or ‘just for me’ option) or does it just refer to whether the installer was run as admin?

The installer gives the ‘for everyone’ and ‘just for me’ option.
The runas option should be only set when install ‘for anyone’

In the installer code:

CreateShortCut ‘$SMPROGRAMS\GNU Octave $VERSION$MultiUser.Local\BLAS Switcher.lnk’ ‘$INSTDIR\$OCTAVE_SUBDIR\bin\blas_switch.exe’ ‘’ ‘’ 0

${If} $MultiUser.InstallMode != “CurrentUser”
Push ‘$SMPROGRAMS\GNU Octave $VERSION$MultiUser.Local\BLAS Switcher.lnk’
Call ShellLinkSetRunAs
Pop $0