I have a problem with .NET Core installation on Mac OS X (El Capitan 10.11). Generally, I did everything as MS documentation said but when I'm trying to test the installation (dotnet new) I get an error:
Unhandled Exception: System.TypeInitializationException: The type
initializer for 'Crypto' threw an exception. --->
System.TypeInitializationException: The type initializer for
'CryptoInitializer' threw an exception. --->
System.DllNotFoundException: Unable to load DLL
'System.Security.Cryptography.Native': The specified module could not
be found.
I was trying to deploy .NET core through manual process, i.e. downloaded all the packages from Git, install mandatory libraries (like openssl) via Homebrew and start compiling. Coreclr has compiled well, but corefx gives errors resembling to what I received with automatic installation:
In file included from
/usr/local/git/corefx/src/Native/Unix/System.Security.Cryptography.Native/pal_ecdsa.cpp:5:
/usr/local/git/corefx/src/Native/Unix/System.Security.Cryptography.Native/pal_ecdsa.h:7:10:
fatal error: 'openssl/ecdsa.h' file not found
include
^ make[2]: *** [System.Security.Cryptography.Native/CMakeFiles/System.Security.Cryptography.Native.dir/pal_bignum.cpp.o]
Error 1
I looked through the interned for possible solution with no luck. I cannot get one thing... if openssl lib is deprecated, why in the world MS keeps using it, as it obviously causes a lot of pain in well known place.
Has anybody managed to run .NET core on Mac, having the issue I described above?
After a while, I decided to reinstall everything from scratch. I have deleted git repo with dotnetfx source, cleaned out 'lib' and 'opt' folders (from 'openssl'), deleted Cellar folder (where 'openssl' reside). Once I did all this, I've started a new installation and followed instructions published on the official resource This time it all been deployed and works like a charm.
Related
I have downloaded and installed a Windows native compiled OpenFOAM from here. But when I try to run any of the OF commands (e.g., blockMesh, foamDictionary, ...) in the MSYS2 terminal I get the message:
path/to/folder/v2106/msys64/home/ofuser/OpenFOAM/OpenFOAM-v2106/platforms/win64MingwDPInt32Opt/bin/blockMesh.exe: error while loading shared libraries: libstdc++-6.dll: cannot open shared object file: No such file or directory
and in the cmd terminal, I get the error message:
System Error The code execution cannot proceed because msmpi.dll was not found. Reinstalling the program may fix this problem.
From here, I see that I might have to reinstall OpenFOAM in admin mode, which I don't have on this work machine. so I tried installing MSMPI using pacman -S msmpi as I used to do here. But I get the error message:
error: target not found: msmpi
My goal is to install and use the OpenFOAM software, doesn't matter which release, on this Windows machine without admin privileges. I would appreciate it if you could help me know how can I fix the above problems, or find another way around.
P.S.1. Searching the installation directory, I see that the libstdc++-6.dll file is in the path\to\folder\v2106\msys64\home\ofuser\OpenFOAM\OpenFOAM-v2106\platforms\win64MingwDPInt32Opt\bin. So I wonder I get the first error message. Maybe OF is not compiled properly against the library? Should I try removing the path\to\folder\v2106\msys64\usr\lib\gcc\x86_64-pc-msys\7.4.0\libstdc++.dll.a as suggested here?
P.S.2. I had written this post ages ago about different ways to install OpenFOAM on Windows. Sadly it is still a big effort to get it up and running.
P.S.3. A follow-up on this issue here on the MSYS2 Discord server.
P.S.4. Opened a new issue here on the OpenFOAM repository.
With OpenFOAM-v2112 it is now possible to install without windows admin permissions.
The original problem will still be evident with older OpenFOAM versions since they relied on installing msmpi separately.
I'm trying to install Yesod through cabal on my HP computer, but the building process fails when shakespeare library gets the turn. MSYS2+MinGW in the path, the rest actually works. What could be the issue? I have my suspicions that it might be due to the x64 processor I have, but not sure.
Tried installing globally with runhaskell, but same story.
C:\Users\Ivan Kretov>cabal install shakespeare
Warning: The install command is a part of the legacy v1 style of cabal
usage.
Please switch to using either the new project style and the new-install
command or the legacy v1-install alias as new-style projects will become
the default in the next version of cabal-install. Please file a bug if
you cannot replicate a working v1- use case with the new-style commands.
For more information, see: https://wiki.haskell.org/Cabal/NewBuild
Resolving dependencies...
Starting shakespeare-2.0.20
Building shakespeare-2.0.20
I've been trying to install hmatrix on my (64-bit) Windows 10 computer; after searching through and trying many possible solutions (including the instructions under "Windows" and "Alternative Windows Build" given here), I decided to pursue the course of action given on this Reddit thread.
However, when I type in the command
cabal install hmatrix -fopenblas --extra-lib-dir=${c:\msys64\mingw64\bin} --extra-include-dir=${c:\msys64\mingw64\include}
into the MSYS2 shell, the following log is given:
Resolving dependencies...
Configuring hmatrix-0.17.0.2...
Failed to install hmatrix-0.17.0.2
Build log ( C:\Users\Christian\AppData\Roaming\cabal\logs\hmatrix-0.17.0.2.log ):
Configuring hmatrix-0.17.0.2...
cabal.exe: Missing dependency on a foreign library:
* Missing C library: libopenblas
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
cabal: Leaving directory 'C:\msys64\tmp\cabal-tmp-4244\hmatrix-0.17.0.2'
cabal.exe: Error: some packages failed to install:
hmatrix-0.17.0.2 failed during the configure step. The exception was:
ExitFailure 1
However, when I check the directory c:\msys64\mingw64\bin, I see that libopenblas.dll is right there; I don't know why cabal can't seem to find it.
Any insight into why this is not working or what to do?
UPDATE:
The files libopenblas.dll.a and libopenblas.a are in the directory c:\msys64\mingw64\lib. Is it possible I need to somehow include this directory as well? (If I do, how would I do that?)
I also downloaded the files in Alex Vorobiev's comment below and put them in c:\msys64\mingw64\bin if they are .dlls or c:\msys64\mingw64\lib if they are .libs. The header files were already contained in c:\msys64\include\openblas.
I tried several variations on the command in the original post after making these changes, including switching \bin with \lib and switching \include with \include\openblas, but all of them still give the same error.
I'm a bit suspicious about the
if os(windows)
if flag(openblas)
extra-libraries: libopenblas
in the cabal file, could you unpack it and remove the "lib" part? If that doesn't work please post a log with -v3 output. I've seen quite a few people with troubles installing this package. So could you also open a ticket on the GHC bug tracker if this doesn't work (and CC me "Phyx-")?
Secondly, you never said which version of GHC you're using. 8.0.1 should have far less trouble (and won't need the hack to get it working in GHCi) since the runtime linker has been overhauled and should be much better on Windows. 8.0.2 will likely include the new import libraries support as well.
I have worked on machine A on an Xcode project, which is linked to a bitbucket git repo. All up-to-date and committed, unit tests run fine.
Now I want to work on it on machine B. I fire up Xcode, clone the repository, and all the files are there in my project. I press cmd-U to run the unit tests, and they 'pass' in lightning speed, or rather, they do not run at all. This is the error message I get:
objc[6434]: GC: forcing GC OFF because OBJC_DISABLE_GC is set
2013-06-11 10:20:05.935 otest[6434:303] The test bundle at /Users/oliver/Library/Developer/Xcode/DerivedData/TextToolsSystem-celmxjqlddjrjvblrklrnvdpytux/Build/Products/Debug/TextToolsSystemTests.octest could not be loaded because a link error occurred. It is likely that dyld cannot locate a framework framework or library that the the test bundle was linked against, possibly because the framework or library had an incorrect install path at link time.
2013-06-11 10:20:05.942 otest[6436:203] *** NSTask: Task create for path '
TextToolsSystemTests' failed: 22, "Invalid argument". Terminating temporary process.
The project does not use any additional frameworks or libraries, and works fine on machine A. A listing of the mentioned directory yields
total 192
-rwxr-xr-x 1 oliver staff 96604 11 Jun 10:20 TextToolsSystemTests
and that file is a Mach-O 64-bit bundle x86_64.
Machine A: MBP, OS X 10.8.2, Xcode 4.6.2
Machine B: MBA, OS X 10.7.5, Xcode 4.6.2
Building the project gives no error (it hasn't got an executable yet that could be run)
Are there any settings that I need to adjust to make it work which the cloning did not carry over?
OK, after some digging I found the solution:
I used otool -L to list the required libraries that the target was referencing (thanks to this question for reference).
Then I manually added in all the libraries/frameworks, even though they're CoreFoundation etc, which would normally not be required. However, it also included libobjc.A.dylib.
Now I was getting a different error, dyld: lazy symbol binding failed: Symbol not found: _objc_setProperty_atomic, which was expected in that library.
I then searched for that error message, and it lead me to this question, which had no accepted answer, but in a comment stated The problem for me was that I had a framework included with deployment target 6.0. After having recompiled it with deployment target 5.0, resulting in all projects and sub-projects being built with deployment target 5.0, everything worked.
I checked the OS X deployment target, and it was set to 10.8–but machine B only runs 10.7! So I changed the target to 10.7, and then it worked.
So, to summarise: the issue was that the deployment target was set to an OS revision which was higher than that of the current machine. Duh!
I am new to python and plan on using it with pykml to create KML files for Google Earth. I have succesfully installed the dependecies(lxml-2.3-py2.7-win32.egg) and the pykml package(pykml-0.1.0-py2.7.egg) itself using easy_install.
In the python interpreter I can import lxml and pykml without issue, but when I try importing pykml."any module" I get an error that says:
python.exe - Unable to Locate Component
-This application has failed to start because MSVCR90.dll was not found. Re-installing the application may fix this problem.
After getting this I downloaded the MSVCR90.dll and placed it in my \Lib\site-package folder and got the following error:
Microsoft Visual C++ Runtime Library
- Runtime Error!
- Program: C:\hp\bin\Python\python.exe
-R6034
-An application has made an attempt to load the C runtime library incorrectly. Please contact the application's support team for more information.
Anyone with experience using pykml on Windows please help!!!
Thanks!