I am using my own laptop locally with win 10 system and intel parallel studio .
After I compiled my mpi code with mpiifort and run it with mpiexec for the first time. It warns me to input account and password, like below
I am sure I put in the correct password. But it just didn't work. What does "execvp error" mean? I never encountered this problem before on my old win8 system. I just installed this new win10 system on my laptop, everything is new. Could somebody please help me instead of making close vote without any comment? At least, say something
execvp error on file is the error from doing execvp system call. It is variant of exec system call used to start programs. In your case the mpiexec program tries to start the mpi-learning-pack.exe file on the target hosts (according to settings, probably some environment settings). This error says that it can't start your program on target hosts, because either it is not executable file, or cannot be found (not copied to target hosts or have no full path).
mpiexec does not copy file to targets, you should copy it to every target hosts.
You can also check if it executable by manually starting it on target host: just login to target host and type mpi-learning-pack.exe without mpiexec;
program may not start if there are no any of required library on target.
Or your account has no enough privileges like https://software.intel.com/en-us/forums/intel-clusters-and-hpc-technology/topic/607844 https://software.intel.com/en-us/forums/intel-clusters-and-hpc-technology/topic/624054
Or you just should use relative (mpiexec [options] .\mpi-learning-pack.exe) or full path (mpiexec [options] e:\w\work\fortran\_test_and_learning\mpi-learning-pack.exe) of target executable like in https://software.intel.com/en-us/forums/intel-clusters-and-hpc-technology/topic/624054
Related
I am using pyinstaller to distribute a python program. It's work fine on my build machine, but on my target machines, I am getting a "path not found" error and the path is relative (.e.g. .\mylib). I do modify the sys.path at runtime, but I have taken the steps suggested by pyinstaller to account for that. I've also tried -add-data, but -add-data seems to make things worse and I get errors where files are being created twice.
What's is bizarre to me is that if I run the python script on the target machine once, (i.e. install python), the EXE created by pyinstaller by the build machine will now work on the target machine. I can then remove python from this machine and.... the exe continues to work. My next step is to start a VM and follow the debug steps from the guide, but thought I would reach out and see if anyone had some advice on what my cause this?
The output in GoLand's terminal:
The output of go env in the OS terminal:
GoLand manages some of the environment variables and settings and overrides what's configured in the system so that it can create a reproducible environment between running code in the builtin terminal or when using the editor itself.
From what I can see in the images, I see that there are some differences around the GOFLAGS, GOPROXY, and GOMOD.
If I understand correctly what you are trying to do, then you need to enable the Go Modules support via Preferences | Go | Go Modules (vgo) and enable the Go Modules integration. Once you do this, you'll see that the GOFLAGS value will change.
There you can also set the Proxy field value to configure the GOPROXY environment variable.
The GOMOD difference comes from the directory where you invoked the go env command, as in this case they seem to be different directories. Invoke the command in the same directory in both IDE terminal and OS terminal and you'll see the same value. It indicates which, if any, go.mod file is used in the current command.
Finally, I recommend upgrading to GoLand 2019.3 as it will automatically enable Go Modules support when it detects that the project is created in a directory with a go.mod file present.
I followed the Software Collections Quick Start and I now have Python 3.5 installed. How can I make it always enabled in my ~/.bashrc, so that I do not have to enable it manually with scl enable rh-python35 bash?
Use the scl_source feature.
Create a new file in /etc/profile.d/ to enable your collection automatically on start up:
$ cat /etc/profile.d/enablepython35.sh
#!/bin/bash
source scl_source enable python35
See How can I make a Red Hat Software Collection persist after a reboot/logout? for background and details.
This answer would be helpful to those who have limited auth access on the server.
I had a similar problem for python3.5 in HostGator's shared hosting. Python3.5 had to be enabled every single damn time after login. Here are my 10 steps for the resolution:
Enable the python through scl script python_enable_3.5 or scl enable rh-python35 bash.
Verify that it's enabled by executing python3.5 --version. This should give you your python version.
Execute which python3.5 to get its path. In my case, it was /opt/rh/rh-python35/root/usr/bin/python3.5. You can use this path to get the version again (just to verify that this path is working for you.)
Awesome, now please exit out of the current shell of scl.
Now, lets get the version again through this complete python3.5 path /opt/rh/rh-python35/root/usr/bin/python3.5 --version.
It won't give you the version but an error. In my case, it was
/opt/rh/rh-python35/root/usr/bin/python3.5: error while loading shared libraries: libpython3.5m.so.rh-python35-1.0: cannot open shared object file: No such file or directory
As mentioned in Tamas' answer, we gotta find that so file. locate doesn't work in shared hosting and you can't install that too.
Use the following command to find where that file is located:
find /opt/rh/rh-python35 -name "libpython3.5m.so.rh-python35-1.0"
Above command would print the complete path (second line) of the file once located. In my case, output was
find: `/opt/rh/rh-python35/root/root': Permission denied
/opt/rh/rh-python35/root/usr/lib64/libpython3.5m.so.rh-python35-1.0
Here is the complete command for the python3.5 to work in such shared hosting which would give the version,
LD_LIBRARY_PATH=/opt/rh/rh-python35/root/usr/lib64 /opt/rh/rh-python35/root/usr/bin/python3.5 --version
Finally, for shorthand, append the following alias in your ~/.bashrc
alias python351='LD_LIBRARY_PATH=/opt/rh/rh-python35/root/usr/lib64 /opt/rh/rh-python35/root/usr/bin/python3.5'
For verification, reload the .bashrc by source ~/.bashrc and execute python351 --version.
Well, there you go, now whenever you login again, you have got python351 to welcome you.
This is not just limited to python3.5, but can be helpful in case of other scl installed softwares.
I'm trying to run "netsh mbn show interfaces" from a .bat or .jar file on a Windows 7 64bit system but every time I run my file, it results in "The following command was not found mbn show interfaces".
When I run that same command in a cmd.exe prompt, the result is correct and as expected.
When we run /? we see "mbn" in available commands. When we output that same result from a .bat or .jar, we don't see that "mbn" command in the available commands for netsh.
Anybody know what's happening?
We know there are 2 netsh.exe files, one in sys32 and one in syswow64.
All help is appreciated.
we solved the problem:
When running the command "netsh mbn show interface" was running the cmd as a 64bit operation.
When running the command from an application - that is 32bit - the cmd is run as a 32bit operation. And the mbn-context is not available in 32bit.
In a windows 64bit os, a behind the scenes function exists: file system redirection.
Meaning: a 64bit process will call the equivalent 32bit process.
The workaround is that you use a csharp script or something else where you can override the file system redirection:
IntPtr ptr = IntPtr.Zero;
Wow64DisableWow64FsRedirection(ref ptr);
// -- your proces information here --
Wow64RevertWow64FsRedirection(ptr);
//always revert the operation.
and that solved it!
I have source code of a compiler which I am building like this:
/path/to/srcdir/configure --prefix=/path/to/installdir
make
make install
I want to distribute the resulting 'installdir' to other machines, with the intent that anybody could use the compiler binaries without going through the 3-stage build process (I am just including the installdir in my distribution tarball).
For testing, I am copying the installdir to another machine under a different user, and then just trying to compile a test program using the binaries I just copied over, like this:
installdir/bin/ucc -mp -o test load_bl.c
Then, I get an error as follows:
cc1: error: /home/sghosh/normalbuild/installdir/open64-gcc-4.2.0/include: Permission denied
cc1: error: /home/sghosh/normalbuild/installdir/open64-gcc-4.2.0/lib/gcc/x86_64-redhat-linux/4.2.0/include: Permission denied
cc1: error: /home/sghosh/normalbuild/installdir/open64-gcc-4.2.0/x86_64-redhat-linux/include: Permission denied
The /home/sghosh/normalbuild/install is what is specified as --prefix during configure on my build machine. The installdir/bin/ucc binary require some files in the open64-gcc-4.2.0 dir under installdir, but since that is the path mentioned in --prefix, so it's still looking for it there, and I want it to look into the same dir in the current machine. FYI, I do not have sudo/root privileges.
How do I come up with a binary distribution that would work in any machine (build once, use anywhere sorts), and not look into the initial --prefix path in this case?
I have had a similar question in superuser, but since lots of edit happened and I got no response to the new question, so I am writing it here.
Check this tool: https://github.com/pgbovine/CDE
CDE is a tool that automatically packages up the Code, Data, and Environment involved in running any set of Linux commands so that they can execute identically on another computer without any installation or configuration.