Re: Solved: R-3.3.3-1: unable to load stats.dll
On 2017-03-31 13:32, cyg Simple wrote:
> On 3/31/2017 12:57 PM, Marco Atzeri wrote:
>> On 31/03/2017 15:35, cyg Simple wrote:
>>> On 3/28/2017 3:17 PM, Oliver Schoett wrote:
>>>> Achim Gratz wrote:
>>>>> $ cygcheck /usr/lib/R/library/stats/libs/stats.dll
>>>>> instead. On a hunch, check your PATH and make sure it contains
>>>> The cygcheck command ends with
>>>> cygcheck: track_down: could not find cyglapack-0.dll
>>>> That library can be found in /usr/lib/lapack, and adding this directory
>>>> to the PATH fixes the problem: Rscript now starts without error message.
>>> Which is why the packager should move the required .dll to the /usr/bin
>>> directory. Was there a stated change to this policy?
>> If you compare openblas and lapack you will find two cygblas-0.dll,
>> that I can not make coexist in /usr/bin
> And so we add to PATH and still have a problem if the lapack and
> openblas versions are different. Adding to PATH doesn't fix the issue
> and if I add the openblas version before lapack then lapack suffers and
> vice-versa. This is the reason we've put DLL in the /usr/bin directory
> because adding to PATH is meaningless.
> should be used in the main function or a Cygwin API developed to do
> that. Or fix lapack to name it's library with a different version id.
> If there are API/ABI differences, then -0 isn't correct since the two
> cannot overlay each other.
This is the situation alternatives(8) was designed
for - to mediate names and functions.
If a package is dependent on one or the other,
its location in /var/lib/pkg/ should be wired in.
My PATH seems to include /usr/lib/lapack, appended by
Perhaps openblas could provide the same for its clients?
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple