I have tried to run an executable 'crcor' with the command
ben-Aspire-S3-391:/usr/local/src/runz% /usr/local/src/runz/crcor
/usr/local/src/runz/crcor: Command not found.
I have successfully run the code on another machine but am unable to reproduce the results on this machine.
On both machines,
which sh returns /bin/sh
however
echo $shell returns /bin/tcsh on the working machine
and /usr/bin/tcsh on the not working machine.
Any tips on how to diagnose the difference between the two to help me get this running would be great.
Edit1:crcor is an executable that links to a fortran code
Edit2: edited for spelling, '/usr/bin/tsch' --> '/usr/bin/tcsh'
Solution: Installing 32-bit libraries on my system (64-bit) has solved the issue. 'ldd' command on the working version revealed that it was recognised as a dynamic executable but on the not-working version it wasn't recognised as a dynamic executeable. Specifically ia32-libs was installed.
Solution: Installing 32-bit libraries on my system (64-bit) has solved the issue. 'ldd' command on the working version revealed that it was recognised as a dynamic executable but on the not-working version it wasn't recognised as a dynamic executeable. Specifically ia32-libs was installed.
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.
bad English (sorry).
I'm trying to get nvim_treesitter to work on my windows machine, on my Linux one it worked great but now when I try on windows the :checkhealth nvim_treesitter gives:
health#nvim_treesitter#check
Installation
ERROR: tree-sitter executable not found
OK: git executable found.
ERROR: cc executable not found.
ADVICE:
Check that either gcc or clang is in your $PATH
Parser/Features H L F I
Legend: H[ighlight], L[ocals], F[olds], I[ndents]
*) multiple parsers found, only one will be used
x) errors found in the query, try to run :TSUpdate {lang}
and I'm totally new to this thing, any advice would help:)
The main issue from my perspective is "ERROR: cc executable not found.". It means nvim_treesitter couldn't find any compiler on your machine, and so no parsers could be compiled and installed when you issue ":TSInstall {some_parser_name}" commands.
If you have Visual Studio installed (since nvim gets compiled by VS 2017, it's fine to have 2017 or 2019 studio, I guess), try this:
Run "x64 Native Tools Command Prompt for VS 201x" if you've downloaded nvim-win64 release package or "x86 Native Tools Command Prompt for VS 201x" otherwise (nvim-win32 package)
Run nvim in this command prompt (i.e. nvim-qt GUI)
Install any parsers you want, let's say ":TSInstall c". Output should look like this:
Downloading...
Compiling...
Treesitter parser for c has been installed.
Optionally run :checkhealth nvim_treesitter again to see if everything is fine
Thereafter you can run nvim in any console, not via VS Tools one only (still use it to install or update parsers though).
Please also see https://github.com/nvim-treesitter/nvim-treesitter/wiki/Windows-support for various instructions.
For the Error: tree-sitter: You can checkout creating parsers and follow the description or you download the windows binary of the binary files and put it into a directory on your PATH.
For the Error: cc: You need to install gcc
Try to apply this vsc tutorial from Prerequisites №3
I had the same issue. It helped me.
Ok, here's what I've done and what helped me:
Go to https://www.msys2.org and follow ALL of the installation steps that are described there:
Download and install
Run pacman -Syu comman
Run pacman -S --needed base-devel mingw-w64-x86_64-toolchain and choose mingw-w64-x86_64-gcc there.
After everything is installed, put into your PATH Environment Variable the path to MinGW64\bin folder (if you installed everything to the default folder it will be c:\msys64\mingw64\bin)
And you are good to go! Now open nvim and run
:TSInstall <yourlang>
For example, :TSInstall php
PS: you can get the list of available languages using :TSInstallInfo
I followed llvm-clang install instructions but having issues with configure command line. I tried both MSYS2 64 bit and Windows mingw for the purpose but similar issues appear: cmake seems confusing between windows and unix paths.
Thus, when I try MSYS2 the following error message is thrown:
File /d/mylib/llvm/D:/mylib/llvm/utils/llvm-build/llvmbuild/main.py does not exist.
It seems that prefix /d/mylib/llvm/ is wrongly added to the path. Note that in this case am using cmake installed with pacman -S cmake
On the other hand, when using windows mingw64 (that comes with git windows), am getting this error
CMake Error: File /d/mylib/llvm/utils/TableGen/LLVMBuild.txt does not exist
though the path is correct... Note that I in this case am using cmake installed directly on windows (using windows gui).
Any ideas please?
Using MSYS2 64-bit version 20161025 on Windows 10...
I'm unable to get msys2 to recognize programs in the windows path. For example, after installing Go version 1.8.3 using the windows the installer: (1) Cygwin finds go.exe (2) the Windows command prompt finds go.exe but (3) MSYS2 does not.
Please refer to attached image. Thanks in advance.
Run msys2_shell.cmd -use-full-path
or
uncomment MSYS2_PATH_TYPE=inherit in msys2.ini (can be found in the installation directory of MSYS2).
Related GitHub issue regarding the inherit flag.
I've been struggling for 2 days to install some plugins which use python on Vim (Windows). Even with a stock vimrc.
Using the official vim 7.4 binary (x86)
I've checked that it comes with +python/dyn and +python3/dyn
I've installed Python 2.7.10 x86, and appended python's path in my Path environment.
:echo has('python') prints 1 as expected.
Yet: when I type :python print 'test', vim quits, just as if I've typed :q
:python mum tell me, why does windows exists?, it quits as well. Wondering why... Not a print issue at least.
Using tuxproject's nighty builds of vim 7.4.826 (x86)
It does come with +python/dyn and +python3/dyn. Also:
Used libraries: Perl 5.22.1, Python 2.7.10, Python 3.4.3, Ruby 2.2.3, Lua 5.3.0, Tcl 8.6.4, libXpm.
Great! That's the verison I've downloaded (2.7.10) ! Wait...
:echo has('python') prints 1 as expected.
But, "merry christmas!" says vim.
Sorry, this command is disabled, the Python's site module could not be loaded. Windows isn't good enough. Oh, and merry christmas!
Using tuxproject's nighty builds of vim 7.4.826 (x64)
I tried to use x64's python binary, taking care of removing the x86 version from my Path variable. Same issue as above.
Using Kaoriya's vim 7.4.something (x64) and Veegee's vim 7.4.803
Same issue as above.
What about compiling vim ?
Windows.
I'm not that lazy, well, yes I am... but I'll try to compile it if there isn't any other workaround. I don't really want to compile it if it won't solve anything. If only I could at least understand why these issues happen...
All right, I managed to solve the issue.
For those who may be interested, the intended python version was Python 2.7.9 and not 2.7.10. Installing Python 2.7.9 x86 (and x64) fixed everything for the corresponding vim version.
First of all, need to check for the python version compiled into the vim. One of the way is to edit the gvim executable (e.g. for window it's gvim.exe), and look for "python\d*.dll\c" as mentioned inside the vim manual. Nonetheless, when you run :echo has('python3') || has ('python'), it may give you the hint that vim cannot find and load python27.dll or python32.dll, so you can guess the python get compiled with vim in this way as well.
Once you have identified the python version needed, and if your python is installed on another location, then you can specify the pythonthreedll location to let vim to find it.
:set pythonthreedll=D:\installed\python\python35.dll
check again with following:
:echo has('python3')
I have this problem too but I didn't have to install previous versions.
All I do to solve this is just set PYTHONHOME=C:\Users\MYUSERNAME\Anaconda2 in my system environment variables!
You may have to adjust the location if you did not use Anaconda as a python installer.
Note: I use python 2.7.11 and 3.5 (Both of them are installed via Anaconda 64-bit)
PS. Please ensure that PYTHONHOME is typed correctly, no underscores. And it should point to the location of Python 2 only. Don't point to Python 3 folder.
PPS. It turns out that if you set PYTHONHOME, your working python3 command on the terminal will crash, so I do not suggest this anymore.